Shebang

Shebang

[Leah]

Hello.  I was curious whether there was any possibility of making gcc
ignore #! instead of viewing it as a directive.  Also, are there reasons
gcc won't compile directly from stdin to stdout?  Along with other
changes, these would make it easier to write C script files.  They would
certainly take more time to load, but scripts can be more convenient at
times.

-- 
Leah

Re: Shebang

[Zack Weinberg]

Leah <eequor@earthlink.net> writes:

> Hello.  I was curious whether there was any possibility of making gcc
> ignore #! instead of viewing it as a directive. 

I think #! is a constraint violation, which requires a diagnostic,
unfortunately.

> Also, are there reasons gcc won't compile directly from stdin to
> stdout? 

GCC will, actually; it's the assembler and linker that won't.  Try: 
gcc -S -xc - -o - < file.c > file.s.

You could take this up with the binutils maintainers
(binutils@sources.redhat.com) but I believe there are good reasons why
this is infeasible at least for the linker.

> Along with other changes, these would make it easier to write C
> script files.  They would certainly take more time to load, but
> scripts can be more convenient at times.

You are unfortunately going to run into even more trouble trying to
get the operating system to load an executable from stdin.  Binary
executable loading works via mmap(), which cannot be applied to a
pipe.

I suggest you write a wrapper program like this (only in C - you can't
use a shell script as an #! interpreter):

---
tmpexec=`mktemp /tmp/exec.XXXXXX`
tail +2 "$1" | gcc -o "$tmpexec" -xc -
shift
"$tmpexec" "$@"; result=$?
rm -f "$tmpexec"
exit $result
---

that should do what you want.

zw

Re: Shebang

[Paul Jarc]

Zack Weinberg <zack@codesourcery.com> wrote:
> I think #! is a constraint violation, which requires a diagnostic,
> unfortunately.

There could be an option that specifies "this is a C script; ignore
the initial #! line".  gcc would be nonconforming in that mode, but
still conforming without that option.  But the wrapper you suggest may
be better anyway.

> I suggest you write a wrapper program like this (only in C - you can't
> use a shell script as an #! interpreter):

But you can do:
#!/usr/bin/env shell-script
... input interpreted by shell-script here ...


paul

Re: Shebang

[Ian Lance Taylor]

Zack Weinberg <zack@codesourcery.com> writes:

> > Also, are there reasons gcc won't compile directly from stdin to
> > stdout? 
> 
> GCC will, actually; it's the assembler and linker that won't.  Try: 
> gcc -S -xc - -o - < file.c > file.s.
> 
> You could take this up with the binutils maintainers
> (binutils@sources.redhat.com) but I believe there are good reasons why
> this is infeasible at least for the linker.

It's feasible, for some definition of feasible.  It's merely
inefficient.  You have to either hold the entire output file in
memory, or you have to process each input file several times.

Ian

Re: Shebang

[cgd]

Totally off topic, but...

At Mon, 8 Mar 2004 20:50:13 +0000 (UTC), prj@po.cwru.edu wrote:
> > I suggest you write a wrapper program like this (only in C - you can't
> > use a shell script as an #! interpreter):
> 
> But you can do:
> #!/usr/bin/env shell-script
> ... input interpreted by shell-script here ...

AFAIK not portably you can't:

217 [ldt-sj3-010] tmp % cat > shcat
#!/bin/sh
while read x; do
        echo $x;
done
218 [ldt-sj3-010] tmp % chmod +x !$
chmod +x shcat
219 [ldt-sj3-010] tmp % shcat
foo
foo
220 [ldt-sj3-010] tmp % cat > doshcat
#!/usr/bin/env shcat
foo
bar
221 [ldt-sj3-010] tmp % chmod +x doshcat 
222 [ldt-sj3-010] tmp % ./doshcat 
223 [ldt-sj3-010] tmp % ./doshcat
blah                                    <- entered on stdin
blah
224 [ldt-sj3-010] tmp % 

(that's on a linux system.)

To quote the solaris manual page for execve:

     An interpreter file begins with a line of the form

          #! pathname [arg]


     where pathname is the path of the interpreter, and arg is an
     optional argument. When an interpreter file is executed, the
     system  invokes  the  specified  interpreter.  The  pathname
     specified  in  the interpreter file is passed as arg0 to the
     interpreter. If arg was specified in the  interpreter  file,
     it is passed as arg1 to the interpreter. The remaining argu-
     ments to the interpreter are arg0 through argn of the origi-
     nally  exec'd  file.  The interpreter named by pathname must
     not be an interpreter file.

note that last sentence.

I forget the exact rules of this (it's been, oh, 8 years since i last
touched the script exec code I wrote for NetBSD), but in a nutshell,
"no."  8-)


chris

Re: Shebang

[Paul Jarc]

cgd@broadcom.com wrote:
> At Mon, 8 Mar 2004 20:50:13 +0000 (UTC), prj@po.cwru.edu wrote:
>> But you can do:
>> #!/usr/bin/env shell-script
>> ... input interpreted by shell-script here ...
...
> To quote the solaris manual page for execve:
...
>      The interpreter named by pathname must
>      not be an interpreter file.

Right.  That's why I used /usr/bin/env - which is a binary, not a
script - as the interpreter.  The rule prohibits using a script
*directly* as an interpeter of another script; that's why I wedge env
in between, to work around that rule.  When you call exec on the
meta-script, the kernel has no idea that env's argument is another
script, or that it will be exec'ed in turn.  The kernel just checks
that env itself is not a script.


paul

Re: Shebang

[cgd]

At Mon, 08 Mar 2004 17:33:44 -0500, prj@po.cwru.edu wrote:
> cgd@broadcom.com wrote:
> > At Mon, 8 Mar 2004 20:50:13 +0000 (UTC), prj@po.cwru.edu wrote:
> >> But you can do:
> >> #!/usr/bin/env shell-script
> >> ... input interpreted by shell-script here ...
> ...
> > To quote the solaris manual page for execve:
> ...
> >      The interpreter named by pathname must
> >      not be an interpreter file.
> 
> Right.  That's why I used /usr/bin/env - which is a binary, not a
> script - as the interpreter.  The rule prohibits using a script
> *directly* as an interpeter of another script; that's why I wedge env
> in between, to work around that rule.

yeah, quoting the manual page was a red herring.


anyway if you look at the example I pasted, your trick obviously
doesn't work on linux with /bin/sh...

I just tried solaris, too, same result.

it's not portable.

(where does it work for you?)



cgd

Re: Shebang

[Paul Jarc]

cgd@broadcom.com wrote:
> anyway if you look at the example I pasted, your trick obviously
> doesn't work on linux with /bin/sh...

No, it works.  Your test script isn't quite right: shcat is reading
from stdin, ignoring its arguments.  If you use this version, I think
you'll find that it works everywhere:
#!/bin/sh
while read x; do
  echo "$x"
done < "$1"

Or simply:
#!/bin/sh
exec cat ${1+"$@"}


paul

Re: Shebang

[cgd]

At Mon, 8 Mar 2004 22:47:12 +0000 (UTC), prj@po.cwru.edu wrote:
> No, it works.  Your test script isn't quite right: shcat is reading
> from stdin, ignoring its arguments.  If you use this version, I think
> you'll find that it works everywhere:

ahh, yes, that should work.

(of course, you didn't mention that detail in your initial msg, at
least, as far as I noticed...  i parsed "input interpreted.." as
"standard input..." and you said nothing different.  8-)


cgd

Re: Shebang

[Andreas Schwab]

cgd@broadcom.com writes:

> Totally off topic, but...
>
> At Mon, 8 Mar 2004 20:50:13 +0000 (UTC), prj@po.cwru.edu wrote:
>> > I suggest you write a wrapper program like this (only in C - you can't
>> > use a shell script as an #! interpreter):
>> 
>> But you can do:
>> #!/usr/bin/env shell-script
>> ... input interpreted by shell-script here ...
>
> AFAIK not portably you can't:
>
> 217 [ldt-sj3-010] tmp % cat > shcat
> #!/bin/sh
> while read x; do
>         echo $x;
> done
> 218 [ldt-sj3-010] tmp % chmod +x !$
> chmod +x shcat
> 219 [ldt-sj3-010] tmp % shcat
> foo
> foo
> 220 [ldt-sj3-010] tmp % cat > doshcat
> #!/usr/bin/env shcat
> foo
> bar
> 221 [ldt-sj3-010] tmp % chmod +x doshcat 
> 222 [ldt-sj3-010] tmp % ./doshcat 
> 223 [ldt-sj3-010] tmp % ./doshcat
> blah                                    <- entered on stdin
> blah
> 224 [ldt-sj3-010] tmp % 

Not sure what you are trying to show, but "./doshcat" is equivalent to
"/usr/bin/env shcat ./doshcat", which is the same as "shcat ./doshcat",
which looks exactly what Paul is trying to achieve.

> To quote the solaris manual page for execve:
>
>      An interpreter file begins with a line of the form
>
>           #! pathname [arg]
>
>
>      where pathname is the path of the interpreter, and arg is an
>      optional argument. When an interpreter file is executed, the
>      system  invokes  the  specified  interpreter.  The  pathname
>      specified  in  the interpreter file is passed as arg0 to the
>      interpreter. If arg was specified in the  interpreter  file,
>      it is passed as arg1 to the interpreter. The remaining argu-
>      ments to the interpreter are arg0 through argn of the origi-
>      nally  exec'd  file.  The interpreter named by pathname must
>      not be an interpreter file.
>
> note that last sentence.

None of the interpreters in your example are shebang scripts.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."