On 22 Feb 2003 at 22:17, CBFalconer wrote:

There is no provision in any of the standard Pascals for accessing command line data. The Borland clones provide an analog of the C/Unix world in Paramstr and Paramct.

In PascalP I handled this with a system file, called cmdline, much like input and output. It was defined at the encompassing level 0 as a read-only text file, and held a single line. To access it one could use:

reset(cmdline);

[...] "cmdline" already exists in the system unit (BP compatibility) - this is from the BP help file:

"CmdLine (variable) (System unit) In a program, CmdLine contains a pointer to a null-terminated string that contains the command-line arguments specified when the application was started. "

I think having two "cmdline"s is likely to cause confusion - but I guess that if one doesn't use the GPC system unit then there should be no problem in having another cmdline somewhere else.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

CBFalconer wrote:

There is no provision in any of the standard Pascals for accessing command line data. The Borland clones provide an analog of the C/Unix world in Paramstr and Paramct.

In PascalP I handled this with a system file, called cmdline, much like input and output. It was defined at the encompassing level 0 as a read-only text file, and held a single line. To access it one could use:

reset(cmdline); cmdline^ get(cmdline); eoln(cmdline) eof(cmdline) read(cmdline, ch); read(cmdline, intvalue); (* etc *)

i.e. absolutely no extensions to the standard system.

Are you sure? Where does it say in the standard that there can be additional "system" files? In 6.10 I find explicit mentioning of `Input' and `Output', but no more.

To me it seems your `CmdLine' would be a "magic" predefined identifier, such as BP's `ParamCount'/`ParamStr' are. In both cases trying to compile such a program with a compiler that doesn't have these extensions will fail with unknown identifiers.

Note that it could be reset multiple times, to restart reading from the beginning. Since it is a one line file after readln(cmdline) eof(cmdline) will be true. If cmdline is empty eof(cmdline) will be true immediately after reset(cmdline).

Naturally the contents of that line depend on whatever shell launched the program.

How are the chances of adding this to gpc. The line itself must already be there for the runtime to prepare paramstr and paramct.

An advantage of this is that other systems can be source compatible. All the users need do is prepare a one line file, call it cmdline, and run the Pascal program. At the same time gpc users can still access an exterior file call cmdline, by simply defining it themselves. The 'extension' will only kick in when no "VAR cmdline : text" is in user scope.

I have at least two problems with it:

- Considering all command line arguments together as a single line is a DOSism. It has many disadvantages, e.g., you can't easily pass arguments containing spaces or whatever you take as separators, without doing some kind of quoting within your program.

The more flexible Unix convention, which GPC/GCC already supports, also on Dos/Windows, is an array of strings. This is also independent of the shell used, since the shell handles any quoting and expansion it supports. To the user this has the advantage that quoting and expansion are independent of the program used (in contrast to the Dos convention where some programs might recognize "", others will not, and others will use yet other quoting mechanisms, so in the worst case the user will have to find out what compiler a program was compiled with in order to find out how to pass complex arguments), but completely under the control of his shell (so if he doesn't like the available convention, he can just use another shell and has it affect all programs).

In the file mechanism, the Unix convention could be represented as one string per line -- well almost; it would break if an argument contains newline characters (quite uncommon, but not impossible). But it would be different from PascalP, so I guess you wouldn't want it, anyway.

- Pascal files have quite complex internal workings. Using them just to retrieve a few strings seems like too much overhead to me.

<rant>

I've heard many suggestion of mapping all kinds of things to "magic" files. To some degree they appear to me more like a desparate rebuttal to Ritchie's accusation that Pascal is a closed language because of its hostility to linking to external code (for the standard Pascals, anyway).

As I said, file semantics are quite complex (already on the system level, and even more so in Pascal). Though this makes them in principle usable as a container for almost anything, that's not necessarily the best way. In the extreme, it would come close to a runtime interpreted language. (Didn't others criticize C for its interpreted formatted I/O (printf etc.)? ;-)

BTW, EP provides a general mechanism of "bindings" by which you can associate program variables with external entities. GPC currently supports them only for files, but I think this would be the "clean" EP way to do such a thing. However, it adds even more overhead (and wouldn't be compatible to CP, either).

</rant>

That said, it is possible to do what you want (if you accept the drawbacks of the Dos convention). Just put the enclosed file in your source directory and compile with the options `--uses=cmdline --automake'.

Frank