Re: [PATCH 3/5] gdb/testsuite: Adjust some testcases to allow Windows pathnames

[Sandra Loosemore <sandra.loosemore@siemens.com>]

On 4/21/23 08:44, Tom Tromey wrote:
>>>>>> "Sandra" == Sandra Loosemore <sandra@codesourcery.com> writes:
> 
> Sandra> This patch fixes some testcases that formerly had patterns with
> Sandra> hardwired "/" pathname separators in them, which broke when testing on
> Sandra> (remote) Windows host.
> 
> Sandra> +    set STRINGHOME ""
> Sandra>      set test "show environment HOME"
> Sandra>      gdb_test_multiple $test $test {
> Sandra>  	-re "\nHOME = (\[^\r\n\]*)\[\r\n\]+$::gdb_prompt $" {
> Sandra>  	    set HOME $expect_out(1,string)
> Sandra> +	    if { [ishost *-*-mingw*] } {
> Sandra> +	      # Backslashes in the pathname must be escaped for the patterns
> Sandra> +	      # that match quoted string output.
> Sandra> +	      regsub -all {\\} $HOME {\\\\} STRINGHOME
> 
> I don't understand this one, because the uses all use string_to_regexp.
> But if the computed value of HOME doesn't work in that context, then it
> seems like that means there is a bug in string_to_regexp, because the
> contract of string_to_regexp is to return a regexp that will exactly
> match the input, no matter what it is.

The output of the two commands it is trying to match using STRINGHOME 
(as opposed to HOME) is

p $_gdb_setting("history filename")
$1 = "C:\\cygwin\\home\\sandra/foobar.baz"

p $_gdb_setting_str("history filename")
$2 = "C:\\cygwin\\home\\sandra/foobar.baz"

E.g., the output is printed with C string syntax, in which every 
backslash is doubled.  So the thing passed to string_to_regexp also 
needs to have doubled backslashes.

> 
> Sandra> -	"The filename in which to record the command history is \"[string_to_regexp $HOME]/foobar.baz\"..*" \
> Sandra> +	"The filename in which to record the command history is \"[string_to_regexp $HOME].foobar.baz\"..*" \
> 
> Also why didn't this one need to be changed?  (Though if there really is
> a bug in string_to_regexp then it's irrelevant.)

Because in this case the output it is trying to match does is *not* 
printed with C string escapes in spite of the surrounding quotes.

Maybe this just needs more comments?  Or is there a utility function to 
add C escapes to a string that should be used on non-Windows hosts too?

-Sandra