Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!snorkelwacker!apple!rutgers!att!cbnewsh!wcs
From: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs)
Newsgroups: comp.sources.d
Subject: Re: Perl scripts on systems without "#!"
Message-ID: <5935@cbnewsh.ATT.COM>
Date: 20 Nov 89 05:23:13 GMT
References: <255C7F44.171@ateng.com>
Reply-To: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs)
Organization: Committee To Insult The C Shell
Lines: 71

Chip posted an article about a perl hack to make csh feed the script
to perl on systems that don't handle #!/bin/perl on the first line.
I followed up pointing out that this will fail miserably for people
whose systems don't feed shell scripts to C shell.

In article <255C7F44.171@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
] According to wcs@cbnewsh.ATT.COM (Bill Stewart):
] > ] like to keep the #! as the first line.  Shell scripts that start with 
] > ] the #! are considered C shell scripts on systems where #! doesn't work.
] > WRONG!!  Most System V systems do not support the #! hack.
] Of course.  I never asserted otherwise.
	You asserted that systems which don't support #! support the
	# => C shell convention.  Vanilla System V systems do not
	do either one, and are thus a major counterexample.

] In my experience, all Unix vendors that include the C shell have modified
] their Bourne and C shells to use some consistent rule to determine the
] flavor of a given script.  Also, as far as I know, all systems with a C
] shell and without "#!" consider an initial "#" to signify a C shell script.
] This decision is the same regardless of the shell doing the examination.
	You experience is too limited :-).  On conventional System V systems,
	the C shell generally will assume initial # means C shell,
	but the Bourne Shell (and Korn Shell) follow correct syntax,
	which is that # is simply a Bourne-shell comment.

	The decision that # means C shell was made back when the
	alternative was V6 Mashey shell (maybe also very early Bourne?),
	which used : for the eval-and-ignore statement and didn't
	have a true comment.  But this is only supported on Berkeley
	systems and systems whose vendors have decided to break
	conforming Bourne shell programs to enhance C shell support.
	Using #!/bin/csh as an indicator that the user really wants
	csh isn't too bad, since it isn't a comment that people
	would put at the beginning of most Bourne Shell scripts.

] >   What is really needed here is a 3-language hack, for perl, csh, and sh.
] You're quite right, for once.  
	Always, Chip, Always!  :-)
] >   The suggestion you give below won't work
] >   - the set noglob changes $* to "noglob", which is boring.
] Oh, Bill.  You've given yourself away as being ignorant of the C shell.
	No, you've lost context at this point.  I had just argued
	that standard behavior for System V and other "proper" systems
	is to use Bourne Shell for shell scripts, in the absence of #!,
	and therefore the discussion is in the context that the
	script might find itself being run by /bin/sh, csh, or perl.
	Perhaps I should have been more explicit about the fact that
	I was describing what your hack would do if fed to /bin/sh,
	but my comment is correct about what /bin/sh (and ksh) does
	with a "set noglob" statement, and was checked on several
	different Bourne shell implementations.
	
] Setting noglob is required if "/bin/perl -S $0 $argv" is to work properly.
	Too bad - if you didn't need to set noglob, or could find a
	hack that tells csh to set noglob and does something
	innocuous in /bin/sh, we might have a working 3-language hack,
	since both shells will handle the exec correctly (assuming
	perl is in /bin/perl, which is often not valid.)

] Oh, please.  Calm down, Bill, and read carefully before following up.
	That *was* calm, more or less, and I think I had read it carefully.
	I simply have a different worldview than yours, and come to
	different conclusions from reading what you wrote :-).
	Remember that not everyone uses, or even likes csh!
	Systems that do support it don't always treat it specially.

				Bill
-- 
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 api.att.com!wcs

#		We did it for the formlessness ...