Re: testsuite failures when test scripts are run with zsh

[Ralf Wildenhues]

Hi Jim, Stefano,

* Jim Meyering wrote on Sun, Oct 11, 2009 at 01:41:25PM CEST:
> Stefano Lattarini wrote:
> ...
> >> Hmm, I'm a bit leery of making things read-only, but making sure
> >> the files contain a "generated by ... " line near the top seems a
> >> good idea.
> > In truth, I don't find that much useful in order to prevent
> > "unintentional" editing: I have ended up too many times modifying
> > tests/defs instead of tests/defs.in, even if it has the customary
> > address@hidden@' line at the top (yeah, stupid me, but I lost time
> > anyway).  On the contrary, the fact that a file is read-only is a much
> > clearer and outstanding indicator of the fact it should not be
> > modified, and is anyway easily circumvented in the case you really
> > need to modify that file.  I'm stressing this because I think that
> > making generated files readonly would be very very useful to the
> > absent-minded developer or contributor (e.g., me).

> Ralf,
> Why are you reluctant to make any generated file read-only?

Basically, because I'm lazy.  Some non-GNU systems have slightly
different semantics wrt. read-only files, and I keep forgetting what
the exact differences are, and am afraid to introduce silent bugs there.
Also, here is another big warning sign that files are not pristine
sources: these files live in the build tree, not the source tree
(hmm, that's not true for a distribution tar ball currently).

I realize that I'm weighing my time against other developer time here,
and in any case the generated tests are not a big issue this way or
another, so I guess these would be alright to change.

> I've been lobbying for this in many projects for a long time,
> for exactly the same reasons.  I've wasted too much time
> (even if it's just a minute or two per incident) by inadvertently
> modifying a generated file rather than the template from which
> it is generated.

There are several prominent instances of generated files that are not
read-only.  The Makefile.in files that automake generates, the
config.status file that configure generates, and the Makefile files that
config.status generate, are not made read-only, neither is the libtool
file that the Libtool macros/config.status generate.

Making those files read-only will break other packages out there; while
the practice to modify these files (either manually, but quite often
also automatically) may not be best practices, it is definitely a
practice we should not (try to) forbid, or code that we should break.
So I'd oppose changing their modes.

> The only potential gotcha is that when redirecting to the temporary
> file, you have to be careful to remove the read-only file beforehand,
> or to ensure that it writable.

Yes, that's an issue.  I think you also need -f with rm; and I think not
all vi instances will overwrite such a file even with :w!, but haven't
checked now.

Cheers,
Ralf