levy@ttrdc.UUCP (07/20/86)
I have been continually frustrated by a quirk in a Eunice system that I must sometimes program under (no flames about get a real Unix, I DO have real Unix available but for the things which are stuck under VMS, Eunice makes our life a bit easier there, IF you steer around the bugs...). The problem is that Eunice Bourne shell scripts and interactive Bourne shells do not seem to inherit the environment from which they were spawned. They do inherit certain environment variables which come from system logical names (things like PATH, for instance). For example the command % printenv results in the output HOME=/udev6/levy PATH=/udev6/levy/bin:/lbin:/usr/ucb:/bin:/usr/bin:/usr/eun:/cadbin:.: TERM=5420 AS_IMAGE=/bin/unixas LD_IMAGE=/bin/unixld PUB=/usr/spool/uucppublic whereas the command % sh -c printenv results in the output HOME=UD6:[LEVY] PATH=:/lbin:/usr/ucb:/bin:/usr/bin:/usr/eun:/cadbin <-- system logical name PS1=!$ SHELL_START=XENVMAIN Also, Bourne shell scripts will behave as if the environment is the latter, not the former, which means they do not find commands in my own $HOME/bin directory, for instance, and that a recursive script such as #!/bin/sh if test -z "$DEPTH" then DEPTH=1 export DEPTH fi DEPTH=`expr $DEPTH + 1` # #do a step of a recursive procedure here, which #exits when finished at the correct depth, otherwise #executes the following: # if test $DEPTH -lt 20 then $0 $* else echo Nested too deep. >&2 exit 1 fi will not work as intended at all (DEPTH never gets to the spawned shells). While I can think of workarounds for just about every difficulty which results from this (pass things as arguments, modify shell scripts to read some startup temp file when invoked from a C program, etc. etc.) they are a pain in the **bleep**. Now if someone out there using Eunice DOES have Bourne shells or Bourne shell scripts which understand the environment they came from, I would very much like to know how that is made possible if you know, or at the least see the output of something which might give me a clue such as "$ SHOW LOGICAL" under DCL, as well as the output of a "printenv" from csh and a "sh -c printenv" from the same csh. I don't have much info on the version of Eunice except that we are running it under VMS V4.3 and that it has long-file-name capability (none of that HSH*.HSH and HSH*.HSN garbage of earlier Eunices), and that it is a BSD 4.1 emulation. Thanks, thanks, thanks, thanks, ADthanksVANCE! -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
levy@ttrdc.UUCP (Daniel R. Levy) (07/23/86)
In article <1073@ttrdc.UUCP>, levy@ttrdc.UUCP (that's me!) writes: >I have been continually frustrated by a quirk in a Eunice system that I must >sometimes program under.... >The problem is that >Eunice Bourne shell scripts and interactive Bourne shells do not seem to >inherit the environment from which they were spawned. My sincere apologies to all of you out there scratching your heads over this because your Eunice Bourne shells all inherit the environment OK. It turns out that, for reasons and causes I won't get into (other than it it wasn't MY fault I didn't know...) a nonstandard /bin/sh was installed on our Eunice system. Trying the /bin/sh from the Wollongong tapes fixed the problem beautifully. Egg on my face.... -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy