bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BLOCKER] cannot single-step unit tests any more


From: Jim Meyering
Subject: Re: [BLOCKER] cannot single-step unit tests any more
Date: Mon, 17 May 2010 13:43:49 +0200

Bruno Haible wrote:
>> I don't see how this can cause a problem.
>>
>> The only uses of $0 are in the re-exec code (which appear not to matter
>> when single stepping)

Hi Bruno,

> If the user starts a shell other than bash interactively, and tries to do
> ". ./init.sh", he may fall into the re-exec code, and the init.sh script
> will then kill his interactive process, which is unfriendly (it may kill
> his xterm, leaving him completely clueless about what happened).
>
> It is safer to try to re-exec and use "$0" when there is enough confidence
> that the execution mode is not interactive. Here is a proposed patch.
> (Btw, $ME_ was used before being initialized.) I have also no problem
> indenting the big 'if/else' branch by 2 spaces.
>
> 2010-05-16  Bruno Haible  <address@hidden>
>
>       init.sh: Avoid aborting from an interactive shell.
>       * tests/init.sh (gl_better_shell_): New variable.
>       When executing in an interactive shell, don't re-exec; instead, give a
>       warning and skip to the end of the file.

Thanks for the patch and explanation.

You say "other than bash".
Do you deliberately exclude zsh?

I appreciate your effort to make init.sh debuggable also for
developers using inferior shells, but I do not like the end result.
Putting most of that script in an "else" block impairs readability.
An alternative would be to print a diagnostic and sleep forever.
Encourage the developer to interrupt.

Another possibility is simply not to accommodate developers who
want to single-step through test scripts without first starting
from a capable shell.

I suspect that of the very few people who will ever
single step through an init.sh-using test, an even smaller
proportion (very likely to be "zero") would be affected.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]