Re: manpage note? weird strings that appear to be equal but create haywire comparisons?

[Linda Walsh]

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