jhc@mtune.ATT.COM (Jonathan Clark) (06/24/87)
> >> On a similar note, for the people who are expounding starting one's >> shell scripts with "#! /bin/csh", the logical continuation of this is >> to start one's C programs with "#! /bin/cc", and so on. > >No. Executable files begin with a magic number, which indicates the >interpreter to be used to execute that file. I was insufficiently precise - I meant that the continuation was that one should start one's C *source* programs with "#! /bin/cc" then instead of saying 'cc file.c' one would just say 'file.c' and the kernel would automatically invoke the correct interpreter. This is not a bad feature, but it isn't what I understand as UNIX (though it probably is already implicit in BSD systems). > partial superset language processors This based on the perceived knowledge that there are Bourne shell mechanisms not supported by C shell (which I admit I have never used) - if this is not the case then I withdraw the comment. >> Perhaps csh should have been made to interpret a strict superset of the >> Bourne shell, > >Considering that the C shell, I believe, antedated the Bourne shell >(or, at least, the public availability of the Bourne shell), this >might not have been practical. Well, I am by no means an old hand at UNIX, but I remember using the Bourne shell or something very like it (and written in Algol, more or less) in 1977 on my v6 system. As an extension of the concept of magic numbers I can see the value of the mechanism, perhaps UNIX should have had a system call "hardware" which meant "run this file on the machine's actual real CPU"? Then everyone would have got used to feeding their input through *some* sort of language processor (and example of which is hardware). -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
guy%gorodish@Sun.COM (Guy Harris) (06/26/87)
> I was insufficiently precise - I meant that the continuation was that > one should start one's C *source* programs with "#! /bin/cc" then > instead of saying 'cc file.c' one would just say 'file.c' and the > kernel would automatically invoke the correct interpreter. This is not > a bad feature, but it isn't what I understand as UNIX (though it probably > is already implicit in BSD systems). But "/bin/cc" *isn't* a "C interpreter" in the commonly-understood sense of the word "interpreter". If you run "/bin/cc" on a piece of C source code, it produces an object (no pun intended) that will, when executed by the machine, do what the C program was intended to do; it will not itself do that. > > partial superset language processors > > This based on the perceived knowledge that there are Bourne shell > mechanisms not supported by C shell (which I admit I have never used) > - if this is not the case then I withdraw the comment. There are Bourne shell mechanisms not supported by the C shell. However, there are also C shell mechanisms not supported by the Bourne shell. (Also, neither language is a *syntactic* subset of the other one.) > >Considering that the C shell, I believe, antedated the Bourne shell > >(or, at least, the public availability of the Bourne shell), this > >might not have been practical. > > Well, I am by no means an old hand at UNIX, but I remember using the > Bourne shell or something very like it (and written in Algol, more or > less) in 1977 on my v6 system. The first version of the Bourne shell publicly released by AT&T in a UNIX system was the one released with V7 in 1979. I believe the work on the C shell was started on V6 (I think there are fragments of V6 shell code still in the C shell). > As an extension of the concept of magic numbers I can see the value of > the mechanism, perhaps UNIX should have had a system call "hardware" > which meant "run this file on the machine's actual real CPU"? Then > everyone would have got used to feeding their input through *some* > sort of language processor (and example of which is hardware). Do you mean "system call" or "command" (there already is a family of calls like that, namely "execve", etc.)? Some systems *do* have such a command, often named "run"; those systems either don't allow you to add new commands to their command languages or they require you to do something special to do so. If UNIX did have a "run" command, and didn't oblige people to use it, would people have used it if they could also have run a program just by typing the program's name? If it required you to use "run", would people have been as eager to add new commands, since doing so would require you to add an alias (e.g., aliasing "newcommand" to "run newcommand" or "sh newcommand") if you wanted to use it without typing an extra noise word "run" or "sh" in front of it (and if you didn't have aliases, you'd really lose)? Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com