#!/path/to/arch-indep/zsh -f

#!/path/to/arch-indep/zsh -f

[Clint Olsen]

Hello:

FYI, I'm using zsh-3.1.6.

I decided to change my script to reflect the copy of my shell, and attempt
to direct it to the path of my zsh wrapper itself causes the script to
misfire when it is executed from *csh.  I've narrowed it down to a machine
independent wrapper I have which seems to be hampering starting the
interpreter.  It is:

#!/bin/sh

if [ -f $OTOOLS/bin/$OS/zsh ]; then
  exec $OTOOLS/bin/$OS/zsh $*
else
  exec /usr/intel/bin/zsh $*
fi

Is this the most robust way to handle this?

-Clint

Re: #!/path/to/arch-indep/zsh -f

[Peter Stephenson]

Clint Olsen wrote:
> Hello:
> 
> FYI, I'm using zsh-3.1.6.
> 
> I decided to change my script to reflect the copy of my shell, and attempt
> to direct it to the path of my zsh wrapper itself causes the script to
> misfire when it is executed from *csh.  I've narrowed it down to a machine
> independent wrapper I have which seems to be hampering starting the
> interpreter.  It is:
> 
> #!/bin/sh
> 
> if [ -f $OTOOLS/bin/$OS/zsh ]; then
>   exec $OTOOLS/bin/$OS/zsh $*
> else
>   exec /usr/intel/bin/zsh $*
> fi

Well, a more specific test would be `[ -x $OTOOLS/bin/$OS/zsh ]', but if
the file's there, it's likely to be executable.  A more likely source of
problems, particularly if you are passing arguments with spaces in, in
which case it's a guaranteed source of problems, is our old friend the sh
word-splitting behaviour: for example, if you do
  zsh -c 'echo "hello there"'
the wrapper will actually in effect invoke
  zsh -c 'echo' '"hello' 'there"'
(which is bad).  To keep your arguments intact, try:

#!/bin/sh

if [ -x $OTOOLS/bin/$OS/zsh ]; then
  exec $OTOOLS/bin/$OS/zsh "$@"
else
  exec /usr/intel/bin/zsh "$@"
fi

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: #!/path/to/arch-indep/zsh -f

[Peter Stephenson]

Clint Olsen wrote:
> Ok, I gave this a try.  This doesn't seem to be my problem (this time).
> What's happening is that *csh is actually trying to run my script and
> immediately failing on the first apparent syntax error.  It's as if it
> won't fire off the interpreter correctly:
> 
> #!/afs/pdx/proj/otools/bin/zsh -f

Try using a shorter path to zsh, if that's possible.  They're often
restricted to 32 bytes, and the whole of this is 33.  But you should get
the zsh part through, so this may not be the problem either.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: #!/path/to/arch-indep/zsh -f

[Clint Olsen]

On Sep 22, Peter Stephenson wrote:
>
> Well, a more specific test would be `[ -x $OTOOLS/bin/$OS/zsh ]', but if
> the file's there, it's likely to be executable.  A more likely source of
> problems, particularly if you are passing arguments with spaces in, in
> which case it's a guaranteed source of problems, is our old friend the sh
> word-splitting behaviour: for example, if you do zsh -c 'echo "hello
> there"' the wrapper will actually in effect invoke zsh -c 'echo' '"hello'
> 'there"' (which is bad).  To keep your arguments intact, try:
> 
> #!/bin/sh
> 
> if [ -x $OTOOLS/bin/$OS/zsh ]; then
>   exec $OTOOLS/bin/$OS/zsh "$@"
> else
>   exec /usr/intel/bin/zsh "$@"
> fi

Ok, I gave this a try.  This doesn't seem to be my problem (this time).
What's happening is that *csh is actually trying to run my script and
immediately failing on the first apparent syntax error.  It's as if it
won't fire off the interpreter correctly:

#!/afs/pdx/proj/otools/bin/zsh -f

prog=${0##*/}
...
...

~% rlsci
Missing }.

As a test, I tried copying Perl to a directory of my own and running a test
with a perl script thinking it might have something to do with me owning
the interpreter.  Evidently that's not it, either.  If I eliminate the
wrapper from the equation, it seems to work fine (but then it's not very
portable).

Thanks,

-Clint

Re: #!/path/to/arch-indep/zsh -f

[Bart Schaefer]

On Sep 21,  6:23pm, Clint Olsen wrote:
} Subject: #!/path/to/arch-indep/zsh -f
}
} I decided to change my script to reflect the copy of my shell, and attempt
} to direct it to the path of my zsh wrapper itself causes the script to
} misfire when it is executed from *csh.

And the error you get is something like "exec format error", I suppose.

Most (I don't know if I can say "all") operating systems won't do two
levels of indirection via #! lines.  That is, if the thing on the #!
line is not itself a binary in executable format, the OS will not
recognize yet another #! line and launch still another interpreter.

The workaround is to write your wrapper in C and compile it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: #!/path/to/arch-indep/zsh -f

[Owen M. Astley]

> Most (I don't know if I can say "all") operating systems won't do two
> levels of indirection via #! lines.  That is, if the thing on the #!
> line is not itself a binary in executable format, the OS will not
> recognize yet another #! line and launch still another interpreter.

$ <test.sh
#!/u/pol1b/oma1000/bin/zsh

echo f
$ head -n 1 /u/pol1b/oma1000/bin/zsh
#!/bin/sh -
$ ./test.sh
f
$ reportzsh 
zsh-3.0.6 dec-alpha-osf4.0

So not on this system.  
I thought that most (all) modern operating systems recognise #!
as a magic number in exec()?

Owen

Re: #!/path/to/arch-indep/zsh -f

[Bart Schaefer]

On Sep 22, 12:24pm, Owen M. Astley wrote:
} Subject: Re: #!/path/to/arch-indep/zsh -f
}
} > Most (I don't know if I can say "all") operating systems won't do two
} > levels of indirection via #! lines.  That is, if the thing on the #!
} > line is not itself a binary in executable format, the OS will not
} > recognize yet another #! line and launch still another interpreter.
} 
} $ <test.sh
} #!/u/pol1b/oma1000/bin/zsh
} 
} echo f
} $ head -n 1 /u/pol1b/oma1000/bin/zsh
} #!/bin/sh -
} $ ./test.sh
} f
} $ reportzsh 
} zsh-3.0.6 dec-alpha-osf4.0
} 
} So not on this system.  

I can't decide if you're agreeing with me or giving a counterexample.

} I thought that most (all) modern operating systems recognise #!
} as a magic number in exec()?

They do, but not necessarily recursively.  Remember that the semantics
of the #! line are to take the name of the interpreter from the line
and run it with the name of the file as its first argument.  If the
interpreter is itself a script with a #!, that would add yet another
first argument, and so on.  The original script file might never have
its contents evaluated at all -- which could be interpreted (sorry) as
a security problem.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: #!/path/to/arch-indep/zsh -f

[Clint Olsen]

On Sep 22, Peter Stephenson wrote:
>
> > #!/afs/pdx/proj/otools/bin/zsh -f
> 
> Try using a shorter path to zsh, if that's possible.  They're often
> restricted to 32 bytes, and the whole of this is 33.  But you should get
> the zsh part through, so this may not be the problem either.

On this crappy system (AIX 4.1.X), it must be the multiple level of
indirection problem that Bart mentioned.  I also duplicated this behavior
on HP-UX 10.20.  Using the actual binary:

#!/afs/pdx/proj/otools/bin/AIX/zsh -f

instead of the wrapper seems to make it work.  Bummer...  Compiling a
wrapper program again defeats the purpose of having an
architecture-independent launch point.

-Clint

Re: #!/path/to/arch-indep/zsh -f

[Bart Schaefer]

On Sep 22,  9:39am, Clint Olsen wrote:
} Subject: Re: #!/path/to/arch-indep/zsh -f
}
} On this crappy system (AIX 4.1.X), it must be the multiple level of
} indirection problem that Bart mentioned.  [...]  Bummer...  Compiling
} a wrapper program again defeats the purpose of having an
} architecture-independent launch point.

Two remarks:

(1) This is what autoloadable shell functions are for.  If an already-
running zsh loads and executes the function, it can't possibly be the
wrong architecture.

(2) What you're really asking for is not an arch-indep launch point, but
an arch-dependent path to the shell.  You can still have that, you just
have to do your launching a slightly different way.

Here's what you do:  Take your launcher script and fix it to pass along
a modified $0 file name to zsh, like so:

#!/bin/sh

if [ -x $OTOOLS/bin/$OS/zsh ]; then
  exec $OTOOLS/bin/$OS/zsh "$0".real "$@"
else
  exec /usr/intel/bin/zsh "$0".real "$@"
fi

(Remember, you're in sh, not zsh, so $* does word-splitting; use "$@".  If
you're really paranoid, use ${1+"$@"} [some old sh turn "$@" into an empty
string if there are no arguments at all, rather than into nothing].)

Put that in ~/bin (or wherever your scripts are) and call it "launch-zsh"
or some such.

Now, for every script that you want to be able to launch this way, run

    mv $script $script.real && ln $script launch-zsh

If you don't like the ".real" extension on every file name, put the real
script in some other directory and do a more complicated replacement on
$0 in the launcher.

It's not as clean as what you originally thought of, but it'll work.  You
can even get as clever as you like with the launcher:

#!/bin/sh

ZERO=$0.real

if [ -f $ZERO ]; then
  read scratch command switches < "$ZERO"
  case "$scratch" in
  '#!') ;;
  '#!*') switches="$command"; command="$scratch";;
  *) echo 1>&2 "$0": warning: no '#!' line in "$ZERO";;
  esac
  case "$command" in
  */zsh)
    if [ -x $OTOOLS/bin/$OS/zsh ]; then
      exec $OTOOLS/bin/$OS/zsh "$switches" "$ZERO" "$@"
    else
      exec /usr/intel/bin/zsh "$switches" "$ZERO" "$@"
    fi;;
  *) echo 1>&2 "$0": "$command" is not zsh; exit 1;;
  esac
else
  echo 1>&2 "$0": launcher found no real script
  exit 1
fi

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com