Re: install-sh -C

[Akim Demaille]

> 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.

OK, so I finally understand: you are ok with working with
"newer or as older", while I'm stating that using find or
ls is just the same when you are interested in "strictly
newer".  It is our usage that differs.

Hum.  Actually, are you sure "-newer" means what you claim?
"ensures me that $file is at least as new as stampfile" while
it seems to mean that it is strictly newer than stampfile.
At least on OSX:

     -newer file
             True if the current file has a more recent last  
modification time
             than file.

address@hidden $ touch foo bar
address@hidden $ find foo -newer bar
address@hidden $ find bar -newer foo
address@hidden $ find . -newer foo
address@hidden $ find . -newer bar
address@hidden $

I used it in the attached patch.

> > 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.

Absolutely.

> > > > +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

Gee!  That's a new one :(  I know that

        false && echo

is not safe with -e (and actually, it does seem fair), but I did not
know

        false || echo

could be a problem.  BTW, the example in the Autoconf doc would
be much clearer (IMHO) with true and false instead of test.

> > I prefer the former, that's more factorized.

Factored!  Shame on me :(

> 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.)

But working without -e is so dangerous too...

Here is my updated proposal.

diffs.txt
Description: Text document