From owner-freebsd-bugs@FreeBSD.ORG Thu Jun 28 02:30:21 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 794AD106566C for ; Thu, 28 Jun 2012 02:30:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 642458FC1B for ; Thu, 28 Jun 2012 02:30:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5S2ULKR052312 for ; Thu, 28 Jun 2012 02:30:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5S2UL8p052309; Thu, 28 Jun 2012 02:30:21 GMT (envelope-from gnats) Date: Thu, 28 Jun 2012 02:30:21 GMT Message-Id: <201206280230.q5S2UL8p052309@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Mark Linimon Cc: Subject: Re: bin/169500: expr(1) improperly requires forward slash to be escaped X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 02:30:21 -0000 The following reply was made to PR bin/169500; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/169500: expr(1) improperly requires forward slash to be escaped Date: Wed, 27 Jun 2012 21:24:40 -0500 ----- Forwarded message from Robert Bonomi ----- Date: Wed, 27 Jun 2012 20:44:25 -0500 (CDT) From: Robert Bonomi To: linimon@freebsd.org Subject: Re: bin/169500: expr(1) improperly requires forward slash to be escaped FWIW, the putative 'bug' is documented on the manpage for expr. There is nothing wrong with the 1003 regex handling. It is operator/operaand recognition in expr. Using something that is parsable as an operator _as_ an operand. is a syntax error for the ':' operator -- EXPRESSLY so stated on the manpage. Using _any_ token that is parsable as an 'operator' (arithmetic, or logical) as an operand for ':' will result in the same non-bug error The 'Examples' section of the manpage documents a work-around -- actually using '/' as the example. Shoulc be closable -- with the traditional IBMism -- "it's not a bug, it's a _feature_, and =documented= as such." *BIG* grin. ----- End forwarded message -----