cudcv@warwick.ac.uk (Rob McMahon) (07/20/89)
(Bash claims to be 1.02, although some of the patches I've seen in this group don't quite seem to tie in.) When you set a flag (e.g. `set -f'), the positional parameters are lost. Here's a typescript to show what I mean. `./bash' refers to bash after adding the fix at the end of this script. Script started on Wed Jul 19 19:13:26 1989 bash$ echo $- io bash$ echo $@ bash$ set gronk grimble bash$ echo $@ gronk grimble bash$ set -f bash$ echo $- fio bash$ echo $@ <= positional parameters have gone away bash$ sh $ echo $- s $ echo $@ $ set gronk grimble $ echo $@ gronk grimble <= okay with normal shell $ set -f $ echo $- sf $ echo $@ gronk grimble $ bash$ ./bash bash$ echo $- o bash$ echo $@ bash$ set gronk grimble bash$ echo $@ gronk grimble bash$ set -f bash$ echo $- fo bash$ echo $@ gronk grimble bash$ x bash$ script done on Wed Jul 19 19:16:17 1989 There's also a patch in here to fix the documentation for `test'. BTW. Could Brian Fox ack this please, I've a sneaky suspicion these bug reports aren't getting to him. I'm posting them to gnu.bash.bug, should I be mailing them to some other address (unknown to me) instead ? Should this group in fact be moderated with some mailing list address as the moderator ? If I'm doing things wrong, could someone else let me know. Thanks, Rob =================================================================== RCS file: builtins.c,v retrieving revision 1.4 diff -c -r1.4 builtins.c *** /tmp/,RCSt1a00923 Wed Jul 19 19:21:27 1989 --- builtins.c Wed Jul 19 19:04:10 1989 *************** *** 339,345 **** \n\ String operators:\n\ \n\ ! -n STRING True if string is empty.\n\ STRING True if string is not empty.\n\ STRING1 = STRING2\n\ True if the strings are equal.\n\ --- 339,346 ---- \n\ String operators:\n\ \n\ ! -z STRING True if string is empty.\n\ ! -n STRING True if string is not empty.\n\ STRING True if string is not empty.\n\ STRING1 = STRING2\n\ True if the strings are equal.\n\ *************** *** 1672,1678 **** } /* Assigning $1 ... $n */ ! remember_args (list, 1); } --- 1673,1680 ---- } /* Assigning $1 ... $n */ ! if (list) ! remember_args (list, 1); } -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/21/89)
Date: 19 Jul 89 18:27:34 GMT From: mcvax!ukc!warwick!cudcv@uunet.uu.net (Rob McMahon) Organization: Computing Services, Warwick University, UK Sender: bug-bash-request@prep.ai.mit.edu BTW. Could Brian Fox ack this please, I've a sneaky suspicion these bug reports aren't getting to him. I'm posting them to gnu.bash.bug, should I be mailing them to some other address (unknown to me) instead ? Should this group in fact be moderated with some mailing list address as the moderator ? If I'm doing things wrong, could someone else let me know. Thanks, Rob To the list in general: If the mail doesn't bounce, you can be sure it got to me. You may not get a response from me because the question has already been answered, the bug has already been fixed, the bug does not really exist (i.e., you ported Bash incorrectly, or you are complaining about an unsupported port), or worst of all, you are complaining about a bug that was introduced by installing third party patches as soon as they appear on this list. It is almost always true that the fix I make to the Bash source is not the same as a posted patch, and sometimes, it is so drastically different as to make it ridiculous to consider posting diffs to the list. All of the bug reports I recieve are read, and are most welcome, for they help me to make Bash more solid and reliable day by day. I thank you all for your patience while using these Beta release versions of Bash. Brian Fox