Package: devscripts Version: 2.10.69 Severity: normal $ cat tmp.sh #!/bin/sh fd=2 echo "error" >&$fd $ checkbashisms tmp.sh possible bashism in tmp.sh line 3 (should be >word 2>&1): echo "error" >&$fd
And similarly for: >&${fd}
There was a patch from Raphael Geissert applied which fixes the similar
case where there's a number instead of fd (e.g. >&$2) which autoconf
uses in generated configure scripts:
http://git.debian.org/?p=devscripts/devscripts.git;a=commitdiff;h=e48341562cd7b6220e817c936bf018f57efd3d2b;hp=4068bf40f060326a4027f06b8bdb63b263158817
That patch deliberately doesn't match the >&$foo case (because if $foo
expands to a filename, then that is a bashism). That's also true if $2
expands to a filename of course, but that does seem much less likely in
practice.
Looking at the daca checkbashisms logs, there are >&$foo uses which are
clearly an fd from the variable name, for example:
http://qa.debian.org/daca/checkbashisms/source/sid/gnulib_20100704+stable-1.dsc
} >&$ofd
http://qa.debian.org/daca/checkbashisms/source/sid/git_1.7.2.3-2.2.dsc
printf '%s\n' "$command${sha1:+ }$sha1${rest:+ }$rest" >&$fd
But also ones where it seems likely that the variable expands to a
filename, and others which where it's hard to know without looking at
the script.
My suggestion would be to squash the warning in the case where the
variable name either starts or ends "fd" (case insensitively), which
would fix several real world false positives and is unlikely to
introduce any new real world false negatives.
I did try to patch the regex, but couldn't get it to work easily.
But if there's agreement that checking for "fd" is a sane plan, or
someone has a better idea, I can try harder.
Cheers,
Olly
signature.asc
Description: Digital signature
