Hi,
This is going to be my last post here.
I posted a very lengthy post to tex-live mailing list to
follow up on my finding here.
http://tug.org/pipermail/tex-live/2014-May/thread.html
I posted a proper patch there. It is near the end since it was posted
a couple of days ago.
Good news is that I tested the modified fmtutil.sh under two Debian
linux systems by making "/var" partition full (totally full, and
partially full by creating a large file under /var/tmp), and I am
confident that the modified fmtutil.sh works much better:
- it prints the warning and error messages much more reliably than the
current version.
(It succeeded under the near full/full conditions of my testing.)
- it returns proper error code in each failure case.
I believe I have covered all the corner cases.
Well, Famous Last Words.
So, I don't claim it is perfect, but it is much better.
TWO MAJOR BUGS UNCOVERED
The two major bugs discovered after my last post to Debian bug
tracking are follows. I was not aware of the second problem below and
so was wondering in detail if the tricky syntax of "verbose" could be
the cause of the strange behavior in previous postings. (It still
could be, but even after my modification to "verbose", the following
two bugs showed up..)
It turned out that a couple of commands may have been responsible for
- the failure of flushing the warning and error messages at the end.
(A command was not properly checked and so it triggered trap
processing bypassing "byebye" processing that would have flushed
the messages.)
It would still return exit code 1. Hmm...
- the failure to return the error code properly. An "mv" command was
executed in the following manner.
if mv .... < /dev/null
then
...
...[lengthy processing]
...
fi
Note that there was NO "else" block to handle the error of "mv"
(say, due to full file system) by calling "log_failure", etc.
Possible error caused by full file system, etc. was used up by "if"
checking itself, and no error exit code was ever produced. In this
case, error code is forgotten! Bad, bad, bad.
(The second problem did not show up on a linux installation, but
it became apparent on a different linux installation. That is how I
noticed the bug.)
In the proposed patch to tex-live@tug.org, I reverted the test
condition of "if mv ... < /dev/null" to "if ! mv ... < /dev/null" so
that the error processing block comes first before the lengthy normal
processing. It is much easier this way to understand the structure of
the code.
Last time I checked, the very long normal processing block made me
lose the fact that there was no matching "else" block. I mistook
another "else" block for the missing one.
I will monitor tex-live mailing list although, as noted by Norbert,
people seem to be very busy preparing 2014 TeXLive image.
We have to wait for the stable upstream version. But it will be great
if we can incorporate the gist of changes into Debian packages
eventually. ("set -e" was not in TeXlive 2013, it is a Debian
addition, for example.)
TIA
PS: In the end, rewriting fmtutil.sh in Perl, C, java, or whatever
reasonably powerful programming language might be
better because the loose standards regarding the
trap handling of the failure of command when "set -e" is issued.
I see "byebye called" in the posted log to tex-live
mailing list: the log was produced under almost full /var partition condition.
E.g.:
[...]
'mv tex.fmt /var/lib/texmf/web2c/tex/tex.fmt' failed
'mv dviluatex.fmt /var/lib/texmf/web2c/luatex/dviluatex.fmt' failed
byebye called
We had error(s).
If somehow subtle change of trap handling occurs due the differences of
shell versions, some installation failure may see
byebye 1 called
instead. (This is how "byebye" is called in my modified version from
trap processing.) Such a line will give us the clue of the different
way of trap handling under the particular shell used.
Thank you again.