How can I parse variable from another ini file?
In following example, I'd like to parse var_a from original_configuration.ini and use it at new_configuration.ini
original_configuration.ini:
[Section A]
var_a = "foo"
var_b = "bar"
new_configuration.ini:
[Section B]
var_c = "lorem"
var_d = {value of var_a in original_configuration.ini}
Since an INI file is an informal standard it depends on the program which is using the configuration file:
The INI file format is an informal standard for configuration files for some platforms or software. INI files are simple text files with a basic structure composed of sections, properties, and values.
Neither Wikipedia nor Microsoft's page about INI configutariont files mention anything about referring to other properties or other configuration files. However since it is not a formal standard, each configuration parser can have its own variant. This answer for example, shows that Python's configparser package is able to refer to other properties:
[env]
name = DEV
[dir]
home = /home/${env:name}/scripts
Related
I'm trying to understand how I can create a ".config" file containing a bunch of parameters to later use to set up the variables in my C project on Unix.
I created my ".config" file using sudo nano test.config and wrote some stuff inside such as:
#N is this
N 10
#p is that
p 0.002
#T is this
T 10
Now that I did that how can I read its content and use it to initialize my variables?
The several answers to this question explain how to parse that config file, but you could use standard parsing techniques (perhaps your own recursive descent parser) or Glib's lexical scanning or key-value pair parser (or use something else). You certainly should define and document (perhaps using EBNF) what is the format of that textual configuration file (and what the various entries there represent: for example, if that configuration file refers to other files, how do you handle spaces in such file paths, etc....). A common (but not universal) convention is to consider as comments so skip any line starting with #.
Another question is how to get that config file while running in an arbitrary working directory. You just need to build the absolute path of your file (for fopen(3) or open(2)), e.g. with
char configpath[100];
snprintf(configpath, sizeof(configpath), "%s/.test.config", getenv("HOME"));
You could test before that getenv("HOME") is not NULL, but in practice that is very unlikely; see environ(7) and getenv(3); and the case when it gives a very long file path is also unlikely; you might test that snprintf(3) returns a count less than sizeof(configpath) or use asprintf(3).
You might use other functions, e.g. glob(3) or wordexp(3) to get that file path (but you probably should stick to snprintf or asprintf with getenv("HOME")...).
You might consider instead embedding some scriptable interpreter like lua or guile in your program (but that is a strong architectural design decision). Then the configuration file becomes some (Turing-complete!) script.
BTW, there is no need to use sudo to edit that configuration file (under your home directory), and you might decide to also read some system-wide configuration under /etc/
I'm testing some GTK+ examples.
At some given function, a reference to some path of a XML file appears in
C code. It explains that the code in C is reading the XML content to
later compile it to be usable from the C code:
static void
example_app_window_class_init (ExampleAppWindowClass *class)
{
gtk_widget_class_set_template_from_resource (GTK_WIDGET_CLASS (class),
"/org/gtk/exampleapp/window.ui");
}
I can understand what is happening here, but not how is it reading the source XML? window.ui, in this case. Because the repo has no folder
as they mention (/org/gtk/exampleapp/).
So, in my function I expect to do something like:
static void my_style_window_class_init(MyStyleWindowClass *class) {
gtk_widget_class_set_template_from_resource(GTK_WIDGET_CLASS(class),
"window.ui");
}
All my XML content is in the same folder as *.c and *.h files. This is a testing decision and have no other meaning.
The _from_resource() part of the function name indicates that the path /org/gtk/exampleapp/window.ui is not a filesystem path, but rather a resource path. Resource paths tie into a feature of GLib called GResource which allows you to embed binary data inside a program or shared library.
You would write an XML file to describe what local files map to what resource paths, and then as part of your build process, you would convert that to a C source file with the glib-compile-resources tool. You then build that C source file into your program. The full details are on the page that I linked in the first paragraph.
(Note that these are not the same as the embedded resources in Windows executables, which use a different technology altogether, but work in similar ways.)
If you want to load something from a file, GLib and GTK+ and other libraries built on them provide a _from_file(), _from_data(), or _from_stream() alternative to the _from_resource() function. _from_file() reads the data from a file directly. _from_data() reads from memory. _from_stream() reads from a GStream, which is an object-oriented I/O endpoint defined by GLib in its GIO module. The function name suffix is optional; it varies.
In the case of gtk_widget_class_set_template_from_resource(), the equivalent provided is gtk_widget_class_set_template(), which follows the _from_data() pattern of reading from memory. The memory is stored in a GBytes object, so you have to read from your local file into the GBytes.
It's an oldie and the question seems answered but I'd like to take a direct approach and place solution - turns out that we can substitute this line
gtk_widget_class_set_template_from_resource (widget_class,
"/org/gnome/gtksourceview/tests/ui/test-widget.ui");
with this line to make the code work.
if (g_file_get_contents("test-widget.ui", &contents, &len, &err) == FALSE)
g_error("error reading test-widget.ui: %s", err->message);
bytes = g_bytes_new_take(contents, len);
gtk_widget_class_set_template(GTK_WIDGET_CLASS(klass), bytes);
Is there a C library function to get the extension of file? I know that I can design a function on my own to get extension after '.' but not all files are stored with their extensions when we read them.
So you'd like to get the type of a file? Maybe the command 'file' in Linux is what you want. You can check its source code.
The file command in Linux uses a library called libmagic (don't confuse with libmagick) to check the 'magic' bytes in the file itself to determine the likely content type.
The library is fairly cross platform, it's well documented, for example here:
http://linux.die.net/man/3/libmagic
I was looking at getting HTML-XML-Utils working on my computer and I noticed the .e filetype in the source tree. Running:
% file types.e
types.e: ASCII c program text
reveals some clues about it and its use in C files seems to be that of a header file.
Can anyone reveal some more information or history about this filetype? I've tried my best Google-foo but I cannot find anything.
I never heard of that file type in connection with C before, but after checking the files and the Makefile it seems to be variables and functions that are exported, therefore the .e extension.
They seem to be created by a special program (which comes with the package) called cexport whose manual page states:
cexport - create header file with exported declarations from a C file
I am trying to understand the different file extensions for the pfxplus powerflex database. Could someone please help telling me briefly what each file is for?
.k1
.k2
.k3
...
.k13
.k14
.k15
.fd
.def
.hdr
.prc
.pc3
Data files:
OK, so .dat is the data file.
.k1 -> .k15 are index files.
These are the critical data files for runtime. (Combined with filelist.cfg or pffiles.tab similar to define what files are available overall).
.fd is the file definition, needed for compiling programs
.tag (which you did not mention) is needed only if you need to access field names at run time (such as using a generic report tool)
.def is the file definition in human readable form, and is not needed by any process but is produced so a programmer or user can understand the file structure.
Run time:
The .ptc files are the compiled threads interpreted by the powerflex runtime.
The .prc file is a resource file that is used at runtime in conjunction with the .ptc file - it defines how a character based program is to look in a gui environment in "g-mode". It was the cheap way to upgrade character based programs when windows first started getting popular usage.
.hdr and .pc3 escape me at the moment, but are vaguely familiar - .hdr is probably another data file used with compression or special field types for later versions of pfxplus. .pc3 may in fact be the .ptc files...