Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> thanks for your quick reply.
NP
> On Tue, 23 Oct 2007, Ian Jackson wrote:
> > Changes to debian/changelog always tend to get rejected if you apply a
> > patch to a different version because the context is the previous
> > version which contains the previous version number.
>
> yeah it is a primitive versioning system.
Annoying, isn't it. It's nice to see some efforts towards improving
the situation ...
> > test(1) has really strange argument parsing, [...]
>
> ok thanks for the lesson.
> never the less i'd prefer to have more readable code,
> then to take into account crazy non posix sh.
> update-initramfs is anyway linux specific.
I think you misunderstood me. I'm not saying that failing to use
"x$..." is nonportable. I'm saying that it can be ambiguous in the
sense that even the test(1) we're actually using (in practice, the
builtins in bash and dash) may sometimes get it wrong, where `wrong'
means `not what we intended'.
My example was that if you write
test '(' "$var" ')'
then it will go wrong when var='=' because it is interpreted as if you
had meant
test "$a" = "$b"
with a='(' and b=')'.
The exact circumstances in which the expression can be ambiguous are
very complicated. The best approach therefore is to prefix the
arguments to these kind of comparisons with `x' so that they cannot be
misinterpreted by test as operators. Ie the solution is to write
test "x$var" != x
which can never look like anything except a comparison because none of
test's operators or syntax start with an x.
If we write our scripts this way all of the time then there is no
possibility that someone who later makes the code more complicated by
adding additional clauses to the test, or introduces additional
possible values for the inputs, will cause it to break. And we get
into the habit of writing code which is always correct, without having
to prove each time that the particular construction we use can never
be misunderstood by test(1).
This area is a subset of the principle of argument unparsing - that
is, how to pass arbitrary arguments to a program without possibility
of misunderstanding.
In general if you see constructions of the form
command-name "$inputvariable" ...
you should be suspicious. What if inputvariable contains a string
which is meaningful to command-name as an option ? Hence
command-name -- "$inputvariable" ...
et al.
> > In the future I imagine debhelper will copy <package>.triggers into
> > the right place itself.
>
> debhelper does it according to joeyh,
> i haven't looked yet at how i'd have to invoke it.
Oh, has he added that already ? The version I had to hand didn't seem
to but perhaps I misread the documentation or was reading the wrong
version.
> i'll see to push a variant in git next days,
> may ping you for review..
Sure.
> so that i can upload it promptly with new dpkg.
Excellent. (As I said, though, I think there is no need to wait.)
Ian.
Reply to: