Re: [PATCH 8/7] syntax-check: fix violations and implement sc_useless_quotes_in_case_branch.
Hi Eric,
On 22 Nov 2011, at 12:09, Gary V. Vaughan wrote:
On 21 Nov 2011, at 23:15, Eric Blake wrote:
On 11/21/2011 07:47 AM, Gary V. Vaughan wrote:
Contrary to popular belief, Bourne shell does not resplit case
expressions after expansion, so if there are no shell unquoted
shell metacharacters or whitespace, the quotes are useless.
@@ -568,7 +568,7 @@ func_resolve_sysroot ()
# store the result into func_replace_sysroot_result.
func_replace_sysroot ()
{
- case $lt_sysroot:$1 in
+ case $lt_sysroot:$1 in
?*:$lt_sysroot*)
Likewise in the pattern expression; you could further change this to:
case $lt_sysroot:$1 in
?*:$lt_sysroot*)
Good call, although narrowing the search down to eliminate false positives
is a lot trickier in this case!
I'm adding the following changeset to this series. Thanks!
Actually, no, I take it back. I won't apply that patch since it causes tests
to fail for at least dash, bash and ksh.
My reading of the opengroup specification agrees with us both that no
resplitting
should be done in the branch expressions of a case, but there is definitely
something odd going on that I don't really understand:
$ cat case.test
for match in '\$\$' '\$'; do
case $match in *$match*) echo good ;; *) echo bad ;; esac
case $match in *$match*) echo good ;; *) echo bad ;; esac
done
solaris10 /bin/sh$ sh case.test
good
good
good
good
solaris10 xpg4$ /usr/xpg4/bin/sh case.test
good
good
good
good
hpux10 /bin/sh$ sh case.test
good
good
good
good
aix6 /bin/sh$ sh case.test
good
good
good
good
zsh-4.3.10$ zsh case.test
good
good
good
good
zsh-4.3.11$ /usr/local/Cellar/zsh-4.3.11/bin/zsh case.test
good
good
good
good
zsh-4.3.12$ /usr/local/bin/zsh case.test
good
good
good
good
dash-0.5.7$ dash case.test
bad
good
good
good
bash-3.2.48$ bash case.test
bad
good
good
good
bash-4.1.5$ /usr/local/Cellar/bash-4.1.5/bin/bash case.test
bad
good
good
good
bash-4.2.10$ /usr/local/bin/bash case.test
bad
good
good
good
ksh-93s+$ ksh case.test
bad
good
good
good
Confusing! It seems any backslash escaped character will do, same
results with '\S\S' and '\S' as with the dollars above. Yet, with
the backslashes removed, all the above print 4 'good's.
If it weren't for the fact that ksh, bash and dash all independently
behave the same way, I'd have called it a bug... any idea?
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 6/7] syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.
[adding bug-autoconf in CC] On Tuesday 22 November 2011, Gary V wrote: Hi Eric, On 22 Nov 2011, at 03:07, Eric Blake wrote: On 11/21/2011 07:47 AM, Gary V. Vaughan wrote: To safely use a non-literal first argument to `test', you must always prepend a literal non-`-' character, but often the second operand is a constant that doesn't begin with a `-' already, so always use `test a = $b' instead of noisy `test X$b = Xa'. Not true. test a = $b is just as likely to trigger improper evaluation in buggy test(1) implementations as: test $b = a :-o For real? On non-museum pieces? On Solaris 10 I see this: $ /bin/sh -c 'b=(; test $b = a'; echo status = $? /bin/sh: test: argument expected status = 1 $ /bin/sh -c 'b=!; test $b = a'; echo status = $? /bin/sh: test: argument expected status = 1 And on NetBSD 5.1 I see this: $ /bin/sh -c 'b=(; test $b = a'; echo status = $? test: closing paren expected status = 2 $ /bin/sh -c 'b=!; test $b = a'; echo status = $? test: a: unexpected operator status = 2 And in fact the autconf manual says: Similarly, Posix says that both `test string1 = string2' and `test string1 != string2' work for any pairs of strings, but in practice this is not true for troublesome strings that look like operators or parentheses, or that begin with `-'. (Text that should be probably be expandend to show some examples, *and* to report the exact names and versions of the affected shells). I tested a bunch of /bin/sh, bash, ksh and zsh versions that I have easy access to, and for all of them, the only way to upset test with leading hypens the first argument. I couldn't do this either (for leading hypens, that is); but see the slighlty more elaborated issues presented above. If you cannot guarantee the contents of $b, then you MUST prefix both sides of the comparison with x or X. Conversely, if you CAN guarantee the contents of $b (for example, if you did b=$?, then you KNOW that b is a numeric tring with no problematic characters), then you might as well use the more idiomatic comparison of variable to constant. I don't suppose you can point me at a shell that chokes or fails on: test a != -b || echo bug ? Or at least some reliable documentation that shows we're not dealing with outdated dogma here? I'll postpone pushing this patch until we get to the bottom of the issue though. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) Regards, Stefano
Re: [PATCH 3/7] tests: migrate tests/sh.test checks to syntax-checks.
On Tuesday 22 November 2011, Gary V wrote: Hi Stefano, On 22 Nov 2011, at 02:52, Stefano Lattarini wrote: Hi Gary. Just a quick nit (I haven't looked at the whole series, and not even at the whole patch in fact; sorry). No apologies necessary, every little helps! Thank you. On Monday 21 November 2011, Gary V wrote: for file do - test -f $file || touch $file + test -f $file || touch $file What's the point of quoting file after `test -f' it it remains unquoted after `touch'? Even though we know there is no whitespace in $file because of the for loop, there still might be other shell meta-characters in there. All uses of $file (including a bunch in the following lines) should be quoted correctly, OK, good. but that is another patch. That's perfectly fine, but IMHO it should me mentioned in the commit message. Regards, Stefano
Re: [PATCH 6/7] syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.
On 11/22/2011 02:02 AM, Stefano Lattarini wrote: test a = $b is just as likely to trigger improper evaluation in buggy test(1) implementations as: test $b = a :-o For real? On non-museum pieces? Okay, you've convinced me otherwise. It looks like even buggy versions of test(1) at least have the decency to recognize non-op = arbitrary as always being a string comparison, even if arbitrary looks like an operator (I tried !, =, (, ), -a, and so on). It is only when the first argument looks like an operator that the parser gets confused on what the remaining two arguments should be. And in fact the autconf manual says: Similarly, Posix says that both `test string1 = string2' and `test string1 != string2' work for any pairs of strings, but in practice this is not true for troublesome strings that look like operators or parentheses, or that begin with `-'. (Text that should be probably be expandend to show some examples, *and* to report the exact names and versions of the affected shells). Yes, the autoconf manual could be improved, based on the results of this thread. I tested a bunch of /bin/sh, bash, ksh and zsh versions that I have easy access to, and for all of them, the only way to upset test with leading hypens the first argument. I couldn't do this either (for leading hypens, that is); but see the slighlty more elaborated issues presented above. I can demonstrate a problem with leading hyphen, on Solaris 10 at least: $ touch =; /bin/sh -c 'test -f ='; echo $? /bin/sh: test: argument expected 1 I'll postpone pushing this patch until we get to the bottom of the issue though. I withdraw my objection to the libtool patch. It might not be a common idiom to list the constant first, but who knows? maybe you've started a new trend. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 8/7] syntax-check: fix violations and implement sc_useless_quotes_in_case_branch.
On 11/22/2011 01:21 AM, Gary V. Vaughan wrote: Likewise in the pattern expression; you could further change this to: case $lt_sysroot:$1 in ?*:$lt_sysroot*) Good call, although narrowing the search down to eliminate false positives is a lot trickier in this case! I'm adding the following changeset to this series. Thanks! Actually, no, I take it back. I won't apply that patch since it causes tests to fail for at least dash, bash and ksh. My reading of the opengroup specification agrees with us both that no resplitting should be done in the branch expressions of a case, but there is definitely something odd going on that I don't really understand: Confusing! It seems any backslash escaped character will do, same results with '\S\S' and '\S' as with the dollars above. Yet, with the backslashes removed, all the above print 4 'good's. If it weren't for the fact that ksh, bash and dash all independently behave the same way, I'd have called it a bug... any idea? Oh, I think I understand the issue: $ a=\* $ case b in $a) echo one;; *) echo two;; esac one $ case b in $a) echo one;; *) echo two;; esac two POSIX states: each pattern that labels a compound-list shall be subjected to tilde expansion, parameter expansion, command substitution, and arithmetic expansion, and the result of these expansions shall be compared against the expansion of word, according to the rules described in Section 2.13 (on page 2332) (which also describes the effect of quoting parts of the pattern). which in turn states: If any character (ordinary, shell special, or pattern special) is quoted, that pattern shall match the character itself. The shell special characters always require quoting. So, variable expansion is performed _prior_ to passing the pattern to fnmatch(), but quoting can occur either by \ or by . In the case where $a is unquoted, we are passing fnmatch the string *, but where $a was quoted, the shell is correctly treating * as a literal and passing fnmatch the string \\*. Bash, ksh, and dash are correct; mksh and Solaris 10 (among other shells) are buggy. And I stand corrected - variable expansion in case labels _must_ be quoted if you want to literally match all characters that occur in that variable expansion. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 6/7] syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.
On Tuesday 22 November 2011, Eric Blake wrote: touch =; test -f =; echo $? This is problematic also with pdksh 5.2.14 on Debian: $ pdksh -c 'touch ./=; test -f =; echo $?' pdksh: test: =: missing second argument 2 and with /bin/sh on OpenBSD 4.6 as well: $ /bin/sh -c 'touch ./=; test -f =; echo $?' /bin/sh: test: =: missing second argument 2 Regards, Stefano
Re: linking problems on SL6
On Mon, Nov 21, 2011 at 15:39, Peter O'Gorman pe...@pogma.com wrote: Glad it works around it. The problem is libtool brokenness, most vendors patch around it in their packaged libtool, e.g. http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD Is there any reason something like this isn't done in the source so vendors don't have to patch? Apart from it being a hack that is :-) Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool
