lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) (01/03/90)
Bash supports the csh style redirection of both error and stdout to a file: foo >& bar but not foo |& bar I'd like to see this added, but Brian says that he's unconvinced. I see no reason not to add it, although you can of course achieve the same thing if you can remember where to put all of the &'s. As an ex-csh user, I'd like the compatibilotyu and consistency. What do you think? Robert
chet@cwns1.CWRU.EDU (Chet Ramey) (01/03/90)
In article <5877@uhccux.uhcc.hawaii.edu> lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) writes: > foo |& bar >I'd like to see this added, but Brian says that he's unconvinced. I see no >reason not to add it, although you can of course achieve the same thing >if you can remember where to put all of the &'s. As an ex-csh user, I'd >like the compatibilotyu and consistency. What do you think? 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 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). Chet Ramey -- Chet Ramey Network Services Group "Help! Help! I'm being Case Western Reserve University repressed!" chet@ins.CWRU.Edu
roy@sts.sts.COM (01/03/90)
I think it doesn't hurt to support the csh-style "|&" syntax. It might even be better to think of it not as a csh compatibility feature, but as a short-hand for the bash equivalent "2>&1 |" (yech!) Roy Bixler roy@sts.COM
dce@smsc.sony.com (David Elliott) (01/04/90)
In article <5877@uhccux.uhcc.hawaii.edu> lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) writes: >Bash supports the csh style redirection of both error and stdout to a file: > foo >& bar >but not > foo |& bar > >I'd like to see this added, but Brian says that he's unconvinced. "Unconvinced"? Well, I guess I can make a couple of statements on this: 1. Both > and | are forms of redirection. In fact, "> filename" can be generalized to "| put_in_file filename". Since they do similar jobs, they should have similar syntax. 2. It's convenient to be able to change the line foo >& bar to foo |& baz with the line editor. It's not as convenient to have to change it to foo | baz 2>&1 3. If bash is going to emulate csh, it needs to emulate it in all areas. Doing just part of the job is not just inconvenient, it's confusing. Maybe Brian could give reasons for his objections? -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "But Pee Wee... I don't wanna be the baby!"
dce@smsc.sony.com (David Elliott) (01/04/90)
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!"
bfox@sbphy.ai.mit.edu (Brian Fox) (01/04/90)
Date: 3 Jan 90 18:28:05 GMT From: dce@smsc.sony.com (David Elliott) Organization: Sony Microsystems Corp. References: <5877@uhccux.uhcc.hawaii.edu> Sender: bug-bash-request@prep.ai.mit.edu In article <5877@uhccux.uhcc.hawaii.edu> lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) writes: >Bash supports the csh style redirection of both error and stdout to a file: > foo >& bar >but not > foo |& bar > >I'd like to see this added, but Brian says that he's unconvinced. This is heresay. Please quote me. "Unconvinced"? Why are you responding to heresay? 3. If bash is going to emulate csh, it needs to emulate it in all areas. Doing just part of the job is not just inconvenient, it's confusing. Why do some people infer that Bash is supposed to emulate Csh? The name of the shell stands for Bourne Again SHell, so I would hope that gives people an idea of what this shell must be compatible with. Bash is a POSIX shell. To the extent that I can support useful features of other shells, I will do so. Maybe Brian could give reasons for his objections? Maybe I could object first? Brian "Take this job and shove it" Fox
chet@cwns1.CWRU.EDU (Chet Ramey) (01/04/90)
> = David Elliott >> = Me >>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? First of all, what I want doesn't mean nearly as much as what Brian wants. I don't think >& should have been in there in the first place. It looks like something different to people used to sh syntax, like it should have a digit or a `-' at the end. &> is barely acceptable. I think Brian threw it in as an afterthought, but you'd have to ask him. >A lot of people are seeing bash as not only an alternative to ksh, but >a way to get back to one true shell. `One true shell' is desirable? I thought one of the great features of Unix was that you could replace any part you didn't like with your own code, including your shell. I'd like to see bash become the most widely-used shell around, but because it offers a superior alternative, not because it includes every feeping creature under the sun. >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. I think that AT&T's indecision regarding ksh (`put it in the Toolchest, charge big bucks, update it irregularly') and the fact that csh comes for free on the BSD tapes had much more to do with ksh not `taking over'. The fact that ksh will come standard in System V.4 could increase it's popularity greatly. (Of course, everything in the world will come on the System V.4 source tapes, and that is *not* an improvement.) BSD is quite popular (and rightly so), but csh is the only usable interactive shell in the distribution. Most BSD users have no other alternative. I think that if they had csh and ksh to choose from up front, there would be a lot more ksh users, regardless of whether or not the baroque csh history editing syntax existed. Just as a point of curiousity, what shell do you think Mike Karels uses? The editing (by this I mean line editing, which vanilla csh doesn't have) and history that ksh offers are superior alternatives to those offered by csh. I guess Korn didn't want to take what he saw as a step backwards (compared to the 4.1BSD csh with job control, since that's what Korn had when he began implementing ksh). Curly brace expansion is in bash and the latest version of ksh, `ksh88b' (but undocumented). I feel that the good features of csh, like curly braces, should be included in bash, but not everything. Even Brian has said that he's surprised by the amount of use the csh-style history is getting. >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." My understanding is that it is intended to be fully compatible with the POSIX shell spec, which itself is not fully compatible with existing shells (in fact, only ksh88b currently conforms to the full Posix shell specification). After that, features of ksh. Everything I saw from the FSF on bash before and after I became involved said the same thing: bash is an implementation of the POSIX shell spec, which is based on the Bourne and Korn shells. I even read something by rms in a GNUs bulletin that said bash could possibly appear as a replacement for `sh' in some subsequent Berkeley distribution, after ksh features were added. I've never seen csh mentioned. Chet Ramey -- Chet Ramey Network Services Group "Help! Help! I'm being Case Western Reserve University repressed!" chet@ins.CWRU.Edu
bfox@sbphy.ai.mit.edu (Brian Fox) (01/05/90)
Date: 3 Jan 90 22:36:22 GMT From: cwns1!chet@usenet.ins.cwru.edu (Chet Ramey) Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA) References: <5877@uhccux.uhcc.hawaii.edu>, <1990Jan3.001743.3636@usenet.ins.cwru.edu>, <1990Jan3.183419.2476@smsc.sony.com> Sender: bug-bash-request@prep.ai.mit.edu > = David Elliott >> = Me I don't think >& should have been in there in the first place. It looks like something different to people used to sh syntax, like it should have a digit or a `-' at the end. &> is barely acceptable. I think Brian threw it in as an afterthought, but you'd have to ask him. Actually, I made &> as a forethought, and then afterwards realized that I could hack >& so that it could work. Since >& doesn't preclude the standard usage, I added it to (mistakenly I now feel) appease the Csh users. Bash has a few features reverse engineered from Csh that I felt were generally useful. These include pushd and popd, ! history expansion and operators, and curly brace expansion. >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. If David Korn had made a free shell, starting from scratch, I think more people would be using and supporting it. Instead, he worked for AT&T, who are not famous for giving software away. The distribubility (<-- nice word, huh?) of Bash makes it the choice for me of shells that have job control. Brian
barratt@DASH.MITRE.ORG (Jeff Barratt) (01/05/90)
I don't really have an opinion about the csh vs. bash redirection---just want to say that it seems clear to me what you are trying to accomplish with bash, and, as a regular user, THANKS for the good work. ---------------------- barratt@dash.mitre.org I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered. - The Prisoner