[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: testsuite failures when test scripts are run with zsh
From: |
Ralf Wildenhues |
Subject: |
Re: testsuite failures when test scripts are run with zsh |
Date: |
Sun, 11 Oct 2009 14:56:38 +0200 |
User-agent: |
Mutt/1.5.20 (2009-08-09) |
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
- Re: testsuite failures when test scripts are run with zsh, Ralf Wildenhues, 2009/10/08
- Re: testsuite failures when test scripts are run with zsh, Stefano Lattarini, 2009/10/09
- Re: testsuite failures when test scripts are run with zsh, Stefano Lattarini, 2009/10/09
- Re: testsuite failures when test scripts are run with zsh, Ralf Wildenhues, 2009/10/10
- Re: testsuite failures when test scripts are run with zsh, Ralf Wildenhues, 2009/10/13
- Re: testsuite failures when test scripts are run with zsh, Stefano Lattarini, 2009/10/13
- Re: testsuite failures when test scripts are run with zsh, Ralf Wildenhues, 2009/10/16
- Re: testsuite failures when test scripts are run with zsh, Stefano Lattarini, 2009/10/16
- Re: testsuite failures when test scripts are run with zsh, Stefano Lattarini, 2009/10/23
- Re: testsuite failures when test scripts are run with zsh, Stefano Lattarini, 2009/10/28