[tex-live] "fmtutil-sys --all" may not return error exit code under low free space condition always.
zephyrus8080 at gmail.com
Wed Nov 26 16:01:05 CET 2014
Thank you for taking the time to digest my patch and commit it to the
original source repository.
The description of what you took and omitted was an interesting reading.
> (if ! mv ...) is not portable.
I should have known! I thought it was one of the few things that I could
assume across many shells.
Again, thank you so much for the inclusion of the essence of my patch.
I use Debian on my linux installations (basically desktop work, and one
So once Debian's package gets refreshed (I think Nobert is reading this.),
I will have a chance to try this new script.
Partitions on a few PCs under my control are always near full without my
intending to make them so
[I am afraid that Debian's default partition setting does not reflect the
bloating of many modern packages especially the ones with good
documentation material: I am horrified to look at the default partition
size offered by Debian's automatic installer lately. The offered size would
be too small to hold
many development packages and TeX-related packages altoghether, and I am
not hoarding up
many development packages myself. Maybe a minimum to compile moizlla
firefox from command line.],
and so would be good test beds.
2014-11-24 3:10 GMT+09:00 Karl Berry <karl at freefriends.org>:
> 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
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tex-live