mcdaniel@amara.uucp (Tim McDaniel) (03/29/90)
I'm using "Sun OS 4.0.3" on a Sun 3.
Given the two scripts
25.sh:
./25.csh
25.csh:
#
if (1 == 1) then
echo Hi
else
echo Impossible
endif
Executing "./25.sh" gives the Bourne shell error message
./25.csh: syntax error at line 7: `end of file' unexpected
There's an easy workaround: make the first line of a C-shell script
#! /bin/csh -f
But I had thought that "#" as the first byte of a file meant "this is
a C shell script" (unless, of course, the first two bytes are "#!").
It appears that the Bourne shell does not respect this rule.
Should it? (On systems where the C shell exists and uses this
convention.)
--
Tim McDaniel
Applied Dynamics International, Ann Arbor, MI
Internet: mcdaniel%amara.uucp@mailgw.cc.umich.edu
UUCP: {uunet,sharkey}!amara!mcdanieljik@athena.mit.edu (Jonathan I. Kamens) (03/29/90)
In article <MCDANIEL.90Mar28143721@rollmops.amara.uucp>, mcdaniel@amara.uucp (Tim McDaniel) writes: > But I had thought that "#" as the first byte of a file meant "this is > a C shell script" (unless, of course, the first two bytes are "#!"). > It appears that the Bourne shell does not respect this rule. > Should it? (On systems where the C shell exists and uses this > convention.) This is *almost* right. "#" as the first byte of a file means "this is a C shell script" *only if the script is being executed by the C shell*. While "#!" is a kernel thing, the "#" by itself thing is figured out by the C shell, not by the kernel. From the man page csh(1): Since many systems use either the standard version 6 or version 7 shells whose shell scripts are not compatible with this shell, the shell will execute such a `standard' shell if the first character of a script is not a `#', i.e. if the script does not start with a comment. Therefore, if your script has to always be executed by the C shell, even when it is executed by someone using another shell, you *must* have the "#!/bin/csh -f" at the top. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
guy@auspex.auspex.com (Guy Harris) (03/30/90)
>But I had thought that "#" as the first byte of a file meant "this is >a C shell script" (unless, of course, the first two bytes are "#!"). That's true on some systems. It is not true on others, and SunOS since SunOS 3.0 has been one of the "others". >It appears that the Bourne shell does not respect this rule. That is correct. >Should it? No. The original V7 Bourne shell didn't really have comments; instead, it had a no-op command ":", that permitted you to give it arguments (as long as they were syntactically correct and didn't have unpleasant side-effects!) that took the form of descriptive text. The C shell (either *ab initio*, or after some point in its life), *did* have comments, marked with "#". The original systems on which the C shell appeared didn't support "#!", so the ": means Bourne shell, # means C shell" crock was invented as a way of having Bourne shell users able to run C shell scripts and *vice versa*. Then "#!" appeared, which obliged the Bourne shell to be able to cope with "#" as the first character in a script. Berkeley added "#" as a real comment character in the Bourne shell, but didn't change the aforementioned crock. AT&T *also* added "#" as a comment character in the Bourne shell; since they didn't much use the C shell, they didn't add said crock. SunOS 3.0 picked up the S5R2 Bourne shell, since it's a big improvement over the V7-vintage one in BSD. Given that "#!" had been around for a while, it was perhaps concluded (I wasn't involved at the time, so I don't know for sure) that said crock had outlived its usefulness. >(On systems where the C shell exists and uses this convention.) S5R4 is such a system, and all *hell* would break loose were the Bourne shell to adopt that convention, since "#" has been a comment character for quite a while, and plenty of scripts would break horribly were that convention to be adopted. Fortunately, S5R4 has "#!", so that convention isn't needed, either.... The moral of the story is that the best thing to do at this point is probably to blow off the systems that don't have "#!", and always use "#!" to indicate the interpreter to be used to handle a script. An even better thing to do might be to think twice before deciding to write a script in the C shell; the Bourne shell is generally accepted as handling scripts better....
jpr@dasys1.uucp (Jean-Pierre Radley) (04/12/90)
In article <3106@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > some of >Larry Wall's scripts open with a command that does one thing on "sh" and >another on "csh", and if it detects it's running under "csh" it >resubmits itself to "sh": >PATH='.:/bin:/usr/bin:/usr/local/bin:/usr/ucb:/usr/local:/usr/lbin:/etc' >export PATH || (echo "OOPS, this isn't sh. Desperation time. I will feed myself to sh."; sh $0; kill $$) Which never worked for me. I use csh most of the time. Both on the Tandy 6000, and in SCO 386 Xenix, it turns out that /bin/csh completey invert the meaning of '&&' and '||'. -- Jean-Pierre Radley jpr@jpradley.uucp New York, NY 72160.1341@compuserve.com
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (04/12/90)
In article <1990Apr11.213725.9361@dasys1.uucp> jpr@dasys1.UUCP (Jean-Pierre Radley) writes: : In article <3106@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: : > some of : >Larry Wall's scripts open with a command that does one thing on "sh" and : >another on "csh", and if it detects it's running under "csh" it : >resubmits itself to "sh": : : >PATH='.:/bin:/usr/bin:/usr/local/bin:/usr/ucb:/usr/local:/usr/lbin:/etc' : >export PATH || (echo "OOPS, this isn't sh. Desperation time. I will feed myself to sh."; sh $0; kill $$) : : Which never worked for me. I use csh most of the time. : Both on the Tandy 6000, and in SCO 386 Xenix, it turns : out that /bin/csh completey invert the meaning of : '&&' and '||'. I try to make allowances for all kinds of cruftiness out there, but I've never felt responsible for the sins of the whole world. This behavior is, frankly, a perversion, and deserves to be treated as such. And, after all, it does say "Desperation time" there. People who feed Configure scripts to csh are asking for trouble already. Larry Wall lwall@jpl-devvax.jpl.nasa.gov