Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14439 > unrolled thread

Re: failglob handling

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: failglob handling Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-03 10:59 -0400

#14439 — Re: failglob handling

On Fri, Aug 03, 2018 at 03:29:33PM +0200, Thomas Deutschmann wrote:
> However, see the following interesting difference between semicolons and
> newlines:
> 
> > $ echo "shopt -s failglob; echo /foo/bar/*; echo alive; " | bash
> > bash: line 1: no match: /foo/bar/*

Yeah, my own testing confirms that basically, if failglob triggers,
it takes out the entire LINE of commands, not just the one command
that triggered it.

wooledg:~$ shopt -s failglob
wooledg:~$ : /none/*
bash: no match: /none/*
wooledg:~$ : /none/* ; echo hi
bash: no match: /none/*
wooledg:~$ : /none/* || echo hi
bash: no match: /none/*
wooledg:~$ if : /none/* ; then echo yes; else echo no; fi
bash: no match: /none/*

Or, the entire compound command, even if it's across multiple lines:

wooledg:~$ if : /none/* ; then
> echo yes; else echo no; fi
bash: no match: /none/*

That's as far as I cared to test it.  Just another thing to toss on the
heap of not-so-useful shell toys, like set -u.  Not suitable for real
work.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web