Re: [Help-bash] getting weird output out of 'echo' w/args

[Dan Douglas]

On Tuesday, June 04, 2013 11:35:09 AM DJ Mills wrote:
> On Thursday, May 30, 2013 11:15:20 AM Roman Rakus wrote:
>   Many times I saw using tr like this:
>   somecommand | tr -s [a-z] ''
>   somecommand | tr -s [:space:] ' '
> 
> The brackets are also not needed in the first one, in fact they probably
> cause incorrect behavior as well.
> 
> 
> On Mon, Jun 3, 2013 at 4:36 AM, Dan Douglas <address@hidden> wrote:
> 
> 
> > Yes. {fail,no}glob can help debugging a bit. A more useful feature would
> > be to
> > fail whenever the first word of a simple command resulted from anything
> > that
> > could have been interpreted as a glob, whether it matched files or not.
> > Also
> > any other context where globing never ever makes sense. Other glob options
> > are
> > too intrusive and are only useful when you aren't going to glob, or to
> > toggle
> > temporarily.
> > --
> > Dan Douglas
> >
> >
> 
> What exactly are the contexts where globbing "never makes sense"? That's
> way too subjective, IMO. How
> can you decide what "makes sense" for everyone?

The example I gave is a good one. You wouldn't want the name of a command, 
variable, or other program code to be determined by a pattern match for files 
in the current directory. For example:

ec*ho arg1 "$x"

or

printf -v a[$var] %s foo

or

>];[ "$x" *

These are coding errors way more than 99% of the time if not always. It makes 
more sense to have an option that's likely to catch real errors by treating 
them as such by default than to have an effectively useless option that breaks 
globbing (failglob) by throwing fatal shell errors that you can't handle 
yourself in cases where globbing is intentional and no files were matched.

-- 
Dan Douglas