Re: install-sh -C

[Ralf Wildenhues]

* 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