Re: Pass the -noecho option to spawn

Jonathan Wakely wrote:
> Is there a reason that dejagnu's local_exec proc doesn't use the
> -noecho option for spawning the command?
>
> Every log contains the spawned commands twice because dejagnu prints
> it then spawn repeats it (with an annoying \r appended, making copy &
> paste from the logs more awkward than it needs to be).
>
> For example:
>
> Executing on build: msgfmt -o fr/LC_MESSAGES/libstdc++.mo
> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/../po/fr.po
> (timeout = 300)
> spawn -ignore SIGHUP msgfmt -o fr/LC_MESSAGES/libstdc++.mo
> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/../po/fr.po^M
> Executing on build: msgfmt -o de/LC_MESSAGES/libstdc++.mo
> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/../po/de.po
> (timeout = 300)
> spawn -ignore SIGHUP msgfmt -o de/LC_MESSAGES/libstdc++.mo
> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/../po/de.po^M
>
>
> I find this annoying. Is there any reason not to disable it?
>
> diff --git a/lib/remote.exp b/lib/remote.exp
> index 1c9971a..1e45810 100644
> --- a/lib/remote.exp
> +++ b/lib/remote.exp
> @@ -165,7 +165,7 @@ proc local_exec { commandline inp outp timeout } {
>     global errorInfo
>     if { $inp eq "" && $outp eq "" } {
>        set id -1
> -       set result [catch "eval spawn -ignore SIGHUP \{${commandline}\}" pid]
> +       set result [catch "eval spawn -ignore SIGHUP -noecho
> \{${commandline}\}" pid]
>        if { $result == 0 } {
>            set result2 0
>        } else {
>
>
> I don't know whether the other spawn command on line 193 should also
> use -noecho, I've only patched line 168 locally. With that change, my
> logs are half the size and have no annoying carriage returns.

The main problem with this patch is that lib/remote.exp:local_exec is 
documented, so it can also be called by testsuite code.  If local_exec 
is called directly, only the message from spawn will appear in the log, 
since the "Executing on ..." message is from remote_exec.  Using -noecho 
would suppress that message, leaving no indication at all of what was 
run in the log.  This is not a problem for your use case, but may cause 
problems for other testsuites, so the patch as suggested cannot be taken 
upstream.

At first glance, there appear to be a number of bugs in local_exec as it 
currently stands (mostly with the alternate code path that does not use 
spawn), so I have added this issue to my list of issues to address in 
lib/remote.exp.  Once I find a solution to ensure that the command run 
appears in the log, I probably will add -noecho to the spawn call(s).  
These will probably not be addressed in 1.6.4 but are on the TODO list.


-- Jacob