From the configuration file format to Gui and CLI

Take a look at the windows ini format configuration file:
[Startup]
Cmd = A. bat
Para =...
...
Windows configurations are all the preceding INI files in the following format:
[Section]
Name = Value
...
Although this configuration file is not as shameless as a binary file, it is also "formatted". For example, the above "[", "]", "=" and so on are all in the format, the more formats are defined, the more Program As the configuration file becomes more complex and professional, the processing program becomes a giant such as Word. Therefore, do not define configuration files with too complex formats, the program should not use a large number of logic to process file IO, so keep the configuration file as simple as possible. Just like the UNIX text configuration file, there is no section, in the unit of action, processing a row each time. The processing program can be very simple. Taking a while loop as a big frame, there is a state machine in it, each row is a state machine, and each row is also a substate machine, the parser controls the two state machines to move forward until the files are processed. The following is a classic Configuration File Processing framework:
Static void read_config_file (...)
{
Int line_num;
Char line [option_line_size]; // a row of the configuration file
Char * P [max_parms]; // a meaningful array converted from a row in the configuration file
Fp = fopen (file, "R ");
Line_num = 0;
While (fgets (line, sizeof (line), FP) {// read a row
++ Line_num; // The following parse_line implementation is a state machine, which is essentially converting meaningless line of data into a meaningful String Array P
If (parse_line (line, P, size (P), file, line_num, msglevel, & options-> GC )){
Bypass_doubledash (& P [0]); // cross "--". The following add_option fills the result of parse_line-a meaningful array P into the struct option to complete parsing of the configuration file line.
Add_option (options, P, file, line_num, level, msglevel, permission_mask, option_types_found, ES );
}
}
Fclose (FP );
}
The above processing program is very compact, basically three things, 1. read a row. 2. converts a line of meaningless strings into a meaningful string array. 3. converts a meaningful string array into a struct in the program. In addition to annotations such as "#" to be processed (very simple, skip directly), there is very little need to process complicated additional formats. If you want to use getopt_long to process parameters like a command line parameter, the configuration file format is simpler. if you write a line or branch directly, you can delete the line break during processing and then read the file into a buffer zone, use awk to process the buffer, format it into the format of Main Parameter argv [], and finally pass in getopt_long (MAN 3 getopt), which is very flexible. Because the configuration file is written into a format like -- xxx yyy, the readability is affected, so the format of xxx yyy is used. For the command line, '-' or '--' is the best way to understand, but they are not required for configuration files. Compared with the Windows INI file, the handler is missing [,], =.
It is unknown why Windows uses the ini "so complex" text format, but the fact that the Unix simple configuration file is preemptible is indisputable, even if windows also has UNIX shadows, the hosts, networks, and protocol files under the $ win/system32/Drivers/etc directory are instances. Even in windows, UNIX is used when network configuration is involved, this proves the fact that the network comes from Unix (BSD and Sun contribute a lot ). Since many network configurations have taken shape, Windows will also take advantage of it. This is just speculation... windows is actually not stupid enough to deliberately complicate the configuration file. The reason why Windows uses a section-based configuration file may be to cater to its GUI, Gui-based configuration is often structured, the final configuration of a program is a tree structure. For example, the "Start" menu is a tree structure, and the configuration of the CLI program is almost a linear structure, if a program is configured with a tree structure, it is obviously difficult to use a linear configuration file to correspond to the GUI. Therefore, only configuration files with a certain structure can be used. In these structured configuration files, the simplest thing is the INI file. It can be seen that Windows does not pursue simplicity, but its GUI itself has alienated the meaning of the word "simple". At the GUI level, the simplest configuration file is the INI format, although not all programs that use the INI file have a GUI. The GUI is an idea, not just an interface.
The reason why the GUI is bloated is that it is not a single abstraction. A "button" has a "Visual Sense" meaning in addition to the specific logic meaning, A multi-level menu can be used only after it is found out. Therefore, it is particularly important to organize the GUI structure. A good GUI program must have well-organized controls. In contrast, CLI, you only need to design the configuration parameters. These Parameter options are not required in the order of the command line or configuration file, and the "sensory" requirement is eliminated in design, the simplest and most efficient configuration file can be used only by combining all configuration options with a single logic. CLI is external and GUI is introverted. The differences between CLI and GUI are the same as those between letters and Chinese characters. To add a new option to the CLI program, you only need two steps. add a field to the internal struct of the program; 2. add an else if or case when parsing parameters. This kind of work can be infinitely expanded, that is, the parameters can be added at will. In the end, you only need to complete the manual, the user will not misuse it or be mad for not knowing what the parameter means. In addition, the CLI user does not "find" the parameter location. Before using an option parameter, the user must know its meaning (refer to the Manual), and then press it on the keyboard. However, for a GUI program, adding an option will inevitably involve changes to the interface. First, consider the location where the new option is added and the menu item under which the menu is added. As the number of options continues to increase, the menu tile is too long, and the subset is too deep. before using the control, you must find the control. In short, the search process is inconvenient, and the number of controls tends to be saturated in the search sense, the GUI is overwhelmed by the availability of controls and cannot be added any more. The GUI scalability is limited by the "senses", which means it is introverted.
The GUI wastes the vast majority of keys on the keyboard, and most of the time you just need to use the mouse. This is especially useful when there are few option parameters, such as the case of answering "yes" and "no, in the case of GUI, the user can see the control with "yes" and "no" at a glance, and then click the mouse. However, if you use CLI, you must first check the manual, if you want to select "yes", what is the input ..., faced with so many buttons on the keyboard, I really don't know what to press, but if there are only two buttons, one click may succeed. If there is only one button, then you only need to press it. As the option increases, the keyboard is effectively used, and the advantages of CLI are shown, at least it makes you no longer think that designing so many buttons is a waste. The more options, the more complex the program functions, the more powerful, and because the GUI has a natural limit on the number of options, it cannot take on the big job, unless you give up the GUI, also write command line programs on Windows. If you have configured IIS and Apache, you should feel the difference between GUI and CLI.
It is precisely because the CLI program uses a keyboard for configuration, rather than a two-or three-click mouse, that long file names are not recommended in the CLI environment and are almost always abbreviated, this is to minimize the input (maybe it also plays a role in memory saving in the early stage). In contrast, no matter how long the file name is, click it and there is no icon, the file name is too short to shake hands and it is not easy to hit! Finally, the GUI program can be said to have no real configuration concept, and they have almost no scalability at the beginning. If the program in the CLI environment is a general-purpose computer, then the GUI program is a customized TV set with fixed buttons or any machine with fixed panel.