On 10/18/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
On Wed, Oct 18, 2006 at 09:47:43AM +0700, Theppitak Karoonboonyanan wrote:> Is there some specific reason for using "mv -i ... < /dev/null" ? > It looks strange to me, but many times strange stuffs have > their own reasons. Can it be "mv -f ..." ? If $TEXDIR/babel.sty exists and $TEXDIR/babel.sty.undivert exists, the admin has changed something by hand and we can't be sure any more which of these is the file belonging to thailatex. Calling "mv -f" would ignore that uncertainty; using "mv -i" treats that uncertainty as a reason not to continue. (The < /dev/null avoids any prompts being sent by the maintainer script: we just want to fail out, not interact with the user.) This could also be written as if [ -e $TEXDIR/babel.sty ] && ! [ -e $TEXDIR/babel.sty.undivert ]; then mv $TEXDIR/babel.sty $TEXDIR/babel.sty.undivert fi which may indeed be a clearer way to write it.
Ah.. This is the key to understanding the whole logic. Thank you for enlightening me.
> What happens if the "if [ -e $TEXDIR/babel.sty ]" clause fails? > Does it mean the babel.sty.undivert won't be created and the > second mv will fail? The only reason that $TEXDIR/babel.sty should not exist here is if the postinst has already moved it aside in preparation for the undivert. If this clause fails for any other reason, that's a big (admin-induced) problem, and the second mv will fail *by design* to avoid declaring the package "installed" when files have been randomly removed...
OK. I got it.
> >- The script is idempotent; we know that $TEXDIR/babel.sty will exist the > >- The diversion removal will always succeed unless the user has manually > > adjusted files. > >- The final mv will always succeed unless the user has manually adjusted > > files, and as a result give us a $TEXDIR/babel.sty file that we're > > assured > > of being the copy from thailatex. > I'm not so sure about this. Should the final mv be guarded with > "if [ -e $TEXDIR/babel.sty.undivert]" ? If $TEXDIR/babel.sty.undivert is missing, should the script succeed? I believe that it should not, but there's no reason why your maintainer script *must* fail in a situation like this.
All right. Thank you for your explanation. It's now clear to me. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
