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

[Pierre Gaston]

On Wed, Aug 26, 2009 at 12:45 PM, Linda Walsh<bash@tlinx.org> wrote:
> I was scripting and fixing some permissions in Win,
> and had a var 'c' set to (no quotes in the var):   'C\windows\system32'
<snip>

> I first bumped into this using the printf -v var "%q" feature, where
> I expected it to doublequote the back slashes. But instead, it looked
> like I got the same value assigned to v as though I'd just done a 'c=v'
>
> # printf -v v "%q" $c
> # echo  $v |hexdump -C
> 00000000  43 3a 5c 77 69 6e 64 6f  77 73 5c 73 79 73 74 65
>  |C:\windows\syste|
> 00000010  6d 33 32 0a  00000014

here is what I get:
$ echo $v | hexdump -C
00000000  43 3a 5c 5c 57 69 6e 64  6f 77 73 5c 5c 53 79 73  |C:\\Windows\\Sys|
00000010  74 65 6d 33 32 0a                                 |tem32.|
00000016

if you run your test prog after setting  "set -x"  (or run it with
bash -x testprog)
you will see the double \\.

<snip>

> Note that [[ and [ return different results when the vars are unquoted.

The bash keyword [[ and [ are different in several ways (word
splitting does not occur for instance)
in your example the difference is that = inside [[ ]] does pattern matching.
(note that in the case of bash [ is also a builtin)

*  If you quote the right hand side variable, then the expression is
taken literally, the test becomes:

[[ 'C:\Windows\System32' != 'C:\\Windows\\System32' ]]

and it's false.

* If you don't quote the right hand side variable, then the expression
is taken as a pattern, the test becomes

[[ 'C:\Windows\System32' != C:\\Windows\\System32 ]]

in this glob the the \ is consider as escaping the other \ and the 2
variables are equal.

That explaine the differences.

Now I'm not too sure why var='"*'"; [[ \* = $var ]] is false while
var='\*' [[ \* = $var ]] is true