Re: [RFA] completion in command definition

[Pedro Alves <palves@redhat.com>]

On 01/31/2017 03:29 PM, Jerome Guitton wrote:
> Pedro Alves (palves@redhat.com):
> 
>> A few minor comments below.
> 
> Thanks again! Comments integrated. I'm just not sure about this one:
> 
>>> +
>>> +  gdb_test "info break \$bpnum" \
>>> +    "Num     Type\[ \]+Disp Enb Address\[ \]+What.*
>>> +\[0-9\]+\[\t \]+breakpoint     keep y.* in main at .*
>>> +\[\t \]+echo.*" 
>>
>> I think we need to use use multi_line, to avoid problems with
>> "\n" vs "\r" vs "\r\n".
> 
> I've used the same code pattern as in break.exp; is that OK?
> 

ISTR that on some hosts (maybe native Windows testing, but not
Cygwin), we can end up with tcl/expect seeing different end lines
from what we normally get on Unix, due to different levels
of \n -> \r\n -> \n translation going on.  Might have been on
macOS, due \r being preferred there.  I think tcl translates end lines to \n
from files by default for input, and uses native eol for output.  I think
the way it's written above makes the end lines in the regexp's depend
on how tcl reads eol out of the script file.  So if gdb actually
outputs "\r" only, the regexp won't match.  Or something like that.  It may
be working as is due to each line ending with ".*".
It's messy, and a might be a bit of cargo-culting is in place (not
sure how relevant this all still is, we don't hear much about
native Windows testing driven by native Windows expect, for
instance), but as far as I remember, we've avoided writing
multi-line regexps like that.

Thanks,
Pedro Alves