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

Groups > gnu.bash.bug > #15609 > unrolled thread

Re: Issues with history substitution and its documentation

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.

Contents

  Re: Issues with history substitution and its documentation Chet Ramey <chet.ramey@case.edu> - 2019-11-18 14:55 -0500

#15609 — Re: Issues with history substitution and its documentation

On 11/6/19 10:21 AM, Jim Monte wrote:
> Another documentation issue for :s, and a bug, or two bugs, although it
> seems to be one of each. Instead of "Any delimiter may be used in place of
> ‘/’.", it should be clarified that any character may be used in place of
> '/' as a delimiter, although if '&' is used, it looses its special property
> of being the value of old when it appears in new and if '\' is used, it
> looses is ability to escape '&'. 

It doesn't. I think it would be clearer after an explanation of how the
history expansion code parses substitutions and how backslashes act as
escape characters during scanning. The principle to remember up front is
that backslash can act as an escape character, but not in all contexts,
and it is removed for the next stage of history expansion if it is used
as an escape character.


However, there is still an issue with an
> escape being lost in some cases.
> 
> [root@localhost ~]# echo a b c
> a b c
> [root@localhost ~]# echo "!:s&b&\\\&&&"
> echo "echo a \& c&"                              ******************* one

This is exactly what csh does. Here's why.

The history code notes that the substitution delimiter is `&', so it has
to scan forward for the separating and closing delimiters. The separating
one after the lhs is easy. To find the closing delimiter, the backslash
escapes one `&', the second `&' terminates the history substitution, and
the third is held until later. The backslash escaping the `&' is removed.
The backslash doesn't escape itself when scanning for the ending delimiter,
so the replacement string is `\\&'.

That replacement string gets post-processed for possible & interpolation,
so it gets rescanned. During this rescanning, the backslash escapes only
the `&', and not itself, so the backslash escapes the `&' and is removed.
The final replacement string is '\&', and that gets substituted for `b'
in the original event string.

The final `&' doesn't participate in the history expansion, so it's just
appended to the result.


> [root@localhost ~]# echo a b c
> a b c
> [root@localhost ~]# echo "!:s/b/\\\&&/"
> echo "echo a \\&b c"                             *******************
> echo a \&b c

Right. You don't have to consume one backslash while scanning for the
ending delimiter.

> [root@localhost ~]# echo a b c
> a b c
> [root@localhost ~]# echo "!:szbz\\\&&z"
> echo "echo a \\&b c"                             *******************
> echo a \&b c

This is the same example.

> [root@localhost ~]# echo a b c
> a b c
> [root@localhost ~]# echo "!:s\b\\\\&&\"
> echo "echo a  c\\&&\"
>> "
> echo a  c\&&"
> 
> [root@localhost ~]# echo a b c
> a b c
> [root@localhost ~]# echo "!:s\b\z\&&y\"
> echo "echo a z c&&y\"
>> "
> echo a z c&&y"

You should be able to work these out given the previous examples.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web