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


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

Re: Issues with history substitution and its documentation

Started byChet Ramey <chet.ramey@case.edu>
First post2019-11-18 10:34 -0500
Last post2019-11-18 10:34 -0500
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.


Contents

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

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

FromChet Ramey <chet.ramey@case.edu>
Date2019-11-18 10:34 -0500
SubjectRe: Issues with history substitution and its documentation
Message-ID<mailman.1845.1574091294.13325.bug-bash@gnu.org>
On 10/3/19 6:19 PM, Jim Monte wrote:

> Description:
> =============================================================================
> Documentation of quick substitution is incorrect (or does not match
> behavior).
> 
> I believe this issue is an error with the documentation of history
> "Quick Substitution" that has existed since the first snapshot available at
> web.archive.org in 2007 at
> 
> https://web.archive.org/web/20071223174140/http://www.gnu.org/software/bash/manual/html_node/Event-Designators.html
> 
> At the least it is true that bash does not behave as the documentation
> states,
> but it does act in a way that is more reasonable (to me) than what is
> written.
> 
> The documentation states that ^string1^string2^ is equivalent to
> !!:s/string1/string2/. However, bash treats it as equivalent to
> !!:s^string1^string2^.

This is correct, and I changed the documentation.

> =============================================================================
> Behavior of empty "old" string in a substitution is undefined.
> 
> The earlier example also shows a related but different issue with the
> !!:s//a/b/ command, where the string to locate is empty.
> It causes /a to be replaced by a and the b/ is appended.

It's not, actually. It's documented in the man page, but due to an
oversight the text doesn't appear in the texinfo manual.


> =============================================================================
> BUG
> If an event designator has a leading - character, it is ignored.

It's treated as an offset with value 0, and otherwise ignored. If it's not
followed by a digit string, it should be treated as part of a search
string.

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