From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15343 invoked from network); 6 Feb 2009 22:51:01 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 Feb 2009 22:51:01 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 31208 invoked from network); 6 Feb 2009 22:50:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Feb 2009 22:50:53 -0000 Received: (qmail 2859 invoked by alias); 6 Feb 2009 22:50:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26526 Received: (qmail 2850 invoked from network); 6 Feb 2009 22:50:47 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Feb 2009 22:50:47 -0000 Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by bifrost.dotsrc.org (Postfix) with ESMTP id 90B79802720F for ; Fri, 6 Feb 2009 23:50:42 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KEO00LA72488CB1@vms173003.mailsrvcs.net> for zsh-workers@sunsite.dk; Fri, 06 Feb 2009 16:50:37 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n16MoV6L010335 for ; Fri, 06 Feb 2009 14:50:32 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n16MoUHW010334 for zsh-workers@sunsite.dk; Fri, 06 Feb 2009 14:50:30 -0800 From: Bart Schaefer Message-id: <090206145030.ZM10333@torch.brasslantern.com> Date: Fri, 06 Feb 2009 14:50:29 -0800 X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: POSIX and the "&>" operator MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/8960/Fri Feb 6 13:42:32 2009 on bifrost X-Virus-Status: Clean The following is part of an exchange on the austin-group mailing list. The assertion is that "foo&>bar" has a well-defined semantics in POSIX sh and therefore the bash extension (which zsh adopted) to make "&>" a synonym for "2>&1 >" is in violation of POSIX compliance. (I tried to send a follow-up to the austin-group about it, but I can't figure out with what email address they think I'm subscribed, and the list won't accept mail from non-subscribers.) This is interesting for two reasons: (1) I suspect that when zsh is emulating a POSIX shell, it should avoid treating "&>" as a token and instead parse it as "&" ">" (2) I'm puzzled by Korn's assertion that some syntax like "&|" is an "invalid extension", as opposed for example to ">;" ---------- Forwarded message ---------- Date: Thu, 5 Feb 2009 12:19:52 -0500 From: Glenn Fowler To: austin-group-l@opengroup.org Subject: shell redirection question Resent-Date: 5 Feb 2009 17:20:33 -0000 Resent-From: austin-group-l@opengroup.org Resent-To: austin-group-l@opengroup.org in the posix shell grammar ';' and '&' are syntactically equivalent so these two commands, modulo one being in the background, should produce the same output ("stdout" to stdout, "stderr" to stderr): sh -c "( echo stdout; echo stderr >&2 ) ;>/dev/null; wait" sh -c "( echo stdout; echo stderr >&2 ) &>/dev/null; wait" ksh produces the same output for both cases i.e., it treats ';' and '&' as command separators bash, even with --posix, and zsh, treat the '&>/dev/null' as '>/dev/null 2>&1' is a shell implementation permitted to treat '&>/dev/null' as '>/dev/null 2>&1' ? -- Glenn Fowler -- AT&T Research, Florham Park NJ -- --- Forwarded mail from David Korn Date: Thu, 5 Feb 2009 16:52:21 -0500 From: David Korn To: austin-group-l@opengroup.org, chet.ramey@case.edu Subject: Re: Re: shell redirection question cc: chet.ramey@case.edu Subject: Re: Re: shell redirection question -------- > Chet Ramey writes: > > >> is a shell implementation permitted to treat > >> '&>/dev/null' as '>/dev/null 2>&1' ? > > > > This is a documented bash extension. It's not posix. As such, it's > > probably not appropriate for the group to decide. > > Certainly it's not appropriate for the group to decide what extensions > Bash should make, but here it seems clear that Bash and zsh do not > conform to the current POSIX spec here. Either the POSIX spec should > change, or bash (with --posix) should change. I prefer the former, > that is, I suggest modifying POSIX so that "&>" leads to > implementation-defined behavior. > > Of course the group cann't say what extensions any shell should make, but they can indicate whether an extension is compatible with posix. When you run ksh93 with the -n option, it produces a warning whenever it finds &< without a space in between. The only time I have ever seen this warning is when a script intended for bash was run so I would say that &< in any other context is exceedingly rare. Excluding the ( and ) operators, I have a list below of all the other two character operator characters and how they are used. The wording in the standard under token recognition, says, "If the previous character was uses as part of an operator and the current character is not quoted and can be used with the current characters to form an operator, it should be used as part of that (operator) token." The grammar section also list which operators are defined double character operators. However, the standard doesn't state how extensions should be made. ksh93 has used the rule that if the second character would generate a syntax error, then it is a valid extension. Maybe, ;<, ;>, &< and &> should produce unspecified behavior without an interviening space so that these can be used as an extension. Minimally &> is commonly used in bash so this might be considered a legal extension. << used by posix <> used by posix <; valid extension <| valid extension <& used by posix >< valid extension >> used by posix >; valid extension used by ksh93 >| used by posix >& used by posix ;< invalid extension ;> invalid extension ;; used by posix ;| valid extension ;& valid extension used by ksh93 |< invalid extension |> invalid extension |; valid extension || used by posix |& valid extension used by ksh93 &< invalid extension &> invalid extension used by bash &; valid extension &| invalid extension && used by posix ksh93 also uses <# and ># which are valid extensions. David Korn dgk@research.att.com ---End of forwarded mail from David Korn --