wwc@boole.ece.wisc.edu (William W. Carlson) (07/12/89)
I really like bash a great deal, but one "feature" I find quite annoying. Whenever globbing fails (i.e. no match), it leaves the unglobbed string as is. (i.e. if I type "ls foo* bar*" and there is a file in the current directory called foo.c but none starting with "bar", ls gets passed "ls foo.c bar*" and of course says "bar* not found." This feature is particularly disturbing in aliases. Do people think this is a "bug" or a "feature"? If it is a bug, I'd really like it fixed. If it is a feature, I'd like for there to be some way (perhaps set -no_bogus_globbing) to disable it. Bill Carlson wwc@engr.wisc.edu
brian@radio.astro.utoronto.ca (Brian Glendenning) (07/12/89)
If it comes to a vote (:-) I think it's a feature. -- Brian Glendenning - Radio astronomy, University of Toronto brian@radio.astro.utoronto.ca uunet!utai!radio!brian glendenn@utorphys.bitnet
rsalz@bbn.com (Rich Salz) (07/13/89)
Given a directory with the two files "virus" and "very" in it, then echo v* z* will do the following for sh very virus z* and it will do the following for csh very virus if you do "set nonomatch" in csh, then you'll get the sh behavior. -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/13/89)
Date: 12 Jul 89 13:22:31 GMT From: cica!ctrsol!sdsu!polyslo!indri!engr!wwc@cis.ohio-state.edu (William W. Carlson) Organization: University of Wisconsin-Madison Sender: bug-bash-request@prep.ai.mit.edu I really like bash a great deal, but one "feature" I find quite annoying. Whenever globbing fails (i.e. no match), it leaves the unglobbed string as is. (i.e. if I type "ls foo* bar*" and there is a file in the current directory called foo.c but none starting with "bar", ls gets passed "ls foo.c bar*" and of course says "bar* not found." This feature is particularly disturbing in aliases. Do people think this is a "bug" or a "feature"? If it is a bug, I'd really like it fixed. If it is a feature, I'd like for there to be some way (perhaps set -no_bogus_globbing) to disable it. Bill Carlson wwc@engr.wisc.edu Well, this was a design decision. I think that it is the best of possible alternatives. Would you like to present an alternative that you feel is better? Brian
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/13/89)
Date: 12 Jul 89 17:29:06 GMT From: rsalz@bbn.com (Rich Salz) Organization: BBN Systems and Technologies Corporation References: <WWC.89Jul12082231@boole.ece.wisc.edu> Sender: bug-bash-request@prep.ai.mit.edu Given a directory with the two files "virus" and "very" in it, then echo v* z* will do the following for sh very virus z* and it will do the following for csh very virus if you do "set nonomatch" in csh, then you'll get the sh behavior. -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out. In csh, without `nonomatch' set, (note this could mean typing "unset nonomatch"!), then echo z* -> echo: no match but echo v* z* -> very virus This is ambiguous behaviour in my opinion. Brian Fox
grr@cbmvax.UUCP (George Robbins) (07/13/89)
In article <WWC.89Jul12082231@boole.ece.wisc.edu> wwc@boole.ece.wisc.edu (William W. Carlson) writes: > > ... ls gets passed "ls foo.c bar*" and of course says "bar* not > found." This feature is particularly disturbing in aliases. Do > people think this is a "bug" or a "feature"? If it is a bug, I'd > really like it fixed. If it is a feature, I'd like for there to be > some way (perhaps set -no_bogus_globbing) to disable it. But that's the elegant, if preverse, way that bourne style shells are supposed to handle unresolved globbing attempts. What you are asking for is "set -csh_style_bogus_glob_error_messages_and_terminate" option. 8-) Such a mode does have it's merits, though it's necessity is arguable. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
chet@kiwi.CWRU.EDU (Chet Ramey) (07/13/89)
In article <WWC.89Jul12082231@boole.ece.wisc.edu> wwc@boole.ece.wisc.edu (William W. Carlson) writes:
? Whenever globbing fails (i.e. no match), it leaves the
? unglobbed string as is. (i.e. if I type "ls foo* bar*" and there is a
? file in the current directory called foo.c but none starting with
? "bar", ls gets passed "ls foo.c bar*" and of course says "bar* not
? found." This feature is particularly disturbing in aliases. Do
? people think this is a "bug" or a "feature"? If it is a bug, I'd
? really like it fixed. If it is a feature, I'd like for there to be
? some way (perhaps set -no_bogus_globbing) to disable it.
This is because (all together now) BASH IS NOT CSH! It is a
POSIX-style/Bourne Shell clone. Bourne-style shells leave a word
unchanged if it expands into nothing.
I vote to keep it, in the interest of sh compatibility.
Chet
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 Humebart@videovax.tv.Tek.com (Bart Massey) (07/14/89)
In article <8907121835.AA02530@aurel.caltech.edu> bfox@aurel.caltech.edu writes: > In csh, without `nonomatch' set, (note this could mean typing "unset > nonomatch"!), then > echo z* > -> echo: no match > but > echo v* z* > -> very virus > This is ambiguous behaviour in my opinion. Agreed. But one of the biggest traps for beginners in Bourne Shell programming is exemplified by the fact that you can't write for i in * do cat $i done safely unless you're sure that there are files in the current directory. IMHO, what's wanted is set nullglobok which inhibits both "no match" errors (which are almost never what I want in shell scripts anyway) and the funny behaviour of nonmatching patterns. If "bash" (instead of "sh" (i.e. BASH emulating the Bourne Shell)) is started non-interactively, then I would probably choose "nullglobok" to be set by default. But this is more a matter of taste. I've taught quite a few people Bourne Shell programming, and it'd have been a lot easier for me if this feature had been available... Bart Massey ..tektronix!videovax.tv.tek.com!bart ..tektronix!reed.bitnet!bart
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/14/89)
Date: 13 Jul 89 22:37:32 GMT From: tektronix!tekcrl!tekfdi!videovax!bart@cis.ohio-state.edu (Bart Massey) Organization: Tektronix TV Measurement Systems, Beaverton OR References: <1897@prune.bbn.com>, <8907121835.AA02530@aurel.caltech.edu> Sender: bug-bash-request@prep.ai.mit.edu In article <8907121835.AA02530@aurel.caltech.edu> bfox@aurel.caltech.edu writes: > In csh, without `nonomatch' set, (note this could mean typing "unset > nonomatch"!), then > echo z* > -> echo: no match > but > echo v* z* > -> very virus > This is ambiguous behaviour in my opinion. Agreed. But one of the biggest traps for beginners in Bourne Shell programming is exemplified by the fact that you can't write for i in * do cat $i done safely unless you're sure that there are files in the current directory. IMHO, what's wanted is set nullglobok which inhibits both "no match" errors (which are almost never what I want in shell scripts anyway) and the funny behaviour of nonmatching patterns. You mean "nullglobok=", not "set nullglobok". If "bash" (instead of "sh" (i.e. BASH emulating the Bourne Shell)) is started non-interactively, then I would probably choose "nullglobok" to be set by default. But this is more a matter of taste. I'm really amazed that you would want this behaviour. In the above `for' command, with "nullglobok" non-null, and no files in the current directory, the `cat' would hang, waiting for input, since `$i' would expand to nothing. Brian Fox
tale@pawl.rpi.edu (David C Lawrence) (07/14/89)
From: tektronix!tekcrl!tekfdi!videovax!bart@cis.ohio-state.edu (Bart Massey)
Bart> for i in *
Bart> do
Bart> cat $i
Bart> done
In <8907141311.AA07040@aurel.caltech.edu> bfox@AUREL.CALTECH.EDU (Brian Fox):
BF> I'm really amazed that you would want this behaviour. In the above `for'
BF> command, with "nullglobok" non-null, and no files in the current
BF> directory, the `cat' would hang, waiting for input, since `$i' would
BF> expand to nothing.
Ugh. I've never come up against a for loops that started with a null
item in sh programming, but is that really what it is supposed to do?
It seems to me that in the interests of logical sensibility and
similarity to many existing languages it shouldn't even enter the for
loop because it has nothing with which to iterate.
(Yes, I know the "existing languages" argument falls apart with those
languages which will always execute a for loop at least once even
when the terminating condition is already met. That always seemed
like broken behaviour to me.)
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))tale@rpi.edu (David C Lawrence) (07/14/89)
From: tektronix!tekcrl!tekfdi!videovax!bart@cis.ohio-state.edu (Bart Massey) Bart> for i in * Bart> do Bart> cat $i Bart> done In <8907141311.AA07040@aurel.caltech.edu> bfox@AUREL.CALTECH.EDU (Brian Fox): BF> I'm really amazed that you would want this behaviour. In the above `for' BF> command, with "nullglobok" non-null, and no files in the current BF> directory, the `cat' would hang, waiting for input, since `$i' would BF> expand to nothing. Ugh. I've never come up against a for loops that started with a null item in sh programming, but is that really what it is supposed to do? No, and I take it back. It doesn't do that. Sorry. Brian Fox
maart@cs.vu.nl (Maarten Litmaath) (07/15/89)
bfox@AUREL.CALTECH.EDU (Brian Fox) writes:
\... for i in *
\ do
\ cat $i
\ done
\... with "nullglobok" non-null, and no files in the current
\directory, the `cat' would hang, waiting for input, since `$i' would
\expand to nothing.
Think again, Brian: the body wouldn't get executed at all.
--
"... a lap-top Cray-2 with builtin |Maarten Litmaath @ VU Amsterdam:
cold fusion power supply" (Colin Dente) |maart@cs.vu.nl, mcvax!botter!maart