Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!dce
From: dce@smsc.sony.com (David Elliott)
Newsgroups: gnu.bash.bug
Subject: Re: piping error output in Bash 1.04
Keywords: bash
Message-ID: <1990Jan3.183419.2476@smsc.sony.com>
Date: 3 Jan 90 18:34:19 GMT
References: <5877@uhccux.uhcc.hawaii.edu> <1990Jan3.001743.3636@usenet.ins.cwru.edu>
Reply-To: dce@Sony.COM (David Elliott)
Organization: Sony Microsystems Corp.
Lines: 34

In article <1990Jan3.001743.3636@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes:
>In article <5877@uhccux.uhcc.hawaii.edu> lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) writes:
>
>It's so easy to do it with the regular bash features that I don't think the
>extra code is warranted:
>
>foo 2>&1 | bar

Well, you can do "foo >& bar" with "foo > bar 2>&1".

>I think csh compatibility should not be a goal.  Bash is not csh; it's not
>even a csh clone.  I think ksh compatibility should be a goal (the useful
>features of ksh, that is).

If that's your reasoning, then get rid of >&.  A half-done job confuses
users trying to switch over.  Is this confusion your goal?

A lot of people are seeing bash as not only an alternative to ksh, but
a way to get back to one true shell.  If David Korn had added csh-style
history and editing syntax and curly braces to ksh, ksh would have
taken over.  Instead, ksh was kept "pure", and potential users stayed
away.

It seems to me that the introduction to bash ought to state what the
goals are, and right now what I'm hearing is "bash is designed to be
a better interactive shell, and it incorporates all of the features
that the authors like.  It is not intended to be fully compatible with
existing shells."

-- 
David Elliott
dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"But Pee Wee... I don't wanna be the baby!"