>Bash has always performed history expansion a line at a time, as soon as >the line is read from the current input source. One consequence of this, >as you noted, is that it doesn't have access to the current quoting state. >This is a limitation of the implementation.
That was quite unexpected for me as a user. I checked sed script like this: echo "a b"| sed '/a/!d' And that implementation detail were highly unexpected... What is the point of multiline edits if quotes are unreliable for certain characters? 2014-12-03 16:47 GMT+03:00 Chet Ramey <chet.ra...@case.edu>: > On 12/3/14, 4:19 AM, Eduardo A. Bustamante López wrote: > > On Wed, Dec 03, 2014 at 08:57:26AM +0100, Piotr Grzybowski wrote: > >> Hey, > >> > >> I think in this case, history_expand lib/readline/histexpand.c:905 is > >> invoked with hstring="b\" | echo '!'", and goes wrongly into history > >> expansion. > >> Not that I know how to fix it ;-) > > Yes, the issue is tricky, because you don't have access to the whole > buffer > > there (shell_getc), just to the current line (shell_input_line), but the > > current line is a fragment of the whole command. > > > > What I don't understand is why bash does history expansion inside > shell_getc, > > shouldn't it be easier to do it once you have the whole thing? > > Bash has always performed history expansion a line at a time, as soon as > the line is read from the current input source. One consequence of this, > as you noted, is that it doesn't have access to the current quoting state. > This is a limitation of the implementation. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu > http://cnswww.cns.cwru.edu/~chet/ >
