cmf851@anu.oz.au (Albert Langer) (05/27/91)
I always assumed it was "standard unix" for an executable file with
a first line as above to have "#!" recognized as a "magic number"
that causes execve(2) when called by sh to execute a command, to
use the $PATH variable to get a full path {filename} for the command
then actually call /usr/bin/nawk -f {filename} (or whatever the word
following #! and the single paramater following that is).
It works for me on SunOs 4.1 but the script always get interpreted
as an ordinary sh script instead of an awk script, whether I put
a space after #! or not, when I try on ISC 386ix 2.0.2. There does
not seem to be a man page for execve on ISC that I can find, and
the man page for exec(2) does not refer to anything except
ordinary shell scripts in this context (thus conforming to the
behaviour I am actually seeing, so apparently it's a "feature"
not a "bug" :-)
Is there some way to get the behaviour I was expecting on ISC
386ix?
Also, I have had trouble using:
nawk '
... lots of awk script ...
' awkparamaters
continue shell script
Even without awkparamaters I get "too many paramaters" or some
such as an error message. What am I doing wrong?
Anyway, that doesn't worry me so much as I prefer to keep the
awk scripts in separate *.awk files anyway, but I want the
shell script to find the awkfile when it is in the $PATH
if I use:
nawk -f $awkfile
I don't want to have to specify a directory but only a basename.
The work-around I am planning to use is:
nawk -f `findpath $awkfile`
Where findpath contains:
#! /bin/sh
set - `type $1`;echo $3
Is there some better way to fix this?
P.S. I would appreciate it if any suggestions could be emailed
direct to the address in .sig file below so I get beeped at
with the happy news while I am still working away at a mess
of awk scripts and NOT reading news. (Also I don't normally
read comp.unix.shell but am cross-posting there in case it
is not a 386ix problem.)
Will summarize here if anyone asks.
P.P.S. Is there some other newsgroup I should be asking in?
--
Opinions disclaimed (Authoritative answer from opinion server)
Header reply address wrong. Use cmf851@csc2.anu.edu.auAlbert.Langer@sunbrk.FidoNet.Org (Albert Langer) (05/28/91)
I always assumed it was "standard unix" for an executable file with
a first line as above to have "#!" recognized as a "magic number"
that causes execve(2) when called by sh to execute a command, to
use the $PATH variable to get a full path {filename} for the command
then actually call /usr/bin/nawk -f {filename} (or whatever the word
following #! and the single paramater following that is).
It works for me on SunOs 4.1 but the script always get interpreted
as an ordinary sh script instead of an awk script, whether I put
a space after #! or not, when I try on ISC 386ix 2.0.2. There does
not seem to be a man page for execve on ISC that I can find, and
the man page for exec(2) does not refer to anything except
ordinary shell scripts in this context (thus conforming to the
behaviour I am actually seeing, so apparently it's a "feature"
not a "bug" :-)
Is there some way to get the behaviour I was expecting on ISC
386ix?
Also, I have had trouble using:
nawk '
... lots of awk script ...
' awkparamaters
continue shell script
Even without awkparamaters I get "too many paramaters" or some
such as an error message. What am I doing wrong?
Anyway, that doesn't worry me so much as I prefer to keep the
awk scripts in separate *.awk files anyway, but I want the
shell script to find the awkfile when it is in the $PATH
if I use:
nawk -f $awkfile
I don't want to have to specify a directory but only a basename.
The work-around I am planning to use is:
nawk -f `findpath $awkfile`
Where findpath contains:
#! /bin/sh
set - `type $1`;echo $3
Is there some better way to fix this?
P.S. I would appreciate it if any suggestions could be emailed
direct to the address in .sig file below so I get beeped at
with the happy news while I am still working away at a mess
of awk scripts and NOT reading news. (Also I don't normally
read comp.unix.shell but am cross-posting there in case it
is not a 386ix problem.)
Will summarize here if anyone asks.
P.P.S. Is there some other newsgroup I should be asking in?
--
Opinions disclaimed (Authoritative answer from opinion server)
Header reply address wrong. Use cmf851@csc2.anu.edu.au
* Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)cpcahil@virtech.uucp (Conor P. Cahill) (05/30/91)
Albert.Langer@sunbrk.FidoNet.Org (Albert Langer) writes: >I always assumed it was "standard unix" for an executable file with >a first line as above to have "#!" recognized as a "magic number" >that causes execve(2) when called by sh to execute a command, to That is a BSDism that does not normally appear in system V systems until SVR4.0. However, ISC did add it in release 2.2, so if you upgrade you will get what you want. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
david@twg.com (David S. Herron) (05/30/91)
In article <1991May27.154914.21663@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes: >I always assumed it was "standard unix" for an executable file with >a first line as above to have "#!" recognized as a "magic number" >that causes execve(2) when called by sh to execute a command, to >use the $PATH variable to get a full path {filename} for the command >then actually call /usr/bin/nawk -f {filename} (or whatever the word >following #! and the single paramater following that is). No, you are wrong. The #! thing is a BSD-ism (like all the useful things in Unix ;-)) which AT&T (in its infinite wisdom) has been slow to adopt. It should (knock on wood) have been adopted as part of SysVr4. I have not yet verified this for myself. The #! magic number is not recognized by execve(2). Instead it is done down inside the kernel. Whatever train of code handles the exec() system call eventually reads the first few bytes of the program to see what magic number is there. If it matches up with #! then it parses the line as #!/path/path/file one-argument and acts as your expecting. >Is there some way to get the behaviour I was expecting on ISC >386ix? Upgrade to r4? There's some interesting bits of code the perl folk stick at the beginning of perl scripts so that, if the script is accidently interpreted by a shell, it gets sent off to perl instead. You might glance in their direction and see if you can do the same thing with nawk instead of perl. This doesn't seem likely since perl happens to have syntax compatible enough with /bin/sh that it works, while nawk does not. >Also, I have had trouble using: > >nawk ' >... lots of awk script ... >' awkparamaters >continue shell script > >Even without awkparamaters I get "too many paramaters" or some >such as an error message. What am I doing wrong? ALL shell's have a command line length limit. This is on the order of 4096 bytes. One solution is what the arbitron script does (I'm the `Herron' named in there) which is to: cat >/tmp/some-tmp-file-name <<'EOF' ... lots of awk script ... EOF nawk -f /tmp/some-tmp-file-name rm -f /tmp/some-tmp-file-name The technique originates (to my knowledge) with shar. >... but I want the >shell script to find the awkfile when it is in the $PATH >if I use: > >nawk -f $awkfile > >I don't want to have to specify a directory but only a basename. > >The work-around I am planning to use is: > >nawk -f `findpath $awkfile` ... >Is there some better way to fix this? How about a shell function instead of a seperate script. Shell functions have been around since SysVr2 and (should be) widely supported nowadays in standard /bin/sh. Except for pure BSD, but BASH should be supporting that feature (dunno for sure). At any rate.. a shell function will save a fork()/exec() ... Otherwise, no. If you have control over nawk you might think about an AWKPATH environment variable. Or ask your vendor or local standards organization to consider this... This is, however, a more general problem. It seems that every program is aquiring a similar PATH variable to the AWKPATH suggestion. This implies that somewhere a more general solution needs to be available. Perhaps a little library module which gives you PATH searching ability? Perhaps also a program like you mention but with a USAGE like findINpath -p path -f file (should this take find(1) like args?) Have fun, David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
rcd@ico.isc.com (Dick Dunn) (05/31/91)
david@twg.com (David S. Herron) writes: > cmf851@anu.oz.au (Albert Langer) writes: [question about availability of #!] > >Is there some way to get the behaviour I was expecting on ISC > >386ix? > Upgrade to r4? Cheap shot, but it's already supported in the current release of ISC's UNIX. (David made a comment about all the useful stuff being BSDisms...but a lot of it gets picked up by SysV vendors as "value added" because it's obviously useful.) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Simpler is better.
sef@kithrup.COM (Sean Eric Fagan) (05/31/91)
In article <1991May30.230458.6240@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >(David made a comment about all the useful stuff being BSDisms...but a lot >of it gets picked up by SysV vendors as "value added" because it's >obviously useful.) Doesn't mean it's a good thing to pick up. SCO, for example, "picked up" having a writable address 0, "because it's obviously so useful." Using #! has at least one *major* problem that causes me to not really like it: you have to hardwire in the path of the interpreter. Ugly. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
richard@pegasus.com (Richard Foulk) (06/02/91)
> >Cheap shot, but it's already supported in the current release of ISC's >UNIX. > >(David made a comment about all the useful stuff being BSDisms...but a lot >of it gets picked up by SysV vendors as "value added" because it's >obviously useful.) And they dole them out a little at a time so they can soak their customers again and again. Bend over -- here comes the update! -- Richard Foulk richard@pegasus.com