Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > ... > With the above definition of "which", the only sign of a mistake would > be some extra output to stderr (which is quelled when running tests in > the normal way). The "exit" is caught by the subshell and just makes > the "if" condition false. > > That's not so terrible --- it could still dissuade new test authors > from using "which". The downside I'd worry about is that it provides > a false sense of security despite not catching problems ... > ... > In the end the analysis that works best would probably involve a > full-fledged shell script parser. Something like "sparse", except for > shell command language. Exactly. That is why I keep saying that whole test-lint-shell-syntax should stay outside the default until it gets more robust by becoming a reasonable shell parser; it may not necessarily have to become "full" parser though. As we discourage the use of tricky features of the language like eval in individual test scripts to implement their own mini test framework, the "something like sparse" parser may initialy start small and still be useful; for example it can learn to exclude anything inside <<HERE_DOCUMENT from getting inspected. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html