Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15263
| 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> |
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
Re: x[ Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-29 13:14 -0400
csiph-web