[tex-live] "fmtutil-sys --all" may not return error exit code under low free space condition always.

Karl Berry karl at freefriends.org
Sun Nov 23 19:10:54 CET 2014

Hi again Zephyrus, months later,

I finally had a chance to look at your fmtutil patch (message archived
at http://tug.org/pipermail/tex-live/2014-May/035443.html), and have
essentially installed it, modulo some stylistic and portability tweaks.
Thank you very very much.

After installing your changes, I went through and removed half of
"#####..." lines and otherwise tightened up commentary (not related to
your patch).

I hope you can try out the new version, which you can get from our svn
repository here:
It is working for me, but I did not try to set up a near-diskfull condition
(pace http://stackoverflow.com/questions/5661966/how-to-make-disk-quota-full).
I've also committed it to the TeX Live runtime (Master/...), so people
using tlmgr can get it that way.

By the way, the native TeX Live fmtutil has never used set -e, so if you
want that, you'll need to add it (as I guess Debian does).  I don't like
set -e, because of its action-at-a-distance effects, resulting logic
contortions, and often-unnecessary-and-confusing aborts.  I think it is
better to check for errors explicitly, as desired, instead of aborting
by default merely because a command exited nonzero.  I know other people
have other opinions, and that's fine, I don't expect to change those
opinions, but I also don't intend to change TL in this regard.

    [log_warning vs. log_failure]

I didn't see a reason to distinguish warnings from errors if both result
in a nonzero exit status.  There didn't seem to be any difference left
between them.  So I simply changed the two remaining log_warning calls
into log_failure and got rid of everything about warnings.  Both of the
calls seemed to deserve failure, anyway: the engine -ini invocation
failing, and the rm -f of the possibly-empty $destfile failing.  I
changed the latter to only run if $destfile actually exists, to combat
broken implementations of rm -f, of which I hope there are none, but ...

    Now I notice that, if fmtutil.sh is passed "--no-error-if-no-format",

I don't think that option matters to your scenarios.  It is passed by
tlmgr when a TeX engine is updated, because it's possible that no
formats are enabled for a given engine.  (Either the packages
have not been installed, or the user has disabled them, or whatever.)
As far as I can recall/determine, that's the only situation in which
it's used.

Let me also mention some of your changes I omitted:

As I understand it, the "strange IFS shuffling" you mention in a couple
places is not strange, and is not about avoiding shell prompts (which
should never happen anyway in non-interactive scripts, afaik).  It's the
standard usage of IFS: specifying where strings are broken into words by
the shell.  So I didn't include those comments.

Negating test conditions so as to put the shorter error-handling first
doesn't work; negating the command itself in conditions (if ! mv ...) is
not portable.  Besides, although I understand the impetus to put the
shorter branch first, I still find it more readable and maintainable to
keep test conditions positive when possible.

I also omitted the comments relating to your thinking process as you
worked through all this.  Comments should not usually be temporal, as in
"used to be this" or "now is changed to that", but rather document how
and why the program works as it is currently constituted.  History can
be found through history.

Finally, just FYI, many shell constructs that may seem puzzling
are described in

thanks again,

More information about the tex-live mailing list