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


Groups > gnu.bash.bug > #15263

Re: x[

From Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups gnu.bash.bug
Subject Re: x[
Date 2019-07-29 13:14 -0400
Message-ID <mailman.167.1564420473.1985.bug-bash@gnu.org> (permalink)
References <CAAZkfoK2hYq_qSkdKYc1on=+V4VEBgpgZW96sYNZwC+AMw7iTw@mail.gmail.com> <9EA25AF1-6D80-456A-81FA-6D908072E624@gmail.com> <a6a2b6a8-6151-78dc-41be-fc81250a40e5@archlinux.org> <20190729171412.GD1218@eeg.ccf.org>

Show all headers | View raw


On Mon, Jul 29, 2019 at 01:09:28PM -0400, Eli Schwartz wrote:
> On 7/29/19 1:01 PM, Clint Hepner wrote:
> > The ``[`` begins a valid shell pattern, so the parser continues to
> > accept input until the closing ``]`` is found. Pathname expansion
> > (apparently) does not apply to the first "argument" of the
> > ``function`` command.
> 
> The initial workaround discovered, was to use
> 
> $ function _[ () { echo hello; }; <() _[
> hello
> 
> The use of <() somehow suppresses the glitch in the same way that
> quoting it does. If it were just glob expansion, then why should that be so?

Or even simpler:

wooledg:~$ echo x[
x[
wooledg:~$ x[
> 

The glitch doesn't occur when the x[ is an argument of a simple command.
It only occurs when x[ is being parsed *as* the command.  So, while I
suspect "looking for a glob" is part of the answer, it's not the whole
picture.

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


Thread

Re: x[ Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-29 13:14 -0400

csiph-web