Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15263 > unrolled thread
| Started by | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| First post | 2019-07-29 13:14 -0400 |
| Last post | 2019-07-29 13:14 -0400 |
| Articles | 1 — 1 participant |
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.
Re: x[ Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-29 13:14 -0400
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-07-29 13:14 -0400 |
| Subject | Re: x[ |
| Message-ID | <mailman.167.1564420473.1985.bug-bash@gnu.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 top | Article view | gnu.bash.bug
csiph-web