* Akim Demaille wrote on Mon, Oct 23, 2006 at 07:20:38AM CEST: > >>>I have some problems with these definitions. If there are several > >>>files that have the youngest time stamp, then the order depends on > >>>the locale. > >> > >>Nia? How can the locale change the order to time stamps? > > > >Only if the time stamps are the same:
> I still don't understand how find can make a better job. Since > it uses the same time stamp its own order might even be non > defined. So anyway the user of the test itself has to know that > the test should not be used when arguments are too close in time. Certainly. But frequently in Automake tests the problem is as follows: do_something with $file $sleep touch stampfile do_something_else with $file ensure that $file is updated/not updated. If the last command is done with `ls -1t', I either have to think about the locale ordering in case that do_something_else finishes quickly (i.e., in less than a second; even if it doesn't now, it will in a couple of years). Or I have to add another $sleep after the touch. Or I use find stampfile -newer $file which ensures me that $file is at least as new as stampfile. > Do you know of any means to compute the list of files with *equal* > time stamp? Hum, playing with repetitive calls to find -not -newer > should do that, Exactly. > but looks expensive. I don't think so. A $sleep takes two seconds on my system, a find takes about 5 ms. > Interresting thread (congratulations Sherlock!), but again, I fail to > see any added value to find compared to ls. If the result is undefined > because the time stamps are too close (read equal), then I don't care > about determinism. So you prefer to add another $sleep in the above scenario. > >>+set -e > >> required=gzip > >>-. ./defs || exit 1 > >>+. ./defs > > > >I don't think `defs' is written to be `set -e' clean. At least all > >other tests only enable it after sourcing defs. > > Agreed, but what do you suggest: proofreading defs so that it'd > be, or do as in the other tests? Do as in the other tests. You could also proofread, if you like. But it will be a bit ugly. For example you will have to write | if test -n "$required" | then [...] | if ( bison --version ); then :; else exit 77; fi instead of | ( bison --version ) || exit 77 because of the OpenBSD /bin/sh bug with `set -e' that is described in http://www.gnu.org/software/autoconf/manual/html_node/Limitations-of-Builtins.html#index-g_t_0040command_007bset_007d-1240 > I prefer the former, that's more factorized. I have some qualms about the Bourne compatibility initialization, and whether it can be made `set -e'-clean. I saw weird issues with AIX /bin/sh in Libtool, but have not been able to get to the bottom of those yet. (I've been meaning to do that in order to be able to write a helpful bug report to Autoconf.) > BTW, I don't know if there is any value in that, but we could > factor even more by changing the scripts' bangshees to using > ./defs. Do you mean putting #! ./defs at the start of the *.test files? No, I don't think that's of much value. AFAIR (but I don't remember too well) security "hardened" Linux kernels can limit the set of allowed interpreters in bangshee lines. (Ignoring for a second that I have no idea whether it's portable to assume that a kernel will look up the interpreter recursively, i.e., also in the ./defs file that is the interpreter; also I think some systems require an absolute path there.) Confirming some of my qualms: http://homepages.cwi.nl/~aeb/std/hashexclam-1.html#ss1.5 Also very readable: http://www.in-ulm.de/~mascheck/various/shebang/ Cheers, Ralf
