Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!emory!wrdis01!mips!twg.com!david
From: david@twg.com (David S. Herron)
Newsgroups: comp.unix.sysv386
Subject: Re: #!/usr/bin/nawk -f
Message-ID: <8988@gollum.twg.com>
Date: 30 May 91 02:11:23 GMT
References: <1991May27.154914.21663@newshost.anu.edu.au>
Organization: The Wollongong Group, Palo Alto, CA
Lines: 105

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