Greg Wooledge wrote:
On Wed, Aug 26, 2009 at 02:45:39AM -0700, Linda Walsh wrote:
I had a var 'c' set to (no quotes in the var): 'C\windows\system32'
How did you assign this value? Did you read it from a file? Did you
type a specific bash command?
------
I typed it in at the prompt as:
# c='C:\Windows\System32'
# echo $v |hexdump -C
00000000 43 3a 5c 77 69 6e 64 6f 77 73 5c 73 79 73 74 65
This isn't trustworthy, because you did not quote $v.
---
Didn't bother quoting it because quoted or unquoted, it gave the
same output in this case, but in general, you are right.
# printf -v v "%q" $c
Same problem here -- unquoted $c means you're not necessarily getting
the variable's exact contents.
---
Again, same response as above (made no diff in this case,
but in general, quoting "is good" :-).
for c=C:\Windows\System32, and v=C:\Windows\System32
Even with the unquoted $v here, you should have seen the double backslashes:
$ echo $v
C:\\Windows\\System32
So your output doesn't match your script. Something strange is afoot.
---
Oh...yeah, forgot about my 'xpg_echo' option...that explains echo
but that wasn't my "ponderance", -- I knew about the internal
contents varying (from tracing the script during debugging, ie '+x').
Note, I'm not saying 'echo' has a bug or there is a problem with
how bash stores things internally. Remember, I did mention that I
"an idea" of what was going on with the 'echo' stuff -- meaning (one is
«'C:\windows\system32'» and the other is «C:\\windows\\system32»),
but my email header was to indicate (perhaps unclearly) whether or not
such behavior was worthy of a ‘manpage note’ for the unwary -- especially
the difference in the test ops mentioned below, which, I'm not entirely
clear, yet, about why they give the different results they give.
I understand why the quoted versions "$c" = "$v" both say 'different',
(their internal representation is different). But the unquoted
differences appear a bit odd. I can make guesses, and rationalizations,
but those would be those.
Since we don't really know WHAT your variables contain, any analysis
of that output is a waste of time,
---
Sure ya do! I just typed:
# c='C:\windows\system32'
although Pierre gave some decent
pointers about the general difference between [ and [[.
---
Indeed...(and verily!)
On Wed, Aug 26, 2009 at 01:17:07PM +0300, Pierre Gaston wrote:
Now I'm not too sure why var='"*'"; [[ \* = $var ]] is false while
var='\*' [[ \* = $var ]] is true
Assuming the first part was supposed to be var='"*"' ...
---
Oops...sorry, my bad. I really miscommunicated.
What I meant that I found it odd/confusing that the
True/False indicators for these ops were different:
for (really, when echo'ing correctly ('just ought to have used printf!')
c=«'C:\windows\system32'» and v=«C:\\windows\System32»
«[[ $c = $v ]]» and «[ $c = $v ]»
(and complements)
«[[ $c != $v ]]» and «[ $c != $v ]»
My guess? the [[/]] op dequotes the internally stored form, which in
one case, I think, may contain the actual single quote char?, but then
the equality test strips the quotes for comparison?
Whereas the [] ops know about internal forms and are comparing the
strings: "'C:\windows\system32'" w/ "C:\windows\system32",
so it's not stripping the "SQ"s off the 1st string?
Just a guess...
Linda
