On Tue, 20 Dec 2022 at 02:51, Jacob Bachmeyer <jcb62...@gmail.com> wrote:
>
> 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.
I see. How about added an additional {noecho 0} parameter to
local_exec, causing it to add -noecho to the spawn command?
The existing behaviour wouldn't change, but remote_exec could pass 1
there to request the -noecho.
>
> 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
>
