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


Groups > gnu.bash.bug > #14439

Re: failglob handling

From Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups gnu.bash.bug
Subject Re: failglob handling
Date 2018-08-03 10:59 -0400
Message-ID <mailman.4653.1533308419.1292.bug-bash@gnu.org> (permalink)
References <cb5f1669-3a0b-f9ce-6994-e4b0c7d31bd0@gentoo.org>

Show all headers | View raw


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.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

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

csiph-web