On Sat, 2009-05-30 at 21:31 -0500, Raphael Geissert wrote:
> Package: devscripts
> Version: 2.10.49
Are all of the issues you mentioned actually found by that version of
the script? (It's not even the latest /released/ version, and doubly
inaccurate if any of the issues only occur with the changes from your
last report).
> Severity: important
Really? :-) Unless I've missed something in one of the reports, I don't
see what makes this particular set of misdetections more "important"
than any other tbh.
> -------------------
>
> bindgraph_0.2a-4_all.deb
> possible bashism in ./DEBIAN/postinst line 66 ($"foo" should be
> eval_gettext "foo"):
> if [ -z "`egrep "^\s*DNS_LOG\s*=\s*$LOGFILE\s*$" $DEFAULTS`" ]; then
>
>
> possible bashism in ./usr/share/bootcd/bootcdmk2diskconf line 83 ($"foo"
> should be eval_gettext "foo"):
> j="$(echo "$RILABEL" | grep ":$i$" | awk -F: '{print $1}')"
>
> possible bashism in ./usr/share/doc/capi4hylafax/examples/sample_faxrcvd line
> 69 ($"foo" should be eval_gettext "...)
> if [ -n "`echo "$SendFile" | grep "\.tif$"`" ] ; then
>
> possible bashism in ./usr/share/debian-cd/tools/update_tasks line 30 ($"foo"
> should be eval_gettext "foo"):
> task_primary="$(grep -Ev "^(#.*)?(.*-)?[[:space:]]*$" $tasklist)"
"Yay". The new and improved $"" check hasn't elicited any complaints for
over six months - I knew it was going too well. :-/ Cloned as #531326.
> gjots2_2.3.4-2.1_all.deb
> possible bashism in ./usr/bin/gjots2html line 76 (brace expansion):
> m4_changequote({{{{,}}}})
>
> Caused due to incorrectly counting the number quotation marks.
> Fix:
> @@ -265,7 +265,7 @@ foreach my $filename (@ARGV) {
> $templine =~ s/$otherquote.*?$quote.*?$otherquote//g;
> # "\""
> $templine =~ s/(^|[^\\])$quote\\$quote$quote/$1/g;
> - my $count = () = $templine =~ /(^|[^\\])$quote/g;
> + my $count = () = $templine =~ /(^|(?!\\))$quote/g;
>
> # If there's an odd number of non-escaped
> # quotes in the line it's almost certainly the
Hmmm, okay. Note that while this may fix this instance, our bête noire
git-instaweb still isn't parsed correctly. :-/
> > possible bashism in ./usr/bin/nws_html_hosts line 61 (should be '.', not
> > 'source'):
> > source destination | grep -v "^hostpair" | \
> > possible bashism in ./usr/bin/nws_html_hosts line 64 (should be '.', not
> > 'source'):
> > source destination | grep -v "^hostpair" | \
>
> l60: eval $searchCommand throughput throughput_prediction
> throughput_mse \
> l61: source destination | grep -v "^hostpair" | \
> l62: awk ' {if(NF>1) {printf "%s ", $2; if($1=="destination")
> print ""}}' > $bwFile
>
> No idea why they are not being correctly parsed; but it isn't fixed by the
> above patch :(
These are both due to the line continuation which means line 161 is
matching "^\s*source". Cloned as #531327 as I suspect making this work
isn't as simple as it might first sound (as the solution must interact
properly with the quoted block stuff).
> -------------------
>
> possible bashism in ./usr/src/gcc-4.1/patches/pr9861-nojava.dpatch line 112
> ('function' is useless):
> +#define DMGL_RET_POSTFIX (1 << 5) /* Print function return types (when
>
> On IRC I said it should be enough to consider #!/bin/sh /path/to/foo scripts
> as evil, but after reconsidering I don't think it is the right solution.
> So far I came up with this workaround:
>
> @@ -451,6 +451,9 @@ sub script_is_evil_and_wrong {
>
> $ret = $. - 1;
> last;
> + } elsif (m'@DPATCH@') {
> + $ret = $. - 1;
> + last;
Yeah. It'll still miss cases where the dpatch includes a valid /bin/sh
script with bashisms, but it's better than nothing.
> -------------------
>
> Misc corrections:
[...]
> The "arithmetic not allowed" check was not matching all the cases, and since
> echo "$[1 + 2]" works in bash, the working check should be moved to
> string_bashisms.
Ok.
> And there's no reason (unless you refresh my mind :) not to use $LEADIN in
> the 'readonly' check.
Not that I can think of right now.
[...]
> Stops warning about unsafe a backslashed backslash, since it works in all
> shells and is used by libtool.
Ok.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
