These examples copy the command-line parameters to the clipboard.
|Command()- Returns all the parameters in a single string
|CmdLine - Returns the entire command line,
including the program name and all the parameters
ParamStr (n) returns the n_th parameter
|WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR lpCmdLine, int)
lpCmdLine - This points to the command-line parameters
|int main(int argc, char **argv)
argc is the number of parameters
argv[i] is the i_th parameter
ls [ -aAbcCdfFgilLmnopqrRstux1 ] [ file... ] ps [ -aAcdefjlLPy ] [ -g grplist ] [ -n namelist ] [[ -o format ] ... ] [ -p proclist ] [ -s sidlist ] [ -t term ] [ -u uidlist ] [ -U uidlist ] [ -G gidlist ] ps: illegal option -- f usage: ps [ -aceglnrSuUvwx ] [ -t term ] [ num ]Notice that some parameters are flags and that others are associated with values.
Therefore, I suggest NOT using the M$ Windows 3.1 INI read routines. The 32-bit operating systems provide section access (which appears to have fixed the problem). But these commands are not mapped for Visual Basic 6.0. Instead, I use these routines
Delphi provides an INIFiles unit. You can read and write individual strings, integers, and booleans, as well as entire sections. I use TMemIniFiles. It provides most of the functionality of the VB routines mentioned above.
Under Windows 95, the most important non-operating system use of Environment Variables is to specify the location of the temporary file. However, if your application ever needs more than 1 Mb of temporary storage, I strongly suggest allowing the user to override this value. (My video capture board came with a program which can capture only 10 sec of video because there is no way to move the temporary file from a full C-drive to my empty 2 Gb partition.)
(It has always been my position that the only reason for most of the registry was to aid in copy protection. In the olde days, you could just copy a directory to a floppy and use that to install an application on another machine. The registry was created to make this impossible. However, now that CD-RW is cheap, people just copy the entire CD. As a result, the registry is no longer necessary. Since ini files were always better, MS has discovered a problem in "the way things work" and they are going to save the world by removing the copy protection that they required everyone to use. What really bothers me is that they have the gaul to claim that this is their idea and that they are saving the world.)
The separation between the entries in the registry and the files on disk makes it very difficult to replicate applications and to uninstall them.
[The] registry ... drastically complicates the process of deploying distributed applications ... [As a result] applications are neither self-describing nor self-contained.
Applications that are self-describing remove the dependency on the registry, ... simplifying uninstall and replication.
# /usr/local/lib/pine.conf -- system wide pine configuration # # Values here affect all pine users unless they've overidden the values # in their .pinerc files. A copy of this file with current comments may # be obtained by running "pine -conf". It will be printed to standard output. # # For a variable to be unset its value must be null/blank. This is not the # same as the value of "empty string", which can be used to effectively # "unset" a variable that has a default or previously assigned value. # To set a variable to the empty string its value should be "". # Switch variables are set to either "yes" or "no", and default to "no". # Except for feature-list items, which are additive, values set in the # .pinerc file replace those in pine.conf, and those in pine.conf.fixed # over-ride all others. Features can be over-ridden in .pinerc or # pine.conf.fixed by pre-pending the feature name with "no-". # # (These comments are automatically inserted.) # Sets domain part of From: and local addresses in outgoing mail. user-domain= # List of SMTP servers for sending mail. If blank: Unix Pine uses sendmail. smtp-server= # NNTP server for posting news. Also sets news-collections for news reading. nntp-server=newsreader.digex.net
It is better to allow the user to customize the application.
With data-driven applications, parameters are customized at runtime.
In general, you want to provide configuration control on both a per user and a per system basis. For instance
There are frequent cases where it is desired that command-line parameters can over-ride the configuration files and built-in default parameters. For instance, a command-line parameter that over-rides the hard coded INI file selection allows each user to define an icon which is customized for them.
The program structure needs to allow a variable number of command-line and INI file parameters. In order to use a common subroutine library in multiple applications, the code needs to store the parameter names and values as strings. The basic syntax is
PValueStr = Get_Param("Param Name", "Default Value")where the default value is returned if the parameter does not have a value.
Depending on the language, the data can be stored in a variable length array, a linked list of objects, or a table.
A set of similar data records and the subroutines associated with them are generically known as an object.
In general, the command-line parameters must be read first in case the user wants to specify an alternate INI file. Otherwise, the command-line values should take precedence over the same parameters in an INI file.
The MS INI file standard permits only a 2-level hierarchy - Key.paramName=Value
The MS Registry allows an n-level hierarchy. - Key1.Key2.Key3.paramName=Value
Netscape Communicator uses several sections in the registry and C:\Program Files\Netscape\Users\userName\prefs.js
In order to implement an n-level hierarchy you either have to build key names which contain all the pieces of the hierarchy, or you need to build a tree structure where any node can point to additional levels.
The ideal solution is a method which does not need to be customized for each user or for each application.
The registry provides one possibility - user preferences should be under
HKCU\Software\CompanyName\Product\Version\(At work, system policies (special software which limits user freedom) prevent users from modifying HKCU!)
A similar naming convention can be used to store ini files, but be sure to include the identifiers in the filename, not the path. (Even empty directories can require about 64K each.) The problem is how to identify an appropriate base directory which is unique for each user.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell FoldersBoth AppData and Personal (aka My Documents) are good possibilities.
Some applications may have multiple ini files for each user.
Delphi 5 has a rich ini file interface - I like TMemIniFile. It is easy to use, but