Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ORION.MC.DUKE.EDU!bet
From: bet@ORION.MC.DUKE.EDU (Bennett Todd)
Newsgroups: gnu.bash.bug
Subject: Bash 1.01 IFS doesn't seem to...
Message-ID: <8907171938.AA08298@orion>
Date: 17 Jul 89 19:38:20 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 49

I haven't gotten around to putting in 1.02; if this is already fixed
please accept my apologies for cluttering the list.

I am running Bash 1.01 under SunOS 3.5. Here's what I am complaining
about:

Script started on Mon Jul 17 15:27:14 1989
bent[1] IFS=:
bent[2] while read login passwd uid gid gcos home shell;do
> echo -n $gcos
> done </etc/passwd
script done on Mon Jul 17 15:27:57 1989

Hmmm -- not only did it not print out anything (i.e. IFS didn't work,
which was my complaint) the child invocation of Bash within the script
exited when EOF was hit on the loop's redirected input, instead of
switching back to interactive. That reminds me of another flake I've
seen (but haven't been able to reproduce suitably for a separate bug
report); on one occasion I set up an intricate loop reading from a file;
then discovered a bug during the first iteration of the loop. So, I
^C-ed the loop. Bash then proceeded to attempt to read the remainder of
the data file attempting to execute each line as a command, and finally
exited when it hit the end of the loop's data file.

By contrast, here's another script:

Script started on Mon Jul 17 15:35:05 1989
bent[1] sh
bent[\#] IFS=:
bent[\#] while read login passwd uid gid gcos home shell;do
> echo -n $gcos
> done </etc/passwd
Operator [...list of GCOS fields omitted...]bent[\#] exit
bent[2] 
script done on Mon Jul 17 15:36:02 1989

/bin/sh parsed /etc/passwd using IFS... and didn't exit when the loop
reached EOF.

Also, while typing this in I stumbled across a *really* minor annoyance;
routinely, when entering interactive loops, I attempt to indent the loop
bodies (which provides me the same readability advantages it offers in
more conventional programming contexts). Bash hangs on the command line
when ^I is the first character entered, until I hit ^C. Would it be too
much work to disable the completion function of ^I when ^I is the first
character entered on a line?

-Bennett
bet@orion.mc.duke.edu