Re: Multi-word matching in history expansion

[The Wanderer]

(And again.)

Bob Proulx wrote:

> The Wanderer wrote:
>
> > Quite some time and several varyingly-significant updates of bash
> > ago, I was able to perform history expansion on multi-word
> > commands.
> >
> > At present and for some while now, [!ls /h] instead expands to
> >
> > ls /tmp/ /h
>
> This is also what csh does in this situation too.  This type of
> history substitution originated with csh and it would be the standard
> against which other implementations would be compared.

That makes a certain amount of sense, although the behaviour itself
still does not.

What does csh do with e.g.

!ls\ /h

(that is, attempting to escape the space so as to prevent tokenizing
them separately)? I do not have csh installed, so I can't test. I know
that bash simply gives

bash: !ls\: event not found

which would appear to imply this sort of expansion either takes place
before tokenization or does not use standard tokenization rules, so the
obvious first-attempt-at-a-workaround approach of escaping the token
separator is ineffective.

> But I don't know the code history of this feature in bash.

I would be interested to find out, if someone is present who does know.
I would also be interested to know the rationale behind the behaviour,
given that the only potentially real-world scenario I can think of where
this behaviour seems as if it would be useful is in adding e.g. the '-g'
flag to the end of a compiler command line, but the other behaviour was
useful to me in a wide variety of circumstances.

I would also be curious to know the exact reason why escaping the space
does not cause it to be treated as part of the initial command to be
matched and so form an effective workaround, but I suspect that there is
no practical way to explain that better than is done by the source itself.

--
      The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.