* #!/path/to/arch-indep/zsh -f @ 1999-09-22 1:23 Clint Olsen 1999-09-22 7:59 ` Peter Stephenson 1999-09-22 9:13 ` Bart Schaefer 0 siblings, 2 replies; 9+ messages in thread From: Clint Olsen @ 1999-09-22 1:23 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 1:23 #!/path/to/arch-indep/zsh -f Clint Olsen @ 1999-09-22 7:59 ` Peter Stephenson 1999-09-22 8:58 ` Clint Olsen 1999-09-22 9:13 ` Bart Schaefer 1 sibling, 1 reply; 9+ messages in thread From: Peter Stephenson @ 1999-09-22 7:59 UTC (permalink / raw) To: Clint Olsen, Zsh hackers list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 7:59 ` Peter Stephenson @ 1999-09-22 8:58 ` Clint Olsen 1999-09-22 8:33 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Clint Olsen @ 1999-09-22 8:58 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 8:58 ` Clint Olsen @ 1999-09-22 8:33 ` Peter Stephenson 1999-09-22 16:39 ` Clint Olsen 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 1999-09-22 8:33 UTC (permalink / raw) To: zsh-workers, Clint Olsen 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 8:33 ` Peter Stephenson @ 1999-09-22 16:39 ` Clint Olsen 1999-09-23 16:42 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Clint Olsen @ 1999-09-22 16:39 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 16:39 ` Clint Olsen @ 1999-09-23 16:42 ` Bart Schaefer 0 siblings, 0 replies; 9+ messages in thread From: Bart Schaefer @ 1999-09-23 16:42 UTC (permalink / raw) To: Clint Olsen, zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 1:23 #!/path/to/arch-indep/zsh -f Clint Olsen 1999-09-22 7:59 ` Peter Stephenson @ 1999-09-22 9:13 ` Bart Schaefer 1999-09-22 11:24 ` Owen M. Astley 1 sibling, 1 reply; 9+ messages in thread From: Bart Schaefer @ 1999-09-22 9:13 UTC (permalink / raw) To: Clint Olsen, zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 9:13 ` Bart Schaefer @ 1999-09-22 11:24 ` Owen M. Astley 1999-09-22 16:28 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Owen M. Astley @ 1999-09-22 11:24 UTC (permalink / raw) To: Bart Schaefer; +Cc: Clint Olsen, zsh-workers > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: #!/path/to/arch-indep/zsh -f 1999-09-22 11:24 ` Owen M. Astley @ 1999-09-22 16:28 ` Bart Schaefer 0 siblings, 0 replies; 9+ messages in thread From: Bart Schaefer @ 1999-09-22 16:28 UTC (permalink / raw) To: Owen M. Astley; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-09-23 16:56 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-22 1:23 #!/path/to/arch-indep/zsh -f Clint Olsen 1999-09-22 7:59 ` Peter Stephenson 1999-09-22 8:58 ` Clint Olsen 1999-09-22 8:33 ` Peter Stephenson 1999-09-22 16:39 ` Clint Olsen 1999-09-23 16:42 ` Bart Schaefer 1999-09-22 9:13 ` Bart Schaefer 1999-09-22 11:24 ` Owen M. Astley 1999-09-22 16:28 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).