foot@tc.fluke.COM (Andrew Proudfoot) (08/07/89)
We got ksh (the RELEASE file says it's the 6/15/88 version) from the
AT&T toolchest recently, and installed it on our Suns and Vaxes. It
appears to have several bugs, though of course they may be the result
of faulty installation. I haven't been watching this newsgroup
until now, and would appreciate copies of patches that have been
posted for these (or other) bugs. Sorry if this rehashes old material.
Here are the bugs we've seen so far:
1. When no result variable is explicitly provided, the "read"
command is supposed to store the line it reads in the REPLY
variable. But a "read" call without an explicit result variable
dumps core on our Suns (works OK on a Vax).
2. the "read" command does filename expansion on its input!
Just filename expansion; it doesn't do quote removal or tilde expansion.
This happens only on the Suns, not on the Vaxes.
$ ls /usr0/foot/xx
file1 file2 file3
$ ls ~foot/xx
file1 file2 file3
$ while read stuff; do echo $stuff; done << EOF
> ~foot/xx/*
> '/usr0/foot/xx/*'
> /usr0/foot/xx/*
> EOF
~foot/xx/*
'/usr0/foot/xx/*'
/usr0/foot/xx/file1 /usr0/foot/xx/file2 /usr0/foot/xx/file3
3. One large ksh script, when run by certain users on certain input,
reports that it can't create new files in a writable directory,
can't find commands that are in the search path, and can't even find
commands for which correct full pathnames (like /bin/cp) are
specified. Seemingly irrelevant changes to the script, such as the
addition of some "pwd" calls, can make the problem go away. Unlike
the first two bugs, this one does occur on the Vaxes (not sure if it
happens on the Suns).
Andy Proudfoot || domain: foot@tc.fluke.COM
John Fluke Mfg. Co., M/S 223B || uucp: {uw-beaver,microsof,sun}!fluke!foot
PO Box C9090 ||
Everett, WA 98206 || phone: (206) 356-5446cpcahil@virtech.UUCP (Conor P. Cahill) (08/08/89)
In article <10166@fluke.COM>, foot@tc.fluke.COM (Andrew Proudfoot) writes: > 2. the "read" command does filename expansion on its input! > Just filename expansion; it doesn't do quote removal or tilde expansion. > This happens only on the Suns, not on the Vaxes. This is not a symptom of a problem in the ksh. This is the expected behavior of the bourne & korn shells. The expansion is not by the "read" but by the shell as it is reading the "heredocument". If you do not want the meta characters expanded you can escape them, or you can turn off all shell processing of the input data by escaping a character in the definition of the end of the here document. For example: while read.... done << \EOF ... EOF > 3. One large ksh script, when run by certain users on certain input, > reports that it can't create new files in a writable directory, > can't find commands that are in the search path, and can't even find > commands for which correct full pathnames (like /bin/cp) are > specified. Seemingly irrelevant changes to the script, such as the > addition of some "pwd" calls, can make the problem go away. Unlike > the first two bugs, this one does occur on the Vaxes (not sure if it > happens on the Suns). I have seen similar types of unexplained problems when the environment variables take up > 5K or so of data space. I don't know the mechanism, nor a fix (other than shortening the environment).
naftoli@aecom.yu.edu (Robert N. Berlinger) (08/08/89)
In article <10166@fluke.COM>, foot@tc.fluke.COM (Andrew Proudfoot) writes: > > We got ksh (the RELEASE file says it's the 6/15/88 version) from the > AT&T toolchest recently, and installed it on our Suns and Vaxes. It > appears to have several bugs, though of course they may be the result > of faulty installation. One bug that I know exists in that distribution is in the cd command: you can't cd to directories that have a ':' in the name without some really weird behavior (I can post the exact circumstances if anyone's interested). I called the toolchest about the problem and they relayed it to David Korn. He sent me a patch right away, and after some tweaking on my part, did the trick. So if you're having problems, it's worth it to call them, even the software is considered unsupported. I believe he IS interested in receiving all bug reports, and his email address is included with the distribution somewhere. -- Robert N. Berlinger |Domain: naftoli@aecom.yu.edu Supervisor of Systems Support |UUCP: {uunet}!aecom!naftoli Scientific Computing Center |CompuServe: 73047,741 GEnie: R.Berlinger Albert Einstein College of Medicine |Pan: berlinger AppleLink: U0995
woods@cbnewsc.ATT.COM (Warren D. Swan) (08/09/89)
In article <10166@fluke.COM> foot@tc.fluke.COM (Andrew Proudfoot) writes: >2. the "read" command does filename expansion on its input! > Just filename expansion; it doesn't do quote removal or tilde expansion. > This happens only on the Suns, not on the Vaxes. > > $ ls /usr0/foot/xx > file1 file2 file3 > $ ls ~foot/xx > file1 file2 file3 > $ while read stuff; do echo $stuff; done << EOF > > ~foot/xx/* > > '/usr0/foot/xx/*' > > /usr0/foot/xx/* > > EOF > ~foot/xx/* > '/usr0/foot/xx/*' > /usr0/foot/xx/file1 /usr0/foot/xx/file2 /usr0/foot/xx/file3 The other two sound like problems, but this one definitely isn't. This is not the read statement doing filename expansion. Nor is it, as someone ludicrously suggested without checking, the here document doing filename expansions, because the shell only does $ expansion on here documents [unless the sentinel (EOF) is quoted, even partially ('EOF' or \EOF)], NOT ` or filename expansions. The problem is in your reference to $stuff. One of the first rules of shell programming ought to be: Always quote any expansion of an environment or shell variable (unless you WANT something like the above to happen). Just change your while loop to read: $ while read stuff; do echo "$stuff"; done <<EOF ... You see, the shell does filename expansion AFTER doing $ expansion. So $stuff is being replaced with /usr0/foot/xx/*, which is then expanded by the shell, and the individual arguments are then handed to echo. Try this: JUNK='*' # (I use quotes to delay another long discussion here, but they're # not needed. JUNK=* would do the same thing.) echo $JUNK # "Weeeee. Lookah my files." echo "$JUNK" # "What a pretty little star!" Have fun, Warren D. Swan (WooDS) Y n n ____ __ You can't tell which way a train AT&T Bell Laboratories -(((((([__]/__] went by looking at the tracks. Naperville, Illinois /o-OOOOO~~ oo att!cblph!woods ##################### FRISCO 1630 Decapod (2-10-0) IRM
foot@tc.fluke.COM (Andrew Proudfoot) (08/10/89)
In article <10166@fluke.COM>, I wrote: > > >2. the "read" command does filename expansion on its input! > Just filename expansion; it doesn't do quote removal or tilde expansion. > This happens only on the Suns, not on the Vaxes. > > $ ls /usr0/foot/xx > file1 file2 file3 > $ while read stuff; do echo $stuff; done << EOF > > /usr0/foot/xx/* > > EOF > /usr0/foot/xx/file1 /usr0/foot/xx/file2 /usr0/foot/xx/file3 > No, wait, turn off the flamethrowers!! I was confused. This is normal behavior, not a bug, and it really does work the same on both our Suns and our Vaxes. The filename expansion isn't happening when the "read" command is interpreted, but when the "echo" command is: echo $stuff => echo /usr0/foot/xx/* (parameter substitution) => echo /usr0/foot/xx/file1... (filename generation) Items 1 and 3 still look like bugs to me, however. I'll talk to the toolchest people, as suggested by one of the repliers. Andy Proudfoot || domain: foot@tc.fluke.COM John Fluke Mfg. Co., M/S 223B || uucp: {uw-beaver,microsof,sun}!fluke!foot PO Box C9090 || Everett, WA 98206 || phone: (206) 356-5446
guy@auspex.auspex.com (Guy Harris) (08/17/89)
>Nor is it, as someone ludicrously suggested without checking, the here >document doing filename expansions, because the shell only does $ expansion >on here documents [unless the sentinel (EOF) is quoted, even partially >('EOF' or \EOF)], NOT ` or filename expansions. That may be true of filename expansion - I don't have a Korn shell handy to check - but it is definitely *not* true of ` expansions, which are referred to as "command substitution" in the Bourne shell manual page. At least in the S5R3 Bourne shell, command substitution is performed in here documents. (Try $ sed 's/Wed/Wednesday/' << EOF > `date` > EOF I got "Wednesday Aug 16 10:15:53 PDT 1989" printed out. This happened with both the Bourne and C shells.) You can also check the manual page: <<[-]word After parameter and command substitution is done on "word", the shell input is read up to the first line that literally matches the resulting word, or to an end-of-file. If, however, `-' is appended to <<: 1) leading tabs are stripped from "word" before the shell input is read (but after parameter and command substitution is done on "word"), 2) leading tabs are stripped from the shell input as it is read and before each line is compared with "word", and 3) shell input is read up to the first line that literally matches the resulting "word", or to an end-of-file. If any character of "word" is quoted (see "Quoting", later), no additional processing is done to the shell input. If no characters of word are quoted: 1) parameter and command substitution occurs, 2) (escaped) \new-line is ignored, and 3) \ must be used to quote the characters \, $, and `. The resulting document becomes the standard input. or you can check the code, and they all agree that command substitution *IS* done in here documents. If the Korn shell doesn't do command substitution in here documents, I would consider that to be a bug, since the Bourne shell does it....
r4@cbnews.ATT.COM (richard.r.grady..jr) (08/17/89)
In article <2363@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Nor is it, as someone ludicrously suggested without checking, the here >>document doing filename expansions, because the shell only does $ expansion >>on here documents [unless the sentinel (EOF) is quoted, even partially >>('EOF' or \EOF)], NOT ` or filename expansions. > >That may be true of filename expansion - I don't have a Korn shell handy >to check - but it is definitely *not* true of ` expansions, which are >referred to as "command substitution" in the Bourne shell manual page. >At least in the S5R3 Bourne shell, command substitution is performed in >here documents. (Try > > $ sed 's/Wed/Wednesday/' << EOF > > `date` > > EOF > >I got "Wednesday Aug 16 10:15:53 PDT 1989" printed out. This happened >with both the Bourne and C shells.) I do have access to a Korn shell, so I can confirm what Guy says about command substitutions. I tried the above sed command on two separate computers with Korn shell, one running version 06/03/86a of ksh and the other version 11/16/88a. In both cases, "Wed" was expanded to "Wednesday", showing that the `date` was substituted OK. Filename expansion, however, is not done: $ ls News a.out cls terms zzz.c $ cat << EOF > * > EOF * $ ------------------------------------------------------------------- Dick Grady r_r_grady@att.com ...!att!mvuxd!r4
foot@tc.fluke.COM (Andrew Proudfoot) (08/17/89)
The three problems I reported recently are all resolved. My thanks to everyone who replied. Here's the deal: > >1. When no result variable is explicitly provided, the "read" > command is supposed to store the line it reads in the REPLY > variable. But a "read" call without an explicit result variable > dumps core on our Suns (works OK on a Vax). Dave Korn says this is fixed in the "point" release, which should be available from the Toolchest soon if it isn't already. My understanding is that these minor releases are relatively cheap if you've already bought the most recent major release, but I haven't confirmed this. >2. the "read" command does filename expansion on its input! ... This was not a bug, just misinterpretation of normal behavior. Sorry! >3. One large ksh script, when run by certain users on certain input, > reports that it can't create new files in a writable directory, > can't find commands that are in the search path, and can't even find > commands for which correct full pathnames (like /bin/cp) are > specified... I've narrowed this problem down since the initial posting. It only occurs when PWD is not set in the environment of the user running the ksh script. Csh users here don't generally have PWD set, so they're the ones that get burned. A simple test script shows the problem: (running csh) % cat toy.ksh Contents of script #!/usr/local/ksh -x tdir=tdir$$ mkdir $tdir cd $tdir cd .. echo hello > $tdir/xx rm -rf $tdir % setenv PWD `pwd` Show PWD is set % echo $PWD /pandora/usr2/rhody/792A/bom/xxx % toy.ksh Script runs OK + tdir=tdir5238 + mkdir tdir5238 + cd tdir5238 + cd .. + echo hello + 1> tdir5238/xx + rm -rf tdir5238 % unsetenv PWD Unset PWD % echo $PWD PWD: Undefined variable. % toy.ksh Script breaks + tdir=tdir5255 + mkdir tdir5255 + cd tdir5255 + cd .. + echo hello + toy.ksh[7]: tdir5255/xx: cannot create + rm -rf tdir5255 toy.ksh[8]: rm: not found A workaround is to start your scripts with something like: if [ -z "$PWD" ]; then PWD=`/bin/pwd`; export PWD; fi Korn says the point release includes repairs to the PWD initialization code that he made to cure other symptoms, and that he *believes* this will fix my bug as well. Andy Proudfoot || domain: foot@tc.fluke.COM John Fluke Mfg. Co., M/S 223B || uucp: {uw-beaver,microsof,sun}!fluke!foot PO Box C9090 || Everett, WA 98206 || phone: (206) 356-5446
clay@uci.UUCP (News Administrator) (08/19/89)
Has anybody used the Korn shell for "unsharing"? I tried it with the Microport Korn shell, expecting a speed increase, but found just the opposite. It did work, but was MUCH slower. -- Clayton Haapala ...!mmm!dicome!uci!clay Unified Communications Inc. 3001 Metro Drive - Suite 500 "Revenge is better than Christmas" Bloomington, MN 55425 -- Elvira
cpcahil@virtech.UUCP (Conor P. Cahill) (08/21/89)
In article <177@uci.UUCP>, clay@uci.UUCP (News Administrator) writes: > > Has anybody used the Korn shell for "unsharing"? I tried it with the > Microport Korn shell, expecting a speed increase, but found just the opposite. > It did work, but was MUCH slower. As I understand it, the capabilities of the korn shell that make it run some shell commands (and command files) faster is that it has more built-ins than the standard shell. For example the korn shell has a built-in for the echo command, built-in math operators and other such stuff. However the cost of these additional built-ins (along with the command history, command line editing, etc...) is that the ksh is a much larger executable which takes longer to load. This is probably why it is slower for processing a shar. Another reason may be that you use the "ENV" mechanism of causing sub-shells to read and process the .profile equivalent named in the ENV environment variable. Since shar's are set to work on most standard bourne shells I just use "sh sharfile" whenever I am un-sharring a file.
tneff@bfmny0.UUCP (Tom Neff) (08/21/89)
In article <1035@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: [why KSH can fork slower] >Another reason may be that you use the "ENV" mechanism of causing sub-shells >to read and process the .profile equivalent named in the ENV environment >variable. This is usually the cause. A workaround suggested in K&B or the AT&T man page, I forget which, is this line (taken from my .profile): export Envfile=$HOME/.env export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}' This has the effect of nulling $ENV unless your copy of ksh was invoked interactively -- so shelldowns and such run much faster. -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
guy@auspex.auspex.com (Guy Harris) (08/22/89)
>As I understand it, the capabilities of the korn shell that make it run >some shell commands (and command files) faster is that it has more built-ins >than the standard shell. For example the korn shell has a built-in for >the echo command, built-in math operators and other such stuff. "echo" (and "test") have been built into the Bourne shell since at least S5R2, and possibly since S3. Math operators haven't been built into any AT&T-distributed Bourne shell, though.
friedl@vsi.COM (Stephen J. Friedl) (08/22/89)
In article <14571@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}' Hey, cool! I didn't know that ksh had a built-in APL interpreter! Steve :-) P.S. - or is that sed script? -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / {attmail uunet}!vsi!{bang!}friedl / friedl@vsi.com "Diet Mountain Dew has the same pH and density of urine." - Newsweek, 31-Jul-89
tneff@bfmny0.UUCP (Tom Neff) (08/22/89)
In article <1170@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >In article <14571@bfmny0.UU.NET>, tneff@bfmny0.UU.NET (Tom Neff) writes: > >> export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}' > >Hey, cool! I didn't know that ksh had a built-in APL interpreter! > >P.S. - or is that sed script? Actually it's a subscript expression, which evaluates to either $Envfile or the null string depending on whether $- (the current flags) has an "i" (for interactive) in it or not. Admittedly it looks like gobbledygook. But it also shows how cute you can get in Korn shell. If I hadn't seen the expression my .profile would say case $- in *i*) export ENV=$Envfile ;; *) export ENV="" ;; esac In fact it probably should anyway. :-) -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
rob@PacBell.COM (Rob Bernardo) (08/23/89)
In article <14579@bfmny0.UUCP> tneff@bfmny0.UU.NET (Tom Neff) writes: +In article <1170@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: +>In article <14571@bfmny0.UU.NET>, tneff@bfmny0.UU.NET (Tom Neff) writes: +> +>> export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}' +> +>Hey, cool! I didn't know that ksh had a built-in APL interpreter! +> +>P.S. - or is that sed script? + +Actually it's a subscript expression, which evaluates to either $Envfile +or the null string depending on whether $- (the current flags) has an "i" +(for interactive) in it or not. Admittedly it looks like gobbledygook. +But it also shows how cute you can get in Korn shell. + +If I hadn't seen the expression my .profile would say + + case $- in + *i*) export ENV=$Envfile ;; + *) export ENV="" ;; + esac + +In fact it probably should anyway. :-) No you shouldn't have! :-) It wouldn't work. If you had that in your .profile, $- would *always* have an 'i' in it, and your ENV file would always be set to to $Envfile and never to the null string. One reason why the "gobbledygook" solution works is that two environmental variables ENV and PS1 are special in ksh insofar as they get evaluated when *used*! Notice that there are single quotes around the gobbledygook value that ENV is first set to. Therefore the value is not immediately evaluated (i.e. not evaluated when ENV is *set*). But it will be evaluated when ENV is *used*, namely when ksh is exec'd. So if the particular exec'd ksh is interactive, ENV will be set to $Envfile, if not interactive, it will be null. -- Rob Bernardo ...![backbone]!pacbell!pbhyf!rob -or- rob@pbhyf.PacBell.COM Product engineer, UNIX/C Reusable Code Library Editor, "Go `C' UNIX" Office: (415) 823-2417 Pacific * Bell, San Ramon, California Residence: (415) 827-4301 R BAR JB, Concord, California