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
signature.asc
Description: This is a digitally signed message part
