bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: texi2dvi: set -e, use tar


From: Akim Demaille
Subject: Re: texi2dvi: set -e, use tar
Date: Wed, 11 Jan 2006 09:21:44 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

>>> "Karl" == Karl Berry <address@hidden> writes:

 >     compile with -Werror -Wall

 > I do not see -e as at all analogous to -Werror -Wall, or to errno,
 > for the reason I wrote before: not all nonzero exit codes are
 > errors.  

That's my point: not all warnings are errors.  Nevertheless, because
you value the warnings about actual errors, you are ready to write

    if ((token = scan (stdin)))

with a "useless" pair of parens.  That's also why you accept to put
braces in

    if (f)
      if (g)
        h;
      else
        i;

although C is clear about the right parsing.  You accept the cost of
some heavier notations but you benefit from the rest of the service.


 > E.g., foo && bar.  I guess we just have differing
 > opinions/experiences on this :).

I have used it for years, and I still use it a lot in my Q&D scripts.
texi2dvi is no longer a q&d script.


 > However, since in reality you are maintaining texi2dvi, and have
 > done everything of significance to it for some time, if you are
 > happier with -e, then that's ok by me.

Thanks :)

 >     cp -r is fine to copy hierarchies, but not sets of files.

 > I don't understand what you're saying, however, again, if you are
 > happier with tar, that's ok.

I'm saying that

    cp -pr chap1/main.aux chap2/main.aux foo

does not create foo/chap1/main.aux and foo/chap2/main.aux.  Rather, if
it is well educated as is GNU cp, it says:

/tmp % mkdir chap1
/tmp % touch chap1/aux
/tmp % cp -r chap1 chap2
/tmp % mkdir fooo
/tmp % cp -pr chap1/aux chap2/aux fooo
cp: will not overwrite just-created `fooo/aux' with `chap2/aux'

otherwise, I guess there are cp out there that just mess up without
reporting anything.  It turns out that set -e had texi2dvi stop
immediately on that failure that I had not spotted before: I was
addressing another issue, and asked set -e what it thought about it.
It is it too that spotted my stupid "local $var=..." instead of "local
var=...".





reply via email to

[Prev in Thread] Current Thread [Next in Thread]