From owner-freebsd-bugs@freebsd.org Mon Sep 19 05:56:06 2016 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CB78BDFE34 for ; Mon, 19 Sep 2016 05:56:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72AF5A16 for ; Mon, 19 Sep 2016 05:56:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u8J5u6q7014077 for ; Mon, 19 Sep 2016 05:56:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 206295] sh(1)/test(1) bug (precedence) Date: Mon, 19 Sep 2016 05:56:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: nibbana@gmx.us X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 05:56:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206295 --- Comment #3 from nibbana@gmx.us --- I apologize for this somewhat incorrect statement (see below): "this bizzare behavior only applies to the -a operator, not -o" -- the -a or -o indeed binds more strongly than the !. This is because -a and -o are explicitly said to be "binary primaries" and therefore '' -a ' ' matches the first case of 3 arguments and ! '' -a '' matches the first case of 4 arguments. In bash, dash, zsh and yash, [ ! "" -a "" ] likewise returns true. I recommend writing [ ! "" ] && [ "" ] or [ -z "" ] && [ -n "" ] instead. -- Thanks for that reply: the fact that other shells do this is important, and probably everything is working as it should, but the manpage doesn't explain any of the logic. The other justification is vague: This is because -a and -o are explicitly said to be "binary primaries" and therefore '' -a ' ' matches the first case of 3 arguments and ! '' -a '' matches the first case of 4 arguments. 'binary' only signifies that they are operators that require two expressions and doesn't signify precedence over 'unary' operators/primaries. Whatever the case, it's a mess: $ [ ! "" -a "" -o ! "" -a "" ] && echo pass || echo fail fail Accordingly, since the manpage explicitly states that -a has higher precedence than -o, we should have "pass -o pass" above, but we get "fail" instead. At the very least, the manpage should state the logic behind this ... is it: (pass -o pass) -a fail =3D fail? pass -o (pass -a fail) =3D fail? -- $ [ ! "" -a "" -o 11 -a "" ] && echo pass || echo fail fail pass -o (pass -a fail) =3D ..... no, this is not correct. (pass -o pass) -a fail =3D fail? -o has higher precedence than the 2nd -a ... which violates the specified manpage rule. $ [ ! "" -a "" -o "" -o "" ] && echo pass || echo fail fail pass -o (fail -o fail) =3D ..... no, this is not correct. (pass -o fail) -o fail =3D ..... no, this is not correct. wtf??? $ [ ! "" -a "" -o "" -a 11 ] && echo pass || echo fail fail pass -o (fail -a pass) =3D ..... no, this is not correct. (pass -o fail) -a pass =3D ..... no, this is not correct. wtf??? Is there any good reason for this matter to be such a mess other than "family tradition?" Did it make code more efficient in 1975? It appears to be intentionally broken without any rational basis whatsoever. --=20 You are receiving this mail because: You are the assignee for the bug.=