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
