Broken test in testset/maintainer-scripts/debian/postinst ?

["Adam D. Barratt" <adam@adam-barratt.org.uk>]

[Apologies if the following is overly verbose; I erred towards
potentially including too much information rather than too little]

Hi,

One of the changes I've made in checkbashisms is to modify the check
for heredoc delimiters to match against a copy of the input line which
has had most (intentionally not all) quoted strings removed from it
rather than simply matching against $_ as lintian's checks/scripts
currently does. (The change in question is part of my outstanding
patchset).

The change was originally made to fix a false positive error in
checkbashisms's (experimental) makefile support which was treating the
<< in a dpkg-shlibdeps call as the start of a heredoc structure. At the
time I was confused as to why the code in lintian worked and
checkbashisms equivalent didn't; after some investigation, I believe the
answer is that lintian's check /doesn't/ work either and that the fact
that lintian only checks maintainer scripts for bashisms (and therefore
heredocs) currently is masking the problem.

The testset does contain a couple of checks for the code in question,
but I think a logic error in one of them is another reason that the
issue has been masked. Specifically,
testset/maintainer-scripts/debian/postinst currently contains this
snippet:

        # This too is a heredoc.
        some-program > /etc/config-file <<'EOF'
        echo "All of the array is: ${H[@]}"
        EOF
        
        # But this isn't.
        cat '>>EOF'
        echo "All of the array is: ${H[@]}"
        EOF
        
The latter section clearly isn't a heredoc as it's using >> rather than
<< :-) If, however, the cat is modified to use '<<EOF' then the bashism
on the penultimate line is no longer matched (and therefore a
debian/rules runtests against maintainer-scripts fails), indicating that
lintian is treating the string as a heredoc despite it being quoted.

As I mentioned, checkbashisms correctly detects the above with s/>>/<</
so the bug in checks/scripts will be fixed once the relevant patch is
applied (which I realise is dependent on my having provided said
patch...) but I just wanted to mention the above issue with the test and
check that I wasn't missing something obvious as to why the test is as
it is.

Thanks,

Adam