Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
From: jeffdbREMOVETHIS AT goodnet DOT com (Mikey)
To: Christopher Faylor <cgf AT cygnus DOT com>, cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Here documents in ash shell scripts mess up stdin on 9x
Date: Mon, 15 Feb 1999 06:05:28 GMT
Organization: Never
Reply-To: jeffdbREMOVETHIS AT goodnet DOT com
Message-ID: <36c7a78d.23637243@mail.goodnet.com>
References: <19990214224355 DOT B6554 AT cygnus DOT com>
In-Reply-To: <19990214224355.B6554@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

You must be looking at different sources than I am.
this is from
FTP directory /pub/sourceware.cygnus.com/cygwin/cygwin-b19/ at go.cygnus.com
a fresh download/untar

Mikey:/c/tmp/ash-linux-0.2$ grep -n SHINIT *
main.c:159:     } else if ((sflag || minusc) && (shinit = getenv("SHINIT")) != N
ULL) {
sh.1:159:If the environment variable SHINIT is set on entry to the shell,
sh.1:160:the commands in SHINIT are normally parsed and executed.  SHINIT is
Mikey:/c/tmp/ash-linux-0.2$

CVS
CVS/Entries
CVS/Repository
LINUX.DIFFS
Makefile
README.Linux
TOUR
b.c
bltin
bltin/CVS
bltin/CVS/Entries
bltin/CVS/Repository
bltin/bltin.h
bltin/echo.1
bltin/echo.c
bltin/test.c
builtins
cd.c
dirent.c
errmsg.c
errmsg.h
error.c
error.h
eval.c
eval.h
exec.c
exec.h
expand.c
expand.h
funcs
funcs/CVS
funcs/CVS/Entries
funcs/CVS/Repository
funcs/cmv
funcs/dirs
funcs/kill
funcs/login
funcs/newgrp
funcs/popd
funcs/pushd
funcs/suspend
init.h
input.c
input.h
jobs.c
jobs.h
machdep.h
mail.c
mail.h
main.c
main.h
memalloc.c
memalloc.h
miscbltin.c
mkbuiltins
mkinit.c
mknodes.c
mksyntax.c
mktokens
mt
mystring.c
mystring.h
nodes.c.pat
nodetypes
options.c
options.h
output.c
output.h
parser.c
parser.h
redir.c
redir.h
sh.1
shell.h
show.c
trap.c
trap.h
var.c
var.h

and this is what I get in .../src/ash

ChangeLog.Cygnus
Makefile.cygwin32
Makefile.debian
TOUR
aclocal.m4
alias.c
alias.h
arith.c
arith.h
arith.y
arith_lex.c
arith_lex.l
bltin
bltin/bltin.h
bltin/echo.1
bltin/echo.c
bltin/test.c
builtins.c
builtins.def
builtins.h
cd.c
cd.h
configure
configure.in
debian
debian/README.debian
debian/changelog
debian/control
debian/copyright
debian/dirs
debian/rules
error.c
error.h
eval.c
eval.h
exec.c
exec.h
expand.c
expand.h
funcs
funcs/cmv
funcs/dirs
funcs/kill
funcs/login
funcs/newgrp
funcs/popd
funcs/pushd
funcs/suspend
histedit.c
init.c
init.h
input.c
input.h
jobs.c
jobs.h
machdep.h
mail.c
mail.h
main.c
main.h
memalloc.c
memalloc.h
miscbltin.c
miscbltin.h
mkbuiltins
mkinit.c
mknodes.c
mksignames.c
mksyntax.c
mktokens
myhistedit.h
mystring.c
mystring.h
nodes.c
nodes.h
nodetypes
options.c
options.h
output.c
output.h
parser.c
parser.h
redir.c
redir.h
setmode.c
sh.1
shell.h
show.c
show.h
signames.h
syntax.c
syntax.h
token.h
trap.c
trap.h
var.c
var.h
y.tab.h

where did the files arith.c arith.h arith_lex.c arith.y arith.l come from?
what would you call them if not command line math
functions?
Or possibly arithmetic substitution functions?
Regardless what are they doing in a shell
that is there strictly for speed in configure/compile?

And what does any of this have to do with the BUG
that I pointed out in the first place?

On Sun, 14 Feb 1999 22:43:55 -0500, you wrote:

>On Sun, Feb 14, 1999 at 08:15:04AM +0000, Mikey wrote:
>>On Sun, 14 Feb 1999 00:41:31 -0500, you wrote:
>>
>>>On Sun, Feb 14, 1999 at 02:16:44AM +0000, Mikey wrote:
>>>>The subject is here documents in ash, not ash bugs in general.
>>>>
>>>>The other bug that I noticed that caused me to go back to B19 ash is
>>>>that B20 ash fails to read/execute $SHINIT, which is how I get it to
>>>>read ~/.shrc on startup.
>>>>
>>>>Sorry Chris, I know you did most of the work on "upgrading" ash, but I
>>>>really can't see the point to adding console math functions in an sh
>>>>compatible shell.  I don't recall them being there in svr4, but maybe
>>>>my memory is bad?
>>>
>>>It's possible, if you think that /bin/sh should do something with a
>>>SHINIT variable.  That's not standard behavior.
>>
>>from the ash man page
>>
>>    If the first character of argument zero to  the  shell  is
>>    ``-'',  the  shell is assumed to be a login shell, and the
>>    files /etc/profile and .profile are read  if  they  exist.
>>    If  the environment variable SHINIT is set on entry to the
>>    shell, the commands in SHINIT are normally parsed and exe-
>>    cuted.   SHINIT  is  not  examined if the shell is a login
>>    shell, or if it the shell is running  a  shell  procedure.
>>    (A  shell is considered to be running a shell procedure if
>>    neither the -s nor the -c options are set.)
>
>>I don't know what happened, but $SHINIT stopped being
>>parsed when B20 came out.  I have never been able to get ash to parse
>>~/.profile, which is why I used $SHINIT.  At one time console handling
>>was so slow with bash on 95 that I used sh as my login shell
>>exclusively.  Happily this is no longer the case.
>
>I really must be missing something here.  I just went back to the
>sources that went into building the B19 version of ash.  There was no
>occurrence of the string SHINIT in any of the files.  There is also no
>SHINIT mentioned in the man page that is in the ash source directory.
>
>I actually can't find an ASH man page anywhere in the man tar files.
>
>Regardless of this fact, the SHINIT environment variable is not a
>standard feature of a /bin/sh.
>
>FYI, I also don't find a difference between the B19 release of ASH
>and the B20 release as far as adding any math functions are concerned.
>
>The changes seem to be pretty minimal, actually.
>
>>>If I inadvertantly added "console math functions" then it was
>>>inattention on my part when I merged the Debian changes.  I will take a
>>>look at stripping out any baggage that I added.
>>>
>>>I've seen people complaining about the supposed HERE document problems
>>>in ash on Windows 95.  So far that is the only problem I've heard that
>>>sounds remotely like a real problem.  Most of the other "problems"
>>>are complaints from people who think that ash should behave exactly
>>>the same way as bash except for being smaller and faster.
>>
>>If you add readline support to ash I will personally tweak all your bits!! ;^)
>
>This is actually one of the things that I missed.  There is a little bit of
>line editing capability in ash right now.  Expect it to disappear in B21.
>
>-chris