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 <br...@clisp.org> > > 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.
