-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerhard Fiedler wrote:
[snip]
| May I quote you: "Yes, on an archaic system like the Windows command-line
| processor (which has distant roots in the original CP/M CCP), the
| application programs must do some of the work of handling the "raw"
command
| line." This made me assume you knew what you were talking about -- you
sure
| didn't just copy me :)
|
|> I assume that the command-line handling is hidden in run-time libraries
|> that come with the software development environments for Windows.
|
| That's probably correct, and is probably the same as it is in *ix
| environments.

This is absolutely true in Windows. At the Win32 API level, a function
called GetCommandLine() passes you a single string. It's up to you to
break the string up into pieces. The fact that you see the conventional
argc/argv in main() is a function of the C runtime library: the library
calls GetCommandLine() and then splits up the result.

[snip]
| You said that in *ix environments, that's handled by the "shell". If you
| mean the command processor (e.g. the bash shell), that would mean that in
| *ix environments, you couldn't run a CLI application without going through
| a command processor. At least in Windows, you can run a CLI application
| directly, without a command processor (like cmd.exe), so the command line
| argument handling has to happen elsewhere (for example in the C runtime).
| I'm not really sure you're correct with your statement that in *ix
this all
| happens in the shell. I'm rather certain that it is possible to run an
| executable on *ix without spawning a shell, so the command line handling
| probably happens elsewhere.
[snip]

In Unix, the splitting of command-line arguments is, indeed, done by a
shell. The system call that allows a process to invoke a program file on
disk is execve(). You pass execve() not a command-line string, but an
ARRAY. That array becomes the argc/argv directly, with no translation at
all. You also must pass execve() the name of the program to execute,
separately. There is no searching of $PATH, you must pass a full
pathname. There is no command-line substitution, if one of the elements
of the array is "*.txt", then the invoked binary sees "*.txt" in argv.

There is a library function called system() which is specified by ISO C,
which accepts a command-line as a string instead of as an array. This
function is not a system call into the kernel, it's implemented in the C
runtime library by executing the shell and having the shell parse the
command line. If you put "*.txt" somewhere in the string, then the shell
will scan the directory for files matching the pattern and expand the
pattern. The last thing the shell does after doing all its expanding and
parsing is call execve() in order to run the actual target program.
Again, this is done by calling to the shell! In the Linux man page for
the system() function is this text:

"system() executes a command specified in command by calling /bin/sh -c
command"

so a call to system(foo) will end up with a call to execve({"/bin/sh",
"-c", foo}), which will end up with the shell starting up and splitting foo.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhTVzIACgkQiD2svb/jCb6ujwCdGa+cAX05RKUrKcs6/WqSqRr1
qEUAoIMtko8w/1tYrvw4zNtdp3g4cUZ7
=7cx3
-----END PGP SIGNATURE-----
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist