bet@ORION.MC.DUKE.EDU (Bennett Todd) (07/18/89)
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
composer@BU-CS.BU.EDU (Jeff Kellem) (07/18/89)
| Date: Mon, 17 Jul 89 15:38:20 EDT | From: bet@orion.mc.duke.edu (Bennett Todd) | | 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? Well, all you really need to do is use whatever key sequence is bound to the function 'tab-insert'. By default, this is Meta-I (or ESC-I). You can always change it to some other key sequence by editing your ~/.inputrc file. Enjoy... -jeff Jeff Kellem INTERNET: composer@bu-cs.bu.edu (or composer%bu-cs.bu.edu@bu-it.bu.edu) UUCP: ...!harvard!bu-cs!composer
bet@ORION.MC.DUKE.EDU (Bennett Todd) (07/18/89)
I wrote: > [...] Bash hangs on the command line > when ^I is the first character entered, until I hit ^C. Jeff Kellem (composer@bu-cs.bu.edu) pointed out to me that it doesn't really hang, it is just taking a while to give up on command expansion. I checked, and sure enough it did come back if I waited. My mistake. Sorry. -Bennett bet@orion.mc.duke.edu
chet@kiwi.CWRU.EDU (Chet Ramey) (07/20/89)
Bennett Todd writes:
?bent[1] IFS=:
?bent[2] while read login passwd uid gid gcos home shell;do
?> echo -n $gcos
?> done </etc/passwd
?Hmmm -- not only did it not print out anything (i.e. IFS didn't work,
?which was my complaint)
This is a simple typo (or an incomplete change). In builtins.c:read_builtin,
the list_string call should read
words = list_string (input_string, ifs_chars, 0);
For some reason, " \t\n" was hard-coded in there, though the value of $IFS
is assigned to ifs_chars.
?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.
I couldn't reproduce this under SunOS 3.5, bash 1.02, gcc-1.35.
Chet Ramey
Chet Ramey "We are preparing to think about contemplating
Network Services Group, CWRU preliminary work on plans to develop a
chet@cwjcc.INS.CWRU.Edu schedule for producing the 10th Edition of
the Unix Programmers Manual." -- Andrew Hume