bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem with global substition in history expansion (!!:gs/old/new/)


From: Klaus . Schiwinsky
Subject: Problem with global substition in history expansion (!!:gs/old/new/)
Date: Wed, 14 Aug 2002 01:44:59 +0200

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H  -D_FILE_OFFSET_BITS=64  -I.  
-I/home/swt/doko/export/packages/bash/bash-2.03 
-I/home/swt/doko/export/packages/bash/bash-2.03/lib -I/usr/include -g -O2
uname output: Linux spinne 2.2.19 #1 Mon Sep 3 00:22:37 CEST 2001 i686 unknown
Machine Type: i386-pc-linux-gnu

Bash Version: 2.03
Patch Level: 0
Release Status: release

Description:

        Global substition reminds me of something like:
        $ echo aaaaaa | sed -e 's/a/3/g'
        333333

        The bash history expansion modifier "gs" works different,
        see "Repeat-By:".
        This problem seems to be independant of the event designator.

        Following bash versions show this behaviour:
        - GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu)
        - GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
        I found a quite old posting (Jan 1994) that describes the 
        very same problem with bash 1.13.14 (sorry for the long URL,
        at least, it's shorter than Compilation CFLAGS):

        
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=9401181723.AA18991%40jfbi.CV.COM&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DISO-8859-1%26q%3Dgs%26meta%3Dgroup%253Dgnu.bash.bug
        The interpretation given in message 2 of this thread is not correct,
        try
            $ #/etc/passswd
            $ !!:gs/s/z/:p
            #/etc/pazszwd
   
        <bashsources>/tests/histexp.tests doesn't test this case.
       
Repeat-By:

        $ bbbbbb                           # /bin/echo 'Here is no problem!'
        Here is no problem!
        $ aaaaaa                           # /bin/echo 'Here is a problem:'
        Here is a problem:                                   
        $ !?aaaaaa?:sg/a/b/:p 
        bababa
        $ !?aaaaaa?:sg/aa/bb/:p
        bbabba
        $ !?aaaaaa?:sg/aaa/bbb/:p
        bbbaaa
        $ !?aaaaaa?:sg/aaaaaa/bbbbbb/
        Here is no problem!

        $
        $ aaaaaa 
        Here is a problem:                                   
        $ !?a?:sg/a/b/:p                   # Modified event designator...
        bababa

        $
        $ aaaaaa
        Here is a problem:                                   
        $ !!:sg/a/b/:p                     # Seems that event designator 
doesn't matter
        bababa


Fix:
        $ mv bbbbbb bababa                                    - Too specific
        Don't use the bash history expansion modifier 'gs'    - I like things 
with long names 
        Send a mail to bug-bash@gnu.org                       - I did.
        Fix the code!                                         - Hm, let me try 
this:

        Well, I tried to figure out what happened and, maybe, I found the 
solution.
        I have to admit that I did not try to understand the code completely,
        but the following solution doesn't show the problems described above
        and passes the tests/histexp.tests. That's all I tried.

-------------------------------------------------------------
--- lib/readline/histexpand.c   Tue Mar  6 20:09:25 2001
+++ lib/readline/histexpand.c   Tue Mar  6 20:09:25 2001
@@ -712,7 +712,7 @@
 
                  if (substitute_globally)
                    {
-                     si += subst_rhs_len;
+                     si += subst_rhs_len - 1;
                      l_temp = strlen (temp);
                      substitute_globally++;
                      continue;

-------------------------------------------------------------

        subst_rhs_len is defined in postproc_subst_rhs () and includes 
        the '\0'.


Greetings
Klaus Schiwinsky




reply via email to

[Prev in Thread] Current Thread [Next in Thread]