Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.bugs.sys5
Subject: Re: ksh bugs
Keywords: ksh
Message-ID: <960@virtech.UUCP>
Date: 8 Aug 89 01:31:18 GMT
References: <10166@fluke.COM>
Distribution: na
Organization: Virtual Technologies Inc
Lines: 28

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