bug-bash
[Top][All Lists]
Advanced

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

Re: Syntax for tab character


From: Bill Gradwohl
Subject: Re: Syntax for tab character
Date: Fri, 24 Apr 2009 20:11:53 -0600

On Fri, 2009-04-24 at 18:54 -0400, Chet Ramey wrote:
> I'm not quite sure what this is supposed to demonstrate.  In the cases
> where you have specified the tab character correctly ($'\t'), it's
> converted into a tab before matching is attempted.  
I respectfully disagree, and I believe I have proof below.
> You can tell this
> because in the cases where you have not, either the literal `$' gets
> removed, or the literal instances of \t in the value of parameter are
> removed.  Since there are no tab characters in $parameter, no tabs get
> removed when you specify $'\t' correctly.
> 
I did a hex dump to prove that there were Hex '09' (tab) characters in
the original parm field and that field gets reused again and again. The
original dump also shows the $'s in evidence.

Let me state what I see going on and maybe I'm just not looking at this
the way you are. BTW - whenever I test, I always do it twice per case,
one with and one without double quotes, as they have tripped me up on
numerous occasions.

Here is the dump of the original string - ${parm}. It shows hex 09's and
$'s.
0000000  68 65 6c 6c 6f 20 09 20 ^ 61 6e 64 20 09 20 24 20
          h  e  l  l  o    \t    ^  a  n  d    \t     $   
0000010  24 67 6f 6f 64 20 09 20 ^ 62 79 65 2e 0a         
          $  g  o  o  d    \t    ^  b  y  e  . \n         

Here is the dump of the 2 trivial cases of just eliminating the space
and tab characters. No surprise here. Note that the pattern used was:
   [ '\t']
and it appears to work, so I conclude that '\t' is being interpreted as
a tab character - without the leading $.
0000000  68 65 6c 6c 6f 61 6e 64 ^ 24 24 67 6f 6f 64 62 79
          h  e  l  l  o  a  n  d ^  $  $  g  o  o  d  b  y
0000010  65 2e 0a                ^                        
          e  . \n                ^                        

0000000  68 65 6c 6c 6f 61 6e 64 ^ 24 24 67 6f 6f 64 62 79
          h  e  l  l  o  a  n  d ^  $  $  g  o  o  d  b  y
0000010  65 2e 0a                ^                        
          e  . \n                ^                        

Below is the one I don't get. You can see that the hex 09's are still
there, and the $'s are also still there. Only the spaces have been
eliminated. This was produced with:
   parameter="${parm}"
   parameter="${parameter//[ $'\t']}"
   echo -e "${parameter}" | dumpit
Well if the tabs are still there, then I conclude that $'\t' isn't being
interpreted as a tab character. Further, if it's not a tab, then what is
it? Since the $'s are still there also, the $'s can't be taken
literally. I don't know what's going on. '\t' worked as a tab character
in the previous example, but it appears not to work here. The $ in front
of the '\t' must have something to do with it I suspect, but $'\t' can't
be a tab character.
0000000  68 65 6c 6c 6f 09 61 6e ^ 64 09 24 24 67 6f 6f 64
          h  e  l  l  o \t  a  n ^  d \t  $  $  g  o  o  d
0000010  09 62 79 65 2e 0a       ^                        
         \t  b  y  e  . \n       ^                        

0000000  68 65 6c 6c 6f 09 61 6e ^ 64 09 24 24 67 6f 6f 64
          h  e  l  l  o \t  a  n ^  d \t  $  $  g  o  o  d
0000010  09 62 79 65 2e 0a       ^                        
         \t  b  y  e  . \n       ^                        

Here I changes the pattern to [$ '\t'] and the $'s, the spaces and the
tabs are gone. [ $'\t'] doesn't work, but [$ '\t'] does.
0000000  68 65 6c 6c 6f 61 6e 64 ^ 67 6f 6f 64 62 79 65 2e
          h  e  l  l  o  a  n  d ^  g  o  o  d  b  y  e  .
0000010  0a                      ^                        
         \n                      ^                        

0000000  68 65 6c 6c 6f 61 6e 64 ^ 67 6f 6f 64 62 79 65 2e
          h  e  l  l  o  a  n  d ^  g  o  o  d  b  y  e  .
0000010  0a                      ^                        
         \n                      ^                        

Via man bash, the description for [...] usage leads me to believe
everything inside it is taken literally, but that is obviously not the
case. I see a lot of strange things going on via this example, but maybe
there's a simple explanation for it all that I'm just missing.
-- 
Bill Gradwohl

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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