minow@decvax.UUCP (Martin Minow) (02/13/86)
In <814@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn) writes: >In a hosted (as opposed to stand-alone) environment, yes, C requires >that programs be able to obtain arguments specified at the time they >are run. There is nothing in the C language that requires command line argument passing. This is solely a feature of the Unix shell. It can be quite difficult to do on some operating systems which have different assumptions about the way in which programs interact with their users. (I speak from the experience of implementing command line argument passing on at least 5 non-Unix operating systems.) Other features of the shell (such as I/O redirection, filename wildcard expansion, and the particular syntax of arguments) are equally not a part of the language. That developers have chosen to implement these features of the Unix command language speaks more for the desire to be compatibile with existing program usage -- it is not necessarily a good thing. (Please note that these are my opinions only, and not necessarily those of Digital.) Martin Minow decvax!minow
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/16/86)
In article <177@decvax.UUCP> minow@decvax.UUCP (Martin minow) writes: >In <814@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn) writes: > >>In a hosted (as opposed to stand-alone) environment, yes, C requires >>that programs be able to obtain arguments specified at the time they >>are run. > >There is nothing in the C language that requires command line argument >passing. This is solely a feature of the Unix shell. It can be >quite difficult to do on some operating systems which have different >assumptions about the way in which programs interact with their users. >(I speak from the experience of implementing command line argument >passing on at least 5 non-Unix operating systems.) > >Other features of the shell (such as I/O redirection, filename wildcard >expansion, and the particular syntax of arguments) are equally not >a part of the language. > >That developers have chosen to implement these features of the Unix >command language speaks more for the desire to be compatibile with >existing program usage -- it is not necessarily a good thing. Read my lips. Did I say "command line arguments"? No, I said "arguments specified at the time the programs are run". As the Software Tools (aka Virtual Operating System) project has shown, these can be provided on practically every significant operating system in wide use today. I didn't even mention shell features. The requirements for a hosted C environment are given in section B.1.2.2 of the X3J11 draft standard. The exact meaning of args other than the zeroth (program name) is not completely spelled out, but there is a strong implication that the environment must be able to supply them to a C program at start-up. This would not be required of a freestanding environment C implementation, of course. I don't see why you say that availability of UNIX shell features is not a Good Thing; the temporary lack of them in a system I am testing is that system's biggest deficiency. In any case, that is all irrelevant in a discussion about C.
jsdy@hadron.UUCP (Joseph S. D. Yao) (02/18/86)
In article <983@brl-smoke.ARPA> gwyn@brl.ARPA writes: >The requirements for a hosted C environment are given in section >B.1.2.2 of the X3J11 draft standard. ... > ... there is a strong implication that the environment must >be able to supply [args] to a C program at start-up. This would >not be required of a freestanding environment C implementation, >of course. I don't see why "of course." Using the System V stand-alone shell, I've gotten unix to happily accept command-line arguments specifying root, initial swap, dump, and pipe devices and other parameters. Perhaps "of course" applies just to the idea that it's not required of less fortunate systems? Note that accepting arguments is possible to most stand-alone programs on System V even without the stand-alone shell. They just prompt for their args and read them in from the keyboard. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}