* Peter Rosin wrote on Sun, Oct 03, 2010 at 08:28:47PM CEST: > Den 2010-10-03 09:01 skrev Ralf Wildenhues: > >> +for i in 25 50 75 100 125 150 175 200 225 250 > >> +do > >> + PATH="$PATH$PATH_SEPARATOR/somewhere-that-eksists-not"
> > Does $LIBTOOL or the autotest machinery ever intentionally try to run > > commands that won't exist in $PATH within this shell? > > I don't think so, and it is a really hard question to answer too. Indeed. I'm kinda wondering whether we should at least delimit our use of nonexistent files and directories to a common subtree, like below /nonexistent or so. I realize we're getting near bike shedding issues though, so how about we cross that bridge when we get to it, and leave your patch as is for now. > > If so, then we > > might get the odd bug report from security-hardened distributions that > > complain about read or execute accessses to non-allowed parts of the > > file system. > > Using "$PATH$PATH_SEPARATOR$PATH" seemed like a much quicker way > to make the length explode so I didn't like that. OK. > > This length doesn't yet trigger the compiler string literal length > > limit; not sure whether it should? > > That's not reliable anyway as most compilers support so long strings > that it's hard to tickle it. FWIW, that is not necessary. It would be sufficient if it were tickled with the one compiler in question. > On a tangent, another bug is that linking > doesn't fail (libtool returns zero) when building the cwrapper fails. > I think that's a separate issue from this one, which is why I haven't > mixed them up previously. OK, good. > Another nit in that area is that there are > multiple levels of "$opt_dry_run || {" which seems superfluous, but > that might be intentional in order to keep the code copy-paste-safe? Not sure. I don't have much sympathy for copy-paste-safety, because I dislike the kludge that copy-paste is. Functions should be used instead. So yes, I guess a cleanup is a good idea, after ensuring that the code really works fine with the outer opt_dry_run enclosing. > > Do we have to cater to the case where the environment is very large > > already? I'm not sure, we might want to deal with it when crossing > > that bridge only, if it's hard to know off-hand. > > Are your three above paragraphs nits and part of what I need to > address, or just notes for the future? They started out as nits, but I guess they've become notes by now. So go ahead with your patch, please. > >> +# try to make sure the test is relevant > >> +AT_CHECK([grep ' *fputs' $objdir/lt-usea.c > /dev/null]) > > > > Rather than redirecting stdout, put [ignore] in the third argument. > > Certainly possible, but I didn't think anyone would be interested in a > couple of hundred lines of boilerplate in the log. I don't really care > though, so if you still think [ignore] is a good idea, then ok. Ah yes. Autoconf 2.64 provides stdout-nolog for this, but I guess you can keep the code the way it is, for compatibility. Thanks, Ralf