Bug#264241: postrm assumes mktexlsr is available
Hilmar Preusse <hille42@web.de> wrote:
> tags 264241 + patch
> stop
>
> On 10.08.04 Ryan Murray (rmurray@debian.org) wrote:
>> On Tue, Aug 10, 2004 at 02:34:20PM +0200, Hilmar Preusse wrote:
>> >
>> > #!/bin/sh
>> > <snip>
>> > command mktexlsr >/dev/null 2>&1 && mktexlsr
>> >
>> > The man page of bash tells us, that it should be sufficient to do
>> > so if /bin/sh points to /bin/bash. I guess we have to remove the
>> > bashism
>>
>> It does? To me, it looks like you run mktexlsr twice, once via command,
>> and once without. And both will fail if mktexlsr doesn't exist.
>>
> OK, sorry. We call mktexlsr twice, the second time if it fails the
> first time.
Looking again, we do not. The first time, we call it via command,
suppressing shell function lookups (which doesn't make sense), and only
if it is _successfull_ we call it again.
I think the code is a misunderstanding; I guess someone thought that
"command foo" would only check whether the command exists, and not
execute it; therefore the second call in case of _success_.
> I dunno exactly why we do this, but IIRC some things are
> cured, if we call it twice. Unfortunately we don't check if mktexlsr
> exist, before doing this. I guess we have to put an test -x wrapper
> around.
If it was intended to run mktexlsr again if something went wrong in the
first run, something like
mktexlsr || mktexlsr
would be right. But we didn't do this, and therefore it does not make
sense to keep it, IMO.
The problem we get with the bashism is that with bash, command exits
with 127 if the command cannot be found, and the second call is not done
- whereas with other shells it seems to exit 0.
So the way to solve this is to replace the bashy "command" by an -x
expression, dropping the second invocation completely.
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: