🚀 go-pugleaf

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).

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

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

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

>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....

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 

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

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

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.

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

 >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. 

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

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

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

I also like this in my ENV file (.kshrc):


	case "$-" in
		*i*)
			#interactive shell stuff here
	esac

I can't remember though, is it "case expr in" or "case expr of".  Oh well.
This is probably slower than the tweak to not bother invoking ENV, but
is A LOT easier to explain to novices who want to use ksh.


-- 
Scott "The Pseudo-Hacker" Neugroschl
UUCP:  ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge
-- Beat me, Whip me, make me code in Ada
-- Disclaimers?  We don't need no stinking disclaimers!!!