lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/06/90)
In <2533@zipeecs.umich.edu>, gilgalad@zip.eecs.umich.edu (Ralph Seguin) writes: >Anybody got any idea when C= is going to get around to writing true pipes >(ala UNIX)? I suppose that I'm probably going to get flamed all over >the place for this one 8-) > > Thanks, Ralph No flames from me. I am all for Unix-like pipes, and use PIP:, as supplied with ConMan. CBM's PIPE: device is just to restrictive for me. I don't know when they are going to do them, but until then, I heartily recommend PIP: -larry -- The raytracer of justice recurses slowly, but it renders exceedingly fine. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
gilgalad@zip.eecs.umich.edu (Ralph Seguin) (06/06/90)
Anybody got any idea when C= is going to get around to writing true pipes (ala UNIX)? I suppose that I'm probably going to get flamed all over the place for this one 8-) Thanks, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/06/90)
In article <2533@zipeecs.umich.edu> (Ralph Seguin) writes: >Anybody got any idea when C= is going to get around to writing true pipes >(ala UNIX)? I suppose that I'm probably going to get flamed all over >the place for this one 8-) You wouldn't happen to be confusing pipes with the bit of syntactic sugar (the vertical bar) that the UNIX shells offer would you? If you can define "true pipe" it would help to answer the question, if you want the syntax I would suggest WShell, a commercial shell from Bill Hawes which offers this. I don't believe this is available in the 2.0 Amiga Shell (yet?, it's only beta). Anyway, looking forward to the definition you give... -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/06/90)
In article <136735@sun.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >In article <2533@zipeecs.umich.edu> (Ralph Seguin) writes: >>Anybody got any idea when C= is going to get around to writing true pipes >>(ala UNIX)? I suppose that I'm probably going to get flamed all over >>the place for this one 8-) > >You wouldn't happen to be confusing pipes with the bit of syntactic >sugar (the vertical bar) that the UNIX shells offer would you? If >you can define "true pipe" it would help to answer the question, >if you want the syntax I would suggest WShell, a commercial shell from >Bill Hawes which offers this. I don't believe this is available in the >2.0 Amiga Shell (yet?, it's only beta). Anyway, looking forward to >the definition you give... > Bzzzzt! Wrong answer Chuck. From a user's viewpoint (You do remember users? They pay the bills.), the difference is far more than syntactic sugar. The difference is information overload and confusion. Under Unix, the user strings together a set of filters by a convenient and reasonably transparent mechanism, the one line set of piped commands. This hides from him/her the nastiness needed on the Amiga: 1) S/he has to remember to explicitly spawn a separate light weight process for all but the last command, via the "run" command, _or_ stop whatever is going on long enough to open separate cli windows in which to execute each separate command of the piped commands. Fail to do one or the other, and s/he is busy exploring the bugs in the responses of C:'s inhabitants to the BREAK command. 2) S/he has to create a distinct and explicit pipe: directory entry for each and every intermediate file. Mistype pipe:b as pipe:a and things are frozen up again; back to exploring BREAK. The Unix user is protected from all this by the _information_hiding_mechanism_, not "syntactic sugar", of the "|" implementation of pipes. In addition, "|" affords the Unix user the chance to push the whole set of commands in the background with two keystrokes, " &" at the end of the line, to recall the entire set of commands and repeat it as a single entity with "!!", and, if in one of the nicer shells that allows command line editing, to recall and edit as a single entity the entire set of commands comprising the piped set. Looking at the Amiga implementation, like looking at the choice of "#?" for the wildcard (that I for one use on over half my typed lines), rather than the single keystroke "*", brings to mind the same question: "Why did the Amiga developers go to the time, trouble, and expense to design and implement something poorly, when an example of how to do it much better was conveniently at hand?" If "not invented here" is that strong a paradigm of software development, perhaps it is high time for a paradigm shift. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
lupe@alanya.Central.Sun.COM (Lupe Christoph - Sun Germany Consulting - Munich) (06/06/90)
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >In article <2533@zipeecs.umich.edu> (Ralph Seguin) writes: >>Anybody got any idea when C= is going to get around to writing true pipes >>(ala UNIX)? I suppose that I'm probably going to get flamed all over >>the place for this one 8-) >You wouldn't happen to be confusing pipes with the bit of syntactic >sugar (the vertical bar) that the UNIX shells offer would you? If >you can define "true pipe" it would help to answer the question, >if you want the syntax I would suggest WShell, a commercial shell from >Bill Hawes which offers this. I don't believe this is available in the >2.0 Amiga Shell (yet?, it's only beta). Anyway, looking forward to >the definition you give... Chuck, I believe Ralph is referring to the need to specify an name with the standard 1.3 pipes. This is more like SYS V named pipes than the ones created by pipe(). Nameless pipes are provided by ConMan, which I would recommend to anybody anyway. BTW, anybody written a pipe() for Lattice C yet ? Or a dup()/dup2() ? The latter two can probably not be implemented the way Lattice open()/close() work. You need a reference counter for the file handle. -- | lchristoph@Sun.COM (Internet) | Disclaimer: | | ...!unido!sunmuc!lupe (German EUNet, "bang") | My employer has a | | lupe@sunmuc.UUCP (German EUNet, domain) | non-exclusive license | | ...!suninfo!lchristoph (Sun Germany customers) | to my opinion. |
gilgalad@dip.eecs.umich.edu (Ralph Seguin) (06/06/90)
I suppose that I should have been more clear on my cry for pipes. What I mean is that UNIX has a kernel call to create a pipe between two processes. This is considerably easier than handling stuff through PIPE: Thanks, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
jesup@cbmvax.commodore.com (Randell Jesup) (06/07/90)
In article <1990Jun6.104643.15176@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Looking at the Amiga implementation, like looking at the choice of "#?" for >the wildcard (that I for one use on over half my typed lines), rather than >the single keystroke "*", brings to mind the same question: "Why did the >Amiga developers go to the time, trouble, and expense to design and >implement something poorly, when an example of how to do it much better was >conveniently at hand?" The #? comes from Tripos, back from the early '80's in England. It's historical, not "not invented here". 2.0 has far more capable wildcards, with classes, ~(not), etc. Even * if you set a flag in the system, though not by default so we don't break existing scripts and apps. As for pipes, there are any number of third party shells that have the '|' syntax, just as in Unix there are any number of alternate shells that have better editing than csh or sh. Once again, turning '|' into a piping character would break existing scripts and applications. 2.0 also has improved support for "user shells", so programs can submit things generated by the user to his/her preferred interactive shell, while continuing to send program-generated command lines through the normal shell (so things like syntax differences won't break them). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
kim@uts.amdahl.com (Kim DeVaughn) (06/07/90)
In article <1990Jun6.104643.15176@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > In article <136735@sun.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: > >In article <2533@zipeecs.umich.edu> (Ralph Seguin) writes: > >>Anybody got any idea when C= is going to get around to writing true pipes > > > >You wouldn't happen to be confusing pipes with the bit of syntactic > >sugar (the vertical bar) that the UNIX shells offer would you? If > > Bzzzzt! Wrong answer Chuck. > > From a user's viewpoint (You do remember users? They pay the bills.), the > difference is far more than syntactic sugar. The difference is information > overload and confusion. [ much deleted, all of which I agree with 100% ... good summation, Kent! ] > Looking at the Amiga implementation, like looking at the choice of "#?" for > the wildcard (that I for one use on over half my typed lines), rather than > the single keystroke "*", brings to mind the same question: "Why did the > Amiga developers go to the time, trouble, and expense to design and > implement something poorly, when an example of how to do it much better was > conveniently at hand?" > > If "not invented here" is that strong a paradigm of software development, > perhaps it is high time for a paradigm shift. No, it wasn't that at all. In fact, originally CAOS was to have had a very csh-like shell. There ended up being some, um, shall we say "differences of opinion" on compensation and such between C-A, and the two (?) individuals that were to provide what is technically called AmigaDOS (as opposed to the complete AmigaOS), i.e., the CLI/shell, filesystem, and such. Basically, they picked up their cookies and left. Being in somewhat of a bind, C-A cast about for a replacement they could get in short order. Unfortunately (IMO), they found Dr. Tim King and his infamous TriPOS (nee TripeOS, :-) ). Which is why we have "#?", BCPL, and all the pain and agony that decision has cost over the years (not to mention all the effort that has been spent getting around the problems thus created by writing alternative shells, commands, etc). On the other hand, if it had not been for Tim/Metacomco/TriPOS, the Amiga might never have made it to the marketplace ... Of course that set the stage and defined the "official" interface, which we still have to live with, even though 2.0 has supposedly exorcised all the BCPL out of the system. Fortunately, there are decent alternative shells, such as SKsh, Wshell, and the Dillon/et-al shell. As to what ever happened to CAOS ... I've heard tell that it is still locked away in some deep, dark vault in West Chester (or possibly Los Gatos ?). I believe there was a lawsuit pending between the "interested parties", but never did hear of any resolution of it. Anyone who knows willing to talk? One related question I've asked several times, but still have not seen an answer to ... under 2.0, can command lines longer than ~255 chars be passed to Exec() ... or must file handling programs still be "builtin" to a shell, or do their own wildcard expansion if not, in order to handle directories with moderately a large number of files in it? Could someone at CBM who knows, please comment? Andy? Randell? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
d88-mbe@sm.luth.se (Michael Bergman) (06/07/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >From a user's viewpoint (You do remember users? They pay the bills.), the >difference is far more than syntactic sugar. The difference is information >overload and confusion. >Under Unix, the user strings together a set of filters by a convenient and >reasonably transparent mechanism, the one line set of piped commands. I fully agree here. I also wish the piping mechanism in the standard Amiga SHELL would be similar to UNIX' "|". >Looking at the Amiga implementation, like looking at the choice of "#?" for >the wildcard (that I for one use on over half my typed lines), rather than >the single keystroke "*", brings to mind the same question: "Why did the Actually the #? has it's advantages. Not very many standard AmigaDOS commands can handle the wildcards, but with those who can, the Amiga wildcards are more powerful than UNIX'. You can match patterns with #?| and the others (can't remember them all) that is impossible in UNIX. Sorry I can't come up with an example, but I know it is the case because this has been discussed here before. Mike -- Michael Bergman Internet: d88-mbe@sm.luth.se // Undergrad. Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se \X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe
daveh@cbmvax.commodore.com (Dave Haynie) (06/08/90)
In article <1990Jun6.104643.15176@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >In addition, "|" affords the Unix user the chance to push the whole set of >commands in the background with two keystrokes, " &" at the end of the line, The "|" character certainly does make things easier. In any case, Chuck's bottom line is correct, get WShell. WShell interprets " | " as a pipe, knows about "&" at the end of the line, and does a bunch of other things extremely well. The only shell I use when I can help it. >to recall the entire set of commands and repeat it as a single entity with >"!!", and, if in one of the nicer shells that allows command line editing, >to recall and edit as a single entity the entire set of commands comprising >the piped set. Well, even AmigaShell has better line editing than most UNIX shells. >Looking at the Amiga implementation, like looking at the choice of "#?" for >the wildcard (that I for one use on over half my typed lines), rather than >the single keystroke "*", brings to mind the same question: "Why did the >Amiga developers go to the time, trouble, and expense to design and >implement something poorly, when an example of how to do it much better was >conveniently at hand?" As pointed out many times here before, the Amiga regular expression language is far more powerful than the other models available at the time. Now you're really the one talking syntactic sugar. Sure, "*" could be substituted for "#?", but what do you substitute for FILE#(A|B|C#E??).(C|O), or a similar AmigaDOS pattern? The only thing that comes close is the grep language, which isn't used for file naming, but that has the disadvantage of using a number of common file characters, such as ".", as part of its regular expression language. I would be annoyed if I had to type "more thing\.c" or some-such; the file-patten language shouldn't often intrude on your normal work. Different isn't always better, different just to be different rarely is, but different with a valid reason behind it usually is. I'm still surprised by how much NUH (Not Used Here) is to be found in the minds of normally intelligent people (in general, I'm not trying to flame Kent here for this relatively minor transgression...). >Kent, the man from xanth. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM
jesup@cbmvax.commodore.com (Randell Jesup) (06/08/90)
In article <5aBo02FSad0201@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes: >One related question I've asked several times, but still have not seen an >answer to ... under 2.0, can command lines longer than ~255 chars be passed >to Exec() ... or must file handling programs still be "builtin" to a shell, or >do their own wildcard expansion if not, in order to handle directories with >moderately a large number of files in it? Could someone at CBM who knows, >please comment? Andy? Randell? Command lines should be able to be longer as used by System and Execute. This hasn't been extensively tested as of yet, but it was a factor in design. Path lengths are still constrained by the 255 character limit to BSTRs, due to the packet formats. At some later date I have plans to eliminate that as well (no time for 2.0). The console may be able to handle longer than 255 character lines now, I'm not sure (but I suspect it still has some hard limit). Wildcard expansion is much easier to do now, due to matchfirst/ matchnext. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (06/08/90)
In article <12373@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >2.0 has far more capable wildcards, with classes, ~(not), etc. Even * if >you set a flag in the system, though not by default so we don't break >existing scripts and apps. Oohh... please tell us more! Could you please post a complete summary of the 2.0 wildcarding? Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
nsw@cbnewsm.att.com (Neil Weinstock) (06/08/90)
In article <12391@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: [ ... ] >Well, even AmigaShell has better line editing than most UNIX shells. For those using System V, there's ksh, which supports vi and emacs line editing. In an ideal world, one's shell should used the same type of line editing as one's editor. I use vi (go ahead, flame me ;-). I use vi editing mode in ksh. "Most" UNIX shells might be lacking in line editing, but everyone I know uses ksh, so from where I stand the point is moot. I still await an Amiga shell that offers vi editing mode. Anyone know of one? - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
peter@sugar.hackercorp.com (Peter da Silva) (06/08/90)
In article <1990Jun7.215928.3826@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: > In an ideal world, one's shell should used the same type of line > editing as one's editor. In an ideal world, the terminal driver would provide the line editing. Line editing in the shell makes as much sense as using SIMPLEREFRESH windows for everything. Ksh and X... two peas in a pod. Luckily the Amiga is a little more modern. > I still await an Amiga shell that offers vi editing mode. Anyone know of one? So, what you really need is a console.device replacement that offers VI mode. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ My other car is a hot-air balloon. v "Have you hugged your wolf today?" `-_-'
nsw@cbnewsm.att.com (Neil Weinstock) (06/09/90)
In article <5795@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Jun7.215928.3826@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: >> In an ideal world, one's shell should used the same type of line >> editing as one's editor. > >In an ideal world, the terminal driver would provide the line editing. Line >editing in the shell makes as much sense as using SIMPLEREFRESH windows for >everything. Ksh and X... two peas in a pod. Luckily the Amiga is a little more >modern. Well, hey, I like to post something stupid once in a while, just to keep myself honest. Allow me to rephrase: In an ideal world, the terminal driver would provide the same type of line editing as one's favorite editor. If I were feeling ambitious, I would generalize that statement to include string gadgets, and just about everything else. >So, what you really need is a console.device replacement that offers VI mode. Yes, that would do nicely. Know of one? Me neither (I use ConMan). BTW, one problem with this approach is that the terminal driver doesn't know the difference between a shell command and any other random keyboard input. This screws up the history mechanism somewhat, since one would usually prefer the shell history to include only shell commands. Is there an obvious fix for this? After about 30 seconds of thought, all I can come up with is to allow the shell (or any application) to control which history buffer is used by the terminal driver (using escape codes, or something like that). And now for YAHBI (Yet Another Half-Baked Idea): a linedit.library, to be used, at the minimum, by the console.device. Comments? - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
wfh58@leah.Albany.Edu (William F. Hammond) (06/10/90)
In article <12373@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: . . . > The #? comes from Tripos, back from the early '80's in England. >It's historical, not "not invented here". 2.0 has far more capable wildcards, >with classes, ~(not), etc. Even * if you set a flag in the system, though not >by default so we don't break existing scripts and apps. I'm very glad to hear that "*" as a wild card is a configuration option under OS 2. I hope this also means that an alternate escape character will also be a configuration option. > As for pipes, there are any number of third party shells that have >the '|' syntax, just as in Unix there are any number of alternate shells that >have better editing than csh or sh. Once again, turning '|' into a piping >character would break existing scripts and applications. I have both WShell (commercial) and the ARP 1.3 Shell (freeware). I hope everyone knows that there is a freeware product which supports the concurrent piping (with the "|" symbol) that is part of the "ConMan" console handler. (In fact, I tend to prefer the ARP shell because it has command line substitution. Against WShell, it has the distinct disadvantage of not opening an ARexx port.) I have never had trouble in the ARP shell with the two meanings of "|" (i.e., as (1) pipe and (2) first string OR second string) probably because the "OR" syntax always occurs inside parentheses while the pipe syntax does not. Maybe this is just the idiosyncrasy of my usage. > 2.0 also has improved support for "user shells", so programs can >submit things generated by the user to his/her preferred interactive shell, >while continuing to send program-generated command lines through the >normal shell (so things like syntax differences won't break them). This also sounds very good. By the way, although "pip:"-style concurrent piping is extremely useful (I daily use pipes of length 4), there are times when "pipe:"-style rendezvous pipes are what I want. After all, there is only one stdout stream and sometimes I want several outgoing streams. So PLEASE PLEASE do not throw out "PIPE:". We want both kinds of piping available. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup >Common phrase heard at Amiga Devcon '89: "It's in there!" ---------------------------------------------------------------------- William F. Hammond Dept. of Mathematics & Statistics 518-442-4625 SUNYA, Albany, NY 12222 wfh58@leah.albany.edu wfh58@albnyvms.bitnet ----------------------------------------------------------------------
wfh58@leah.Albany.Edu (William F. Hammond) (06/10/90)
In article <12391@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: > . . . >The "|" character certainly does make things easier. In any case, Chuck's >bottom line is correct, get WShell. WShell interprets " | " as a pipe, >knows about "&" at the end of the line, and does a bunch of other things >extremely well. The only shell I use when I can help it. > . . . >As pointed out many times here before, the Amiga regular expression language >is far more powerful than the other models available at the time. Now you're >really the one talking syntactic sugar. Sure, "*" could be substituted for >"#?", but what do you substitute for FILE#(A|B|C#E??).(C|O), or a similar >AmigaDOS pattern? The only thing that comes close is the grep language, > . . . The "*" has peacefully co-existed with all of the standard Amiga pattern matching characters in the ARP world for quite a time now. Yes, the standard Amiga pattern matching language is more powerful. But 90+% of my pattern matching is the '*' kind, and 99.999% of my CPU time is wasted by my clumsy typing at the keyboard. So anything that helps to recover that wasted CPU time is worthwhile. Likewise with piping. I can only handle one outgoing stream with the '|' symbol (invoking ConMan's "PIP:"), whereas I can handle multiple streams with "PIPE:". But wiring a single piped stream with "PIPE:" takes lots of typing -- lots more than simply typing '|'. And 90+% of my piping is single-stream. >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "I have been given the freedom to do as I see fit" -REM
peter@sugar.hackercorp.com (Peter da Silva) (06/10/90)
In article <1990Jun9.062243.24641@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: > If I were feeling ambitious, I would generalize that statement to include > string gadgets, and just about everything else. ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Damn good point. Yes. > one would usually prefer > the shell history to include only shell commands. Not always. But usually, yes. > Is there an obvious fix > for this? After about 30 seconds of thought, all I can come up with is to > allow the shell (or any application) to control which history buffer > is used by the terminal driver (using escape codes, or something like that). Sounds good. You could even put this sequence in your prompt, & alias your long running commands to "echo esc; command" to turn off history. I'd also like escape sequences to change window borders, create menu entries, change the window title, etcetera. > And now for YAHBI (Yet Another Half-Baked Idea): a linedit.library, to be > used, at the minimum, by the console.device. Comments? I like it. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ My other car is a hot-air balloon. v "Have you hugged your wolf today?" `-_-'
kim@uts.amdahl.com (Kim DeVaughn) (06/10/90)
In article <1990Jun7.215928.3826@cbnewsm.att.com>, nsw@cbnewsm.att.com (Neil Weinstock) writes: > > I still await an Amiga shell that offers vi editing mode. Anyone know of one? Will you settle for "RSN" ...? Steve Koren's SKsh shell will support vi-style editing in version 1.5. The release of 1.5 may be delayed however, due to a Lattice (v5.05) bug, where it generates F-line instructions in random places, for no apparent reason. He reported this to Lattice some time ago, but as yet, has received no word about a fix, etc. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
jesup@cbmvax.commodore.com (Randell Jesup) (06/10/90)
In article <1990Jun9.062243.24641@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: > In an ideal world, the terminal driver would provide the same type of > line editing as one's favorite editor. > >If I were feeling ambitious, I would generalize that statement to include >string gadgets, and just about everything else. Well, we're getting closer, what with string gadget editing hooks. >BTW, one problem with this approach is that the terminal driver doesn't know >the difference between a shell command and any other random keyboard input. >This screws up the history mechanism somewhat, since one would usually prefer >the shell history to include only shell commands. Is there an obvious fix >for this? After about 30 seconds of thought, all I can come up with is to >allow the shell (or any application) to control which history buffer >is used by the terminal driver (using escape codes, or something like that). History and related items (such as filename expansion) are the tough parts of doing console handlers, if you want to go that route. >And now for YAHBI (Yet Another Half-Baked Idea): a linedit.library, to be >used, at the minimum, by the console.device. Comments? console.device has nothing to do with editing, you want console-handler. :-) Not for 2.0. If we do it, it would be best to integrate it with the default Intuition string editing hook somehow. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
daveh@cbmvax.commodore.com (Dave Haynie) (06/11/90)
In article <3149@leah.Albany.Edu> wfh58@leah.albany.edu.UUCP (William F. Hammond) writes: >I have never had trouble in the ARP shell with the two meanings of "|" >(i.e., as (1) pipe and (2) first string OR second string) probably because >the "OR" syntax always occurs inside parentheses while the pipe syntax does >not. Maybe this is just the idiosyncrasy of my usage. As I recall, ARP only handles the alternation charcter inside of parentheses, but real Amiga commands support it outside them as well. There is still no ambiguity, though, if you define the syntax for "|" as a pipe rather than a file alternation character, in most cases. Normally, a pattern with alternation uses "|" without whitespace: dir this|that While a pipe would look like: dir | this | that both of those would work just dandy, as intended, in WShell. In the case where you really did have whitespace to consider next to the alternation character, the whole pattern would have to be in double quotes, just as any filename with whitespace when used from a shell. >William F. Hammond Dept. of Mathematics & Statistics -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM
umsmigie@ccu.umanitoba.ca (Jason Smigiel) (06/12/90)
In article <1990Jun6.104643.15176@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Looking at the Amiga implementation, like looking at the choice of "#?" for >the wildcard (that I for one use on over half my typed lines), rather than >the single keystroke "*", brings to mind the same question: "Why did the >Amiga developers go to the time, trouble, and expense to design and >implement something poorly, when an example of how to do it much better was >conveniently at hand?" I much prefer the Amiga's pattern matching abilities over the traditional * route, But what I think is sorely missed in the Amiga Shell is file completion. I think the most valuable thing about the shells I use on Unix is File Completion! That feature saves an incredible amount of typing, and extraneous ls'ing. >Kent, the man from xanth. Jason
mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) (06/13/90)
In article <1990Jun9.062243.24641@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes:
BTW, one problem with this approach is that the terminal driver doesn't know
the difference between a shell command and any other random keyboard input.
This screws up the history mechanism somewhat, since one would usually prefer
the shell history to include only shell commands.
One might, but I wouldn't. Of course, I don't want a "shell history";
I want an "input history". That way, I get access to the everything I
typed, and not just that which is saved by a some specific subsystem.
It also means I get a consistent history mechanism for all CLI-based
programs.
Of course, I also want to be able to select input from all text output
into the CLI, but that's a different problem.
<mike
--
I'm gonna lasso you with my rubberband lazer, Mike Meyer
Pull you closer to me, and look right to the moon. mwm@relay.pa.dec.com
Ride side by side when worlds collide, decwrl!mwm
And slip into the Martian tide.desmarai@IRO.UMontreal.CA (Stephane Desmarais) (06/13/90)
In article <MWM.90Jun12140219@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) writes: > >Of course, I also want to be able to select input from all text output >into the CLI, but that's a different problem. > This is what I liked the most on the C-64. Display a directory listing, and edit the line to load the program (and of course I only had to type a '/' in front of the line). This is just a simple example, but sometime it was really more sophisticated than that. On the Amiga, I use Snap. Unfortunately, the 64 had no input history (hey, maybe I could write one? I'll add it to my long list of projects :-). -- Stephane M. Desmarais desmarais@iro.umontreal.ca (le Domaine Canadien) Departement d'informatique uunet!mcgill-vision!iros1!desmarais Universite de Montreal C.P. 6128 Succ. A Montreal Quebec Canada H3C 3J7 Projet IBM/CRIM/UdeM sur MAP/MMS (514) 343-7660
dailey@frith.uucp (Chris Dailey) (06/14/90)
In article <1990Jun7.215928.3826@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: > In an ideal world, one's shell should used the same type of line > editing as one's editor. Wouldn't it be nice if there were a number of editing 'tools' that were available as libraries. Then an editor could be written with a link to that library (or any of a number of libraries) and your favorite shell could be used with a link to the same library. (I'm calling it a library for want of a better word.) Feaseable or not? Maybe the shell or word processor could define a number of other keystrokes that would be processed by itself should a command be needed that goes beyond the line limitation...? Maybe the user's preference could be set in an environment variable that the word processor and the shell take their cues from...? Just thinkin' out loud. -- /~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary) C oo dailey@(cpsin1.cps|frith.egr).msu.edu (make WP5.1 for the Amiga) _( ^) "I am thankful for one leg. To limp is no disgrace -- / ~\ I may not be number one, but I can still run the race." -from B.C.
gilgalad@caen.engin.umich.edu (Ralph Seguin) (10/19/90)
Does anybody know whether or not Amiga OS 2.0 will support "true pipes", ie pipes ala UNIX? I am considering writing a true pipe handler, but I don't want to waste my time if C= is going to do it for me 8-). Thanks, Ralph gilgalad@dip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph Seguin | "You mean THE Zaphod Beeblebrox?" 536 South Forest | Apartment 915 | "No. Haven't you heard, I come in six packs!" Ann Arbor, MI 48104 | (313) 662-4805
dewolfe@ug.cs.dal.ca (Colin DeWolfe) (10/19/90)
In article <1990Oct19.044319.4851@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >Does anybody know whether or not Amiga OS 2.0 will support "true pipes", >ie pipes ala UNIX? I am considering writing a true pipe handler, but >I don't want to waste my time if C= is going to do it for me 8-). > > Thanks, Ralph Not yet, at least in my release KS 36.143 WB36.68 (2.01) there isn't anything. I want true pipes so I think you should go for it. :-) > > >gilgalad@dip.eecs.umich.edu gilgalad@caen.engin.umich.edu > >Ralph Seguin | "You mean THE Zaphod Beeblebrox?" >536 South Forest | >Apartment 915 | "No. Haven't you heard, I come in six packs!" >Ann Arbor, MI 48104 | >(313) 662-4805 Colin DeWolfe dewolfe@ug.cs.dal.ca dewolfe@iris1.ucis.dal.ca
waggoner@dtg.nsc.com (Mark Waggoner) (10/20/90)
In article <1990Oct19.153416.12047@cs.dal.ca> dewolfe@ug.cs.dal.ca (Colin DeWolfe) writes: >In article <1990Oct19.044319.4851@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >>Does anybody know whether or not Amiga OS 2.0 will support "true pipes", >>ie pipes ala UNIX? I am considering writing a true pipe handler, but >>I don't want to waste my time if C= is going to do it for me 8-). > >Not yet, at least in my release KS 36.143 WB36.68 (2.01) there isn't >anything. > >I want true pipes so I think you should go for it. :-) I don't know if this is quite what you want, but ConMan, the console handler by William Hawes can be mounted as a pipe handler and may provide what you are looking for. How exactly would you expect a "true" pipe handler to work, without significant cooperation from the shell that is using the pipes. Conman is on a fish disk somewhere back there in the less than 300 range, maybe even less than 200. -- Mark Waggoner Santa Clara, CA (408) 721-6306 waggoner@dtg.nsc.com Unofficially representing National Semiconductor Local Area Networks Group Officially misrepresenting myself.
rwm@atronx.UUCP (Russell McOrmond) (10/23/90)
In a message posted on 19 Oct 90 23:31:48 GMT,
waggoner@dtg.nsc.com (Mark Waggoner) wrote:
MW>>I want true pipes so I think you should go for it. :-)
MW>I don't know if this is quite what you want, but ConMan, the
MW>console handler by William Hawes can be mounted as a pipe handler and
It does provide what we need - I myself seem to always end up with problems
when I use PIP: for anything.
MW>may provide what you are looking for. How exactly would you expect a
MW>"true" pipe handler to work, without significant cooperation from the
Yes, we want Un-named Pipes - To use in our own programs as opposed to being
used within a Shell.
MW>--
MW>Mark Waggoner Santa Clara, CA (408) 721-6306 waggoner@dtg.nsc.com
MW> Unofficially representing National Semiconductor Local Area Networks Group
MW> Officially misrepresenting myself.
:Later
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (10/28/90)
>>>>> On 19 Oct 90 23:31:48 GMT, waggoner@dtg.nsc.com (Mark Waggoner) said:
Mark> I don't know if this is quite what you want, but ConMan, the
Mark> console handler by William Hawes can be mounted as a pipe handler and
Mark> may provide what you are looking for. How exactly would you expect a
Mark> "true" pipe handler to work, without significant cooperation from the
Mark> shell that is using the pipes.
The PIP: device? As I recall, the ARP shell _did_ use this for real (i.e.
concurrent, no file redirect kludge) pipes.
Cheers,
--
Chuck Phillips MS440
NCR Microelectronics chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckprick@rsami.spoami.com (Rick Schaeffer) (10/31/90)
>In article <ggk.657249739@tirith.UUCP> ggk@tirith.UUCP (Gregory Kritsch) writes: >Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) writes: > >Here's the definitions, for the curious. I'd like to know if this IS >possible under 2.0, and if anyone can think of anything which can't be >done with this definition. (If it can't be done under 2.0, I will >eventually kludge it for 1.3 and see if it works with 2.0). > >BPTR POpen(char *cl, int mode, BPTR stdio) > >int PClose(BPTR pfh) > Some time back the Revision Control System (RCS) that I did in conjunction with Ray Brand was posted to comp.amiga.sources. It contains a working popen/pclose pair of functions implemented using the Lattice fexecv function and the AmigaDos 1.3 PIPE: device. (it is also available in the fish disk collection although I don't remember which numbers). The fexecv function has problems execing BCPL programs but works fine with any C or Assembler program I've tried it with. As to the pipe: device itself, it has been 100% reliable for me. The popen() function uses the process's address to create a unique filename for the pipe. Some while back, I modified the popen/pclose functions to use the arp library AsyncRun function which seems to be able to exec everything I've tried (including BCPL stuff). I'm not sure whether it is worth sending to comp.amiga.sources but if there is enough interest I could post to alt.sources otherwise I'll just send via email. It might be worth noting that I spent some time this past weekend playing with the Dos2.0 CreateNewProcess and System functions. They seem to work fine and I'll be doing a popen/pclose using them this weekend. -- Rick Schaeffer UUCP: uunet!isc-br.isc-br.com!ricks ISC-Bunker Ramo ricks@isc-br.isc-br.com Box TAF-C8 Phone: (509)927-5114 Spokane, WA 99220
pete@violet.berkeley.edu (Pete Goodeve) (11/02/90)
In <1990Oct19.044319.4851@engin.umich.edu>, Ralph Seguin (gilgalad@caen.engin.umich.edu) asks: > Does anybody know whether or not Amiga OS 2.0 will support "true pipes", > ie pipes ala UNIX? I am considering writing a true pipe handler, but > I don't want to waste my time if C= is going to do it for me 8-). > [I think this topic crops up afresh every month or so, but never mind...] OK -- what exactly ARE the criteria for "true" pipes? Or at least, which do you find necessary? I've always felt that the form of unix pipes was really just a fallout from that system's unique "fork". It isn't necessarily the most flexible for other systems like the Amiga. I suspect that your main requirement is that they be unnamed. This is a natural mechanism under unix, where the shell (or other initiator) is the direct parent of both processes that will share the pipe, so it can acquire both ends at once. and pass one to each of its children. The kernel call to do this is not interruptible, so arranging to get a couple of matching descriptors back is no problem. Amiga DOS is NOT synchronous like the unix kernel, though, and the standard FindInput and FindOutput calls will only pick up one end at a time -- and there's no way of matching ends without a name... It would of course be possible, I guess, to add a new Packet type that would set up TWO handles at once, but is it worth it? Giving names to pipes has advantages in an more anarchic (well.. less hierarchically strict, anyhow (:-)) OS like the Amiga's, in that two otherwise totally unconnected processes can use them to communicate. You get problems too, of course, the two main ones being the burden of having to think of -- and type! -- names, and conflicts between names. The latter is most vexing when you want to run multiple copies of a script, for instance. Both of these are real problems only if you're working from a shell. The first is trivial if you're invoking processes from a program of your own, and the second isn't much harder: you simply keep going through some straightforward name sequence until you find an unused one. (This is easy in ARexx, too; I do it this way regularly.) Both of these are real problems only if you're working from a shell. The first is trivial if you're invoking processes from a program of your own, and the second isn't much harder: you simply keep going through some straightforward name sequence until you find an unused one. (This is easy in ARexx, too; I do it this way regularly.) Mostly we need to make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" please!) If, as at least one person (Gregory Kritsch in <ggk.657249739@tirith.UUCP>) has desired, you want to write a POpen function -- or even a pipe(fildes) call -- I don't see why you can't do it the same way. You don't really need an unnamed-pipe device. (I see that someone has done just this, from a posting just encountered.) On the OTHER hand.... The 1.3 PIPE: is not the device we want to have to live with. Not only is it buggy (I've had it refuse to accept perfectly good names) but it lacks one other characteristic that I consider vital to a true pipe: it is NOT "transparent"! In other words you can't read anything from it until either the buffer (4096 bytes I think) has been filled or the input end is closed. This makes interactive applications impossible. And this is why I wrote the IP-device -- now available on Fish Disk #374. [aa...HA!! Now his ulterior motive is exposed... ] This is a pipe with a couple of twists in it. (:-)) It IS transparent -- a packet passed to it is immediately available for reading -- but in addition you can have more than one input active (a "funnel") and you can keep it open beyond the closing of its inputs (so for example you could pipe sporadic logging outputs to a compression program or something). Also you can open a "pipe-console" that will let you get in and out of a Shell via pipes. Okay, so you still have to name your pipes, but I'm doing things with the IP-device that weren't possible before, like having ARexx ship lines off to another process (with no ARexx port) for massaging -- and getting them back! One caution: most C programs probably use buffered output anyway, which is efficient, but defeats us if we want line by line output; fortunately the program in this case was mine (Mat), so I quickly wrote in fflush calls after every newline. (The version of Mat also on #374 does NOT flush every line. Sorry!) -- Pete --
rwm@atronx.UUCP (Russell McOrmond) (11/03/90)
In a message posted on 2 Nov 90 09:15:42 GMT,
pete@violet.berkeley.edu (Pete Goodeve) wrote:
PG>time -- and there's no way of matching ends without a name...
Hmmm - Here's what I end up doing. I end up Opening the Pipe Twice to get two
filehandles - I then use one of them in my program, and pass the other one to
a program that I'm running. I DO get these descriptors at the same time.
Here's WHY you wish them to be un-named this way you KNOW that the names are
unique: I now do some convaluted task+timer thing to try to make sure I have
a unique name. With the number of times I use it, it's inevidable that the same
name gets used twice.
So what might I end up having to do? A Pipe-Name-Server that's protected by a
semaphore? All because I don't have Un-named pipes??
Names are fine when it's a USER that's doing it - BOTH types of pipes are required
at different times. Neithor type of pipe is perfect for ALL applications.
PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|"
PG>please!)
What's wrong with that notation? If you don't like that, what do YOU suggest.
PG>has desired, you want to write a POpen function -- or even a pipe(fildes)
PG>call -- I don't see why you can't do it the same way. You don't really need
PG>an unnamed-pipe device. (I see that someone has done just this, from a
PG>posting just encountered.)
He's working on the same thing that I am, and that is networking software. What
we need to do is run a program (UUX in most cases) that will take message Text
as standard input.
We Get a copy of UUX running, and then we Output the message to it. It's real
simple - Except for these names - We end up spending most of our time trying to
figure the best way to make it Unique. And the largest BUG in all the programs is
the fact that once in a while it's NOT unique, and this brings the whole thing
down. (You end up with one program tying to output to a pipe where the UUX that
was associated with it is NOT running because when it ran, another pipe was open -
That pipe got closed, and TWO copies of UUX exited.
PG>On the OTHER hand.... The 1.3 PIPE: is not the device we want to have
I'm running the pipe in 2.0 - I've not found it to be buggy - WHEN I need a
named pipe, it works quite well.
I tried to send the following off to Rick, but the message bounced.
In a message posted on 30 Oct 90 23:53:18 GMT,
rick@rsami.spoami.com (Rick Schaeffer) wrote:
RS>It might be worth noting that I spent some time this past weekend playing
RS>with the Dos2.0 CreateNewProcess and System functions. They seem to
RS>work fine and I'll be doing a popen/pclose using them this weekend.
This I would be VERY interested in seeing.
:Later
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109gilgalad@caen.engin.umich.edu (Ralph Seguin) (11/03/90)
In article <1990Nov2.091542.25505@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > >In <1990Oct19.044319.4851@engin.umich.edu>, >Ralph Seguin (gilgalad@caen.engin.umich.edu) asks: >> Does anybody know whether or not Amiga OS 2.0 will support "true pipes", >> ie pipes ala UNIX? I am considering writing a true pipe handler, but >> I don't want to waste my time if C= is going to do it for me 8-). >> >[I think this topic crops up afresh every month or so, but never mind...] >OK -- what exactly ARE the criteria for "true" pipes? Or at least, which >do you find necessary? I've always felt that the form of unix pipes was The major problem with any of the pipe implementations for the Amiga is that they build "named" temporary files. Kinda bad, when you're trying to use pipes as an IPC with files larger than a megabyte. For instance: ilbmtoppm blah.iff|ppmquant 256|ppmscale -yscale 1.4|ppmtogif >blah.gif Hmmm... Let's see, that's 3 megs worth of temp files. See ya, Ralph
pete@violet.berkeley.edu (Pete Goodeve) (11/03/90)
In <1990Nov2.173103.18889@engin.umich.edu>, Ralph Seguin (gilgalad@caen.engin.umich.edu) wrote: > > The major problem with any of the pipe implementations for the Amiga is > that they build "named" temporary files. Kinda bad, when you're trying > to use pipes as an IPC with files larger than a megabyte. For instance: > > ilbmtoppm blah.iff|ppmquant 256|ppmscale -yscale 1.4|ppmtogif >blah.gif > > Hmmm... Let's see, that's 3 megs worth of temp files. > Now exactly WHERE did you get THAT idea??! There is no pipe on the Amiga that I know of that works this way. (On the IBM on the other hand...!) Both the 1.3 (Matt Dillon) pipes and Ed Puckett's directory-based version use circular buffers of fixed size: if the buffer gets full, the writer will block until the reader takes some out of it. No disk storage at all is used! My IP-Device works a little differently in that the packet passed by the writer acts as a temporary buffer until it is read, which minimizes byte copying (but may cause the writer to block more readily). -- Pete --
a143@mindlink.UUCP (Ed Meyer) (11/03/90)
> eeh@public.BTR.COM writes: > > Msg-ID: <890@public.BTR.COM> > Posted: 3 Nov 90 22:26:55 GMT > > Org. : BTR Public Access UNIX, MtnView CA, Contact: cs@btr.com 415-966-1429 > Person: Eduardo E. Horvath eeh@btr.com > > In article <1990Nov3.073201.8227@agate.berkeley.edu> pete@violet.berkeley.edu > (Pete Goodeve) writes: > > > > > >In <53407.657565922@atronx.UUCP>, Russell McOrmond (rwm@atronx.UUCP) > writes: > >> In a message posted on 2 Nov 90 09:15:42 GMT, > >> pete@violet.berkeley.edu (Pete Goodeve) wrote: > > >> PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid > "|" > >> PG>please!) > > >> What's wrong with that notation? > >> If you don't like that, what do YOU > suggest. > > > What about "=" ? It even looks alot more lile a pipe than "|". I > think > that the only place "=" will cause problems would be when using something > like > set or in scripts where you are doing comparisons. In scripts, just look for > "==" or ">=", etc. Set can be modified to allow something like: > > set FRED 55 > or > set "FRED=55" > > both give the same results (i.e. FRED=55.) Is there anything else that using > "=" as a pipe would break? > > > -- > ======================================================================= == > Eduardo Horvath eeh@btr.com > ..!{decwrl,mips,fernwood}!btr!e eh > "Trust me, I am cognizant of what I am doing." - Hammeroid And suddenly, in the twilight ... brilliance. Okay, okay: perhaps over enthusiastic, but I like it; an equal sign for a pipe.
pete@violet.berkeley.edu (Pete Goodeve) (11/03/90)
In <53407.657565922@atronx.UUCP>, Russell McOrmond (rwm@atronx.UUCP) writes: > In a message posted on 2 Nov 90 09:15:42 GMT, > pete@violet.berkeley.edu (Pete Goodeve) wrote: > PG>time -- and there's no way of matching ends without a name... > > Hmmm - Here's what I end up doing. I end up Opening the Pipe Twice to get two > filehandles - I then use one of them in my program, and pass the other one to > a program that I'm running. I DO get these descriptors at the same time. Well, no. You're actually making two calls to the OS with the same name, NOT making a single call that returns two matching file descriptors -- which is what I meant. > Here's WHY you wish them to be un-named this way you KNOW that the names are > unique: I sorta thought that was what I was saying...(:-)) A little more diffusely than you though, I'll admit. > I now do some convaluted task+timer thing to try to make sure I have > a unique name. With the number of times I use it, it's inevidable that the same > name gets used twice. > > So what might I end up having to do? A Pipe-Name-Server that's protected by a > semaphore? All because I don't have Un-named pipes?? I'm sorry, but I don't really see the difficulty. As long as your device objects if you try to do more than one open simultaneously with the same name, all you do is keep trying opens with slightly different names until one succeeds. The moment you do succeed, you've got an exclusive, and any other process going through the same business will pass over than one and find a unique one of its own. If you have a reasonable way of hashing up a name, you shouldn't have to make more than a couple of probes before you get in. To be more concrete, here's some [really] pseudocode for a "pipe(fildes)" function: Make an initial stab at a name, perhaps using the middle bits of the current process address as a basis -- getting 'P!4283' say. Do an fopen call on your pipe device -- probably at the read end -- with that name. If the call fails, add something (modulo 10000 or whatever) to the numeric part of the name, and go back to the previous step. [You could simply add 1, if the name space is sparse enough, or you could choose some different increment for each process.] When an open succeeds, do another fopen -- for write -- to the same name. Return both read and write file handles in the 'fildes' structure supplied. And that's it. > > Names are fine when it's a USER that's doing it - BOTH types of pipes are required > at different times. Neithor type of pipe is perfect for ALL applications. > But when it comes down to it, all pipes, unix-type too, are ""named"" -- even if only by the hex address of the control structure! The only important point is whether the user has to WORRY about it. Seems to me all you need to remove that worry is some scheme like the above. > > PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" > PG>please!) > > What's wrong with that notation? Just that the "|" character is significant in AmigaDos pattern matching. I'm not quite sure how you'd be certain of distinguishing its use there from a pipe request. > If you don't like that, what do YOU suggest. Well... er... ahh... (:-)) To brutally honest, I haven't really given much thought to the topic at all (which is why I didn't actually MAKE any suggestion!). Maybe after I've thought a while, I will. Seems like a suitable topic for net discussion, anyhow. -- Pete --
a143@mindlink.UUCP (Ed Meyer) (11/04/90)
From seeing the various messages, here is a collage ... the equal sign = the bowtie >< the chevron >> (nice for directionality) from pascal := Choose one or create one, then promote it so some tech-wiz can implement it/them. It's beyond my talents at present or I would put one into practice: I think | is cute but not as iconic as the above and not as informative as others I've see. Cheers.
peter@sugar.hackercorp.com (Peter da Silva) (11/04/90)
In article <53407.657565922@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: > Here's WHY you wish them to be un-named this way you KNOW that the names are > unique: I now do some convaluted task+timer thing to try to make sure I have > a unique name. I don't see how !printf("RAM:%08lx.%d", FindTask((char *)0), seq++)! would fail. The task that creates the pipe should continue to execute over the lifetime of the pipe for this to work, but that should be the case anyway. This is the general temp-file problem. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (11/04/90)
In article <1990Nov3.073201.8227@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > Just that the "|" character is significant in AmigaDos pattern matching. > I'm not quite sure how you'd be certain of distinguishing its use there from > a pipe request. Good point! > > If you don't like that, what do YOU suggest. The version 6 shell and the version 7 (bourne) shell use either '|' or '^' as a pipe character. I understand that at least one Amiga shell requires pipes to have white-space around them. The use of '^' might be a better alternative, even if it will break c-shell history (which is something I want, weird though that might sound to some of you). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
navas@cory.Berkeley.EDU (David C. Navas) (11/04/90)
In article pete@violet.berkeley.edu (Pete Goodeve) writes: >Just that the "|" character is significant in AmigaDos pattern matching. >I'm not quite sure how you'd be certain of distinguishing its use there from >a pipe request. Well, I haven't really used ADos pattern matching much -- my only real example was taken from an incorrect example provided in my 2.0? Workbench which tended to crash my machine every so often :) However, wouldn't such uses usually be enclosed in parenthesis? ala foo.(h|c) That might make the parsing a bit simpler. At worst case you'll need to put some white space in there... Having another non-standard symbol would push the readability of this news group way down (due to tonnage of abusive flames). While we're at it, why not make those ">" and "<" placable anywhere on the command line? [IE. figure out how "run" would redirect output correctly...] Later -Dave > >> If you don't like that, what do YOU suggest. > >Well... er... ahh... (:-)) To brutally honest, I haven't really given much >thought to the topic at all (which is why I didn't actually MAKE any >suggestion!). Maybe after I've thought a while, I will. Seems like >a suitable topic for net discussion, anyhow. > > -- Pete -- David Navas navas@cory.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me (and Calvin)
eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (11/04/90)
In article <1990Nov3.073201.8227@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > > >In <53407.657565922@atronx.UUCP>, Russell McOrmond (rwm@atronx.UUCP) writes: >> In a message posted on 2 Nov 90 09:15:42 GMT, >> pete@violet.berkeley.edu (Pete Goodeve) wrote: >> PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" >> PG>please!) >> What's wrong with that notation? >> If you don't like that, what do YOU suggest. What about "=" ? It even looks alot more lile a pipe than "|". I think that the only place "=" will cause problems would be when using something like set or in scripts where you are doing comparisons. In scripts, just look for "==" or ">=", etc. Set can be modified to allow something like: set FRED 55 or set "FRED=55" both give the same results (i.e. FRED=55.) Is there anything else that using "=" as a pipe would break? -- ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid
pete@violet.berkeley.edu (Pete Goodeve) (11/04/90)
In <6977@sugar.hackercorp.com> (3 Nov), Peter da Silva (peter@sugar.hackercorp.com) writes: > > The version 6 shell and the version 7 (bourne) shell use either '|' or '^' > as a pipe character. I understand that at least one Amiga shell requires > pipes to have white-space around them. The use of '^' might be a better > alternative, even if it will break c-shell history (which is something > I want, weird though that might sound to some of you). I would whimper rather a lot over that choice! I chose '^' to extend the pattern matching convention (in Mat), where it indicates a "slice" in the pattern (and I use it similarly in templates for rearranging the slices). Actually I sort of fear that ANY character co-opted for a pipe separator would screw up somebody. Maybe we'll have to take some other route (Heh..!). I'm not sure that requiring spaces around the character would be adequate either -- I often have spaces in my patterns, and it would be quite possible for them to be adjacent to the '|'. Of course spaces are always enclosed in quotes, so maybe there'd be no conflict. In <8450@pasteur.Berkeley.EDU> (3 Nov), David C. Navas (navas@cory.Berkeley.EDU) writes: > > Well, I haven't really used ADos pattern matching much -- my only real example > was taken from an incorrect example provided in my 2.0? Workbench which > tended to crash my machine every so often :) I use it a heck of a lot -- mainly for things like: copy this_one|that_one|the_other to df0: > However, wouldn't such uses usually be enclosed in parenthesis? ala foo.(h|c) Not necessarily -- see above! > > [.....] Having another non-standard symbol would push > the readability of this news group way down (due to tonnage of abusive flames). This is true... > While we're at it, why not make those ">" and "<" placable anywhere on the > command line? [IE. figure out how "run" would redirect output correctly...] Yurr. Is there anything in the current CLI/Shell syntax that really prohibits this? At one time I had myself convinced that there was, mainly because you could (in theory) do something like: run >somewhere myprog >somewhere_else Can't say that I've ever found much need for such a construction though (except for suppressing the "[CLI n]" message with "run >NIL: myprog"). I'd think that any piping shell would call RUN implicitly anyhow, so we're probably free to do what we like. In <890@public.BTR.COM> (3 Nov), Eduardo E. Horvath (eeh@public.BTR.COM) writes: > > What about "=" ? It even looks alot more lile a pipe than "|". I think > that the only place "=" will cause problems would be when using something like > set or in scripts where you are doing comparisons. [.....] > I guess the arguments against this are about the same as for '|' and '^'. It would be hard to be cerain you weren't breaking anything. Maybe it's time for my own suggestions. [Uh... just a moment... Darn, this flameproof material is uncomfortable...!] I'm wondering if we shouldn't broaden possibilities a little. I'm not sure for example if we should fixate on single line, multi-process, commands. Supposing we keep to a single command per line as it is now, but PREFIX the command with some special character? In this position you could use almost anything. Oh, I dunno, how about this sort of thing?: <list #?.(c|h) <myformatter myprinter This looks perfectly feasible within scripts, but it might be a nuisance when typing things at the console. History would be a pain for example. Alternatively, maybe instead of a single separator character we could use a unique pair, e.g.: list #?.(c|h) >< myformatter ><myprinter (trailing space optional, leading one required) I figure that that particular pair has such a relation to current redirection syntax that it wouldn't interfere with anything else (except that .BRA & .KET would probably then be essential!). [Oof -- time to take the suit off again.] -- Pete --
pete@violet.berkeley.edu (Pete Goodeve) (11/04/90)
Duhh -- I've been thinking. Maybe I'm just about to do a COMPLETE
about-face on what I said last time.
I suppose there's really no more conflict between the use of '|' as
a pipe character and its other uses than there is between, say, using '>'
for redirection and having it pop up in a pattern string (as a plain
character to be matched). At least this is the case if you insist on a
space preceding it (as you need before '>' redirection), because a pattern
can never BEGIN with an alternation mark. (Quotes and parentheses would
have to be taken into account naturally.)
list #?.c|???.h | myformatter |myprinter
Any other problems? If not, I withdraw my objections.
-- Pete --gregg@cbnewsc.att.com (gregg.g.wonderly) (11/04/90)
From article <1990Nov4.072423.408@agate.berkeley.edu>, by pete@violet.berkeley.edu (Pete Goodeve): > At least this is the case if you insist on a > space preceding it (as you need before '>' redirection), because a pattern > can never BEGIN with an alternation mark. (Quotes and parentheses would > have to be taken into account naturally.) > > list #?.c|???.h | myformatter |myprinter > > Any other problems? If not, I withdraw my objections. I find the UN*X shells' quoting conventions to be quite adequate at avoiding the need to require a SPACE anywhere. If you want something which contains meta characters to become part of a parameter-word, you quote it. That makes it pretty simple to put together whatever you need. grep some-text *.c egrep "some-text|other-text|other-text" *.c etc. Of course the biggest part of this is educating people which characters are special meta-characters which the shell will treat in a special way. I usually just tell people, when you want a character that is not a letter or digit to be a part of a parameter to a program, just quote it. This results in no surprises. -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
peter@sugar.hackercorp.com (Peter da Silva) (11/05/90)
In article <1990Nov4.054222.24999@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > I would whimper rather a lot over that choice! I chose '^' to extend the > pattern matching convention (in Mat), where it indicates a "slice" in the > pattern (and I use it similarly in templates for rearranging the slices). I'm unhappy with "extensions" to the pattern matching convention, particularly since I think it should be done in the shell (well, I can dream). How about making a second-order jump: ^. in pascal becomes -> in C, so: 1> list lformat="%s" -> cpio -ocv > rdf:df0 So "->" is "redirect to program". Or how about making a new command that uses the "+" syntax like in run? 1> pipe list lformat="%s" + cpio -ocv >rdf:df0 -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
limonce@pilot.njin.net (Tom Limoncelli) (11/05/90)
As more and more people get 2.0, we will finally see the demise of the "why not use * for wilde cards? I hate to type #? !" The end of an era. Tom "I feel the same way as I did when the Berlin Wall was torn down" Limoncelli P.S. Of course, if we make anything-but-| the symbol for pipes, we'll start a whole era of "why doesn't C-A use | for pipes?" postings. Praise be the bandwidth! -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"
peter@sugar.hackercorp.com (Peter da Silva) (11/05/90)
In article <1990Nov4.072423.408@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > list #?.c|???.h | myformatter |myprinter Well, I can imagine a pattern matching "nothing or a subdirectory". Hold on. Well, dir and list don't match the current directory with an empty pattern so that's OK. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/05/90)
In <890@public.BTR.COM>, eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) writes: >In article <1990Nov3.073201.8227@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >> >> >>In <53407.657565922@atronx.UUCP>, Russell McOrmond (rwm@atronx.UUCP) writes: >>> In a message posted on 2 Nov 90 09:15:42 GMT, >>> pete@violet.berkeley.edu (Pete Goodeve) wrote: > >>> PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" >>> PG>please!) > >>> What's wrong with that notation? >>> If you don't like that, what do YOU suggest. > > > What about "=" ? It even looks alot more lile a pipe than "|". I think >that the only place "=" will cause problems would be when using something like >set or in scripts where you are doing comparisons. In scripts, just look for >"==" or ">=", etc. Set can be modified to allow something like: > >set FRED 55 > or >set "FRED=55" > >both give the same results (i.e. FRED=55.) Is there anything else that using >"=" as a pipe would break? I don't see anything wrong with the '|' as pipe character, since the context for each use of it is absolutely clear. In the case of PIP: (using Conman), you must delimit the pipe character with whitespace, but that isn't a big deal to me. Since the '|' is already in use in regular expressions, overloading it for pipes seems to me to be preferable to using another character and making it special too. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lrg7030@uxa.cso.uiuc.edu (Loren Rittle) (11/05/90)
Peter da Silva writes: > The version 6 shell and the version 7 (bourne) shell use either '|' or '^' > as a pipe character. I understand that at least one Amiga shell requires > pipes to have white-space around them. The use of '^' might be a better > alternative, even if it will break c-shell history (which is something > I want, weird though that might sound to some of you). The shell of which you speak is the WShell v1.2 (highly recommended :-). It does indeed ``force'' you to have white-space on the leading edge of the pipe symbol, which defaults to `|', but can be changed via the WShell-config file to be any symbol you desire. Because Bill enforces the white-space before pipe symbol rule in the WShell, there is no way it could be mixed up with AmigaOS pattern matching. Have your burger, your way, some might say... Loren J. Rittle
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/05/90)
In article <6984@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
+
+I'm unhappy with "extensions" to the pattern matching convention, particularly
+since I think it should be done in the shell (well, I can dream). How about
+making a second-order jump:
+
+ ^. in pascal becomes -> in C, so:
+
+1> list lformat="%s" -> cpio -ocv > rdf:df0
+
+So "->" is "redirect to program".
Fooey! That is my favorite choice, and I wanted to spring it on you (given
the recent chastizing post about posting non-essential stuff!). It seems to
be the most logical choice, since (a) it is another derivation of `>', like
`>>' for append, and >, <, >>, <<, and -> all seem to me to be in the same
class of operators.
I really dislike wildcard expansion in the shell. Granted, it would have
been nicer in 1.3, since there was no library support of standard pattern
matching, but now that 2.0 has good, standardized routines to do this, I
can't for the life of me see how shell expansion is superior. The amount of
coding that must be done is no greater, the size of your programs is no
greater, and having the expansion done by the current program eliminates all
of that silly quoting that you have to remember to do in Un*x, whenever you
want to pass wildcards to a program. It is just a lot easier to write a
program like Arp's move, which does exactly what I expect it to if I say
move #?.c sys:backups/src/#?.bak
since move gets to decide how to handle the patterns. I guess this is a
religious question.
+<peter@sugar.hackercorp.com>.
ken
--
Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-5218
`You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/05/90)
In article <1990Nov4.195838.25540@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: +Peter da Silva writes: +> The version 6 shell and the version 7 (bourne) shell use either '|' or '^' +> as a pipe character. I understand that at least one Amiga shell requires +> pipes to have white-space around them. The use of '^' might be a better +> alternative, even if it will break c-shell history (which is something +> I want, weird though that might sound to some of you). + +The shell of which you speak is the WShell v1.2 (highly recommended :-). +It does indeed ``force'' you to have white-space on the leading edge of +the pipe symbol, which defaults to `|', but can be changed via the +WShell-config file to be any symbol you desire. Because Bill enforces +the white-space before pipe symbol rule in the WShell, there is no +way it could be mixed up with AmigaOS pattern matching. +Have your burger, your way, some might say... Making the idiot user include whitespace or not seems to be an awkward way of handling it, to me. How do I remember if I should throw a space in, of if it isn't allowed? Just be a little flexible, come up wita a new symbol for pipes (c'mon, guys... `->' is the way to go...), and stick with it. Seems to me that in any `modern' command-line interface, enforcing the amount of whitespace between tokens is clumsy ("In columns 1-10 appear the command name. Column 12 contains the optional redirection symbol `<'. If present...") +Loren J. Rittle ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
pete@violet.berkeley.edu (Pete Goodeve) (11/05/90)
In <1990Nov4.150403.28982@cbnewsc.att.com> (4 Nov), gregg.g.wonderly (gregg@cbnewsc.att.com) writes: > > I find the UN*X shells' quoting conventions to be quite adequate at > avoiding the need to require a SPACE anywhere. If you want something which > contains meta characters to become part of a parameter-word, you quote it. > That makes it pretty simple to put together whatever you need. > [......] > Of course the biggest part of this is educating people which characters > are special meta-characters which the shell will treat in a special way. > [.....] I incline somewhat on the opposite tack. The UN*X shell syntax is elegant in the abstract, but I've found it is one of the things that contributes to the reputation for unfriendliness. The plethora of metacharacters is one of the problems (and the choice of '.' as one of them is a real pain!). Conversely, the use of a space is natural to most people -- and the space bar is the easiest stroke on a keyboard! In <6984@sugar.hackercorp.com> (4 Nov), Peter da Silva (peter@sugar.hackercorp.com) writes: > > I'm unhappy with "extensions" to the pattern matching convention, particularly > since I think it should be done in the shell (well, I can dream). In the shell? [...Now this is another well trodden path, isn't it?] We definitely take different forks here. The big problem is that you have NO guarantee that a command line argument refers to a file -- not even if it's a pattern. In particular, Mat uses patterns to scan the contents of TEXT files (though it does things with filenames too); the "slices" I was talking about are used for rearrangement of the matched lines for output. What I've wanted -- and we now are getting with 2.0 -- are standard calls to the kernel functions that it make it painless for a program to do things like (standard) pattern matching itself. > How about making a second-order jump: > > ^. in pascal becomes -> in C, so: > > 1> list lformat="%s" -> cpio -ocv > rdf:df0 > > So "->" is "redirect to program". > This I like! It's certainly suitably "iconic". (On the other hand it's not quite as convenient to type as my '><' suggestion.) Or you might even combine it with Eduardo Horvath's suggestion and make it '=>'. Or, not quite so mnemonic, but easier to parse (only one metachar to worry about), "redirect to program" could be ">=". > Or how about making a new command that uses the "+" syntax like in run? > > 1> pipe list lformat="%s" + > cpio -ocv >rdf:df0 > -- > Also not a bad possibility, though once again it has the problem of keeping multi-line commands conveniently in a history list. (Which, BTW, is a general difficulty that would be nice to have a cute solution to. Somehow you ought to be able to "group" commands -- without having to create a script -- so that they can be backed up to and re-executed as that group.) In <6985@sugar.hackercorp.com> (4 Nov): > > Well, I can imagine a pattern matching "nothing or a subdirectory". [...] Yeah -- no problem here, because "nothing" in a pattern is '%'. I think that hidden behind all this discussion is a big difference in philosophy between UN*X and AmigaDOS (well, Tripos). The C-shell and so on sort of assume by default that arguments are probably filenames, so things like globbing get done automatically unless you specifically tell it otherwise. On the other hand AmigaDOS essentially believes that the argument string is only the concern of the program receiving it, and passes it on (almost) unchanged. In fact the BCPL convention went further than this: the argument part of the command line was simply left in the input stream for the program to read; if it wanted it could keep ON reading that stream to get more arguments -- this is how the '+' mechanism works (or did prior to 2.0 -- dunno if it does still). In practice it's not quite like that, with removal of comments, quoted strings, redirection, and so on, All in all, though, the command line still gets passed on in fairly pure form to its destination. All the suggestions we've been tossing back and forth mean more massaging on the command line, and just MAY have unexpected consequences. As John Campbell said, "You can't do just one thing"! Even obvious sounding things like permitting redirection anywhere on the line mean a change in assumptions, and have to be considered VERY carefully. ('Course on the other hand, I guess there's no reason why we can't just start afresh...) -- Pete --
FelineGrace@cup.portal.com (Dana B Bourgeois) (11/05/90)
If you're gonna allow multiple characters for these symbols then do go with symbols suggest the action. I kinda like -> for redirection although => is pretty good too. I've also liked the MSDOS > for create and re- direct versus >> which is redirect and append. And the idea of multi-line commands could be implemented by having all redirection characters be preceded by a new-line char (and optional white space). Multi-line commands would have to end with a special character that says 'more to follow' such as +. I don't know the ramifications of all this - I am not a Unixer. So if it has potential to cause horrendous problems, be gentle with me. :) Here's an example: "command" <"redirected stdin" + => "command with stdin from pipe" + => "command with stdin from pipe" >"redirected stdout" Dana Bourgeois @ cup.portal.com
peter@sugar.hackercorp.com (Peter da Silva) (11/05/90)
In article <1990Nov4.150403.28982@cbnewsc.att.com> gregg@cbnewsc.att.com (gregg.g.wonderly) writes: > I find the UN*X shells' quoting conventions to be quite adequate at > avoiding the need to require a SPACE anywhere. If you want something which > contains meta characters to become part of a parameter-word, you quote it. The problem is that in this case you have two sets of metacharacters conflicting at the shell level. Think about the following: list lformat=%s #?.c|#?.h | zoo ... Now if you quote that: list lformat=%s "#?.c|#?.h" | zoo ... How does list know whether to expand it or not? What if you're using a shell that does expansion? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (11/05/90)
In article <1990Nov5.040638.6580@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > and the choice of '.' as [a UNIX shell metacharacter] is a real pain!. Huh? "." isn't a UNIX shell metacharacter. What are you talking about? > In the shell? [...Now this is another well trodden path, isn't it?] > We definitely take different forks here. The big problem is that you have > NO guarantee that a command line argument refers to a file -- not even > if it's a pattern. On the other hand, if it's not in the shell you have no idea if a given program handles patterns or if it uses the standard ones. This is a problem in every operating system that I've used except for UNIX. > In particular, Mat uses patterns to scan the contents > of TEXT files (though it does things with filenames too); the "slices" I > was talking about are used for rearrangement of the matched lines for > output. Like \1, \2, \3 and so on in "ed" style regular expressions? What's wrong with using backslash for that... it doesn't conflict with UNIX anything. (and I have no problem quoting my "sed" arguments) (speaking of which, how does MAT differ functionally from sed?) > What I've wanted -- and we now are getting with 2.0 -- are standard calls > to the kernel functions that it make it painless for a program to do things > like (standard) pattern matching itself. And Commodore themselves don't use them for all programs: 1.Ram Disk:> list foo Directory "Ram Disk:" on Monday 05-Nov-90 foo 26 -s--rwed Today 06:15:58 1 file - 2 blocks used 1.Ram Disk:> execute fo#? EXECUTE: Can't open fo#? me> [what about ->] > This I like! It's certainly suitably "iconic". (On the other hand it's > not quite as convenient to type as my '><' suggestion.) Or you might even > combine it with Eduardo Horvath's suggestion and make it '=>'. Which is no easier to type, but does stand out more. > > 1> pipe list lformat="%s" + > > cpio -ocv >rdf:df0 > Also not a bad possibility, though once again it has the problem of keeping > multi-line commands conveniently in a history list. On the other hand it could be implemented to work in the existing AmigaShell and CLI. > In fact the BCPL convention went further than this: the argument part of > the command line was simply left in the input stream for the program to > read; A nice idea but conflicts with redirection. ISIS did the same thing on the old Intel development systems (ISIS is what originally inspired CP/M, by the way... what goes around comes around). I've often thought that arguments should be an input stream, read from a new file descriptor "stdcmd". So you could write your program as: while(getword(stdcmd, buffer)) { do_something_with buffer; } So if you opened a pipe to stdcmd... > All the suggestions we've been tossing back and forth mean more massaging > on the command line, and just MAY have unexpected consequences. Which is an advantage for the "pipe command+\ncommand+\ncommand" syntax. > 'Course on the > other hand, I guess there's no reason why we can't just start afresh...) One of these days I've gotta start using SKSH. Maybe when there's a 2.0 version that doesn't use arp.library. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mcafee@elmst.enet.dec.com (Steve McAfee) (11/05/90)
In article <Nov.4.12.36.09.1990.26991@pilot.njin.net>, limonce@pilot.njin.net (Tom Limoncelli) writes... >As more and more people get 2.0, we will finally see the demise of the >"why not use * for wilde cards? I hate to type #? !" > >The end of an era. Huh? I asked a few days back what happened to * wildcard support in 2.0 and no one responded. I have a 3000 and none of the 2.0 docs I've got tell how to get this. Do you know a way to turn this on? regards, steve
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/06/90)
In <1990Nov5.021744.3349@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >Making the idiot user include whitespace or not seems to be an awkward way of >handling it, to me. How do I remember if I should throw a space in, of if it >isn't allowed? Just be a little flexible, come up wita a new symbol for >pipes (c'mon, guys... `->' is the way to go...), and stick with it. Seems to >me that in any `modern' command-line interface, enforcing the amount of >whitespace between tokens is clumsy ("In columns 1-10 appear the command >name. Column 12 contains the optional redirection symbol `<'. If >present...") Sure, and lets do away with the convention of requiring whitespace between the command and arguments, and between argument too. :-) Seriously, if it weren't for the ability of Unix shells to accept the pipe operator without delimiting whitespace, it would be a complete non-issue. Nobody would even think to question it. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
smp@myamiga.UUCP (Steve Palm) (11/06/90)
I would never have guessed that such a great amount of bandwith could be taken
up with such a simple topic as pipes and wildcards... Live and learn...
My suggestion is to leave the current wildcard regular expressions alone.
They are great. Perhaps add * for those out there who can't stomach #?.
For the pipe, leave it as |. After all, as someone pointed out, overloading
this regular expression character works splendidly well and doesn't reserve
yet another character. Besides, I believe that it would be clear when you
wanted it to be a pipe character and when it was part of an expression.
--
/// AMIGA: | Steve Palm, Sysop of FidoNet node 1:11/16
/// FOR THE | UUCP: {gatech,ames,rutgers}!ncar!asuvax!stjhmc!myamiga!smp
\\\/// CREATIVE | INTERNET: [not yet available]
\XX/ MIND |_________________________________________________________ pete@violet.berkeley.edu (Pete Goodeve) (11/06/90)
In <6991@sugar.hackercorp.com> (5 Nov), Peter da Silva (peter@sugar.hackercorp.com) writes: > In article <1990Nov5.040638.6580@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: |> and the choice of '.' as [a UNIX shell metacharacter] is a real pain!. > > Huh? "." isn't a UNIX shell metacharacter. What are you talking about? > Heh! (Kaff..!) Well, see -- that just goes to show how confusing it all is! (:-)) Of course it's not a SHELL metacharacter; I was thinking of all the OTHER kinds of regular expressions under unix. Sorree! |> In particular, Mat uses patterns to scan the contents |> of TEXT files (though it does things with filenames too); the "slices" I |> was talking about are used for rearrangement of the matched lines for |> output. > > Like \1, \2, \3 and so on in "ed" style regular expressions? What's wrong > with using backslash for that... it doesn't conflict with UNIX anything. Nothing at all really, except that the '^' was a natural for marking a "slice point" in a pattern, and I economized in special characters by using it in replacement templates as well. > (and I have no problem quoting my "sed" arguments) I think I've satisfied myself that this overloading/quoting question is a non-issue after all. > (speaking of which, how does MAT differ functionally from sed?) Um, tough question. All I know is I got frustrated trying to make sed do something I wanted a few months ago, so I hauled out the Mat code again to make it do everything *I* needed. Of course the obvious difference is that it uses Amiga style pattern matching, rather than ed. It has a much less complex syntax than sed -- which to be frank I found thoroughly intimidating. On the other hand it lacks things like address ranges. > > > [.....] > 1.Ram Disk:> execute fo#? > EXECUTE: Can't open fo#? Consistency WOULD be nice, wouldn't it..? -- Pete --
pete@violet.berkeley.edu (Pete Goodeve) (11/06/90)
In <2188@lpami.wimsey.bc.ca> (4 Nov), Larry Phillips (lphillips@lpami.wimsey.bc.ca) writes: > Since the '|' is already in use in regular expressions, overloading it for > pipes seems to me to be preferable to using another character and making it > special too. A pertinent point. In <1990Nov5.021744.3349@opusc.csd.scarolina.edu> (5 Nov), Ken Yarnall (yarnall@opusc.csd.scarolina.edu) writes: > Making the idiot user include whitespace or not seems to be an awkward way of > handling it, to me. How do I remember if I should throw a space in, of if it > isn't allowed? [.......] Seems to > me that in any `modern' command-line interface, enforcing the amount of > whitespace between tokens is clumsy ("In columns 1-10 appear the command > name. Column 12 contains the optional redirection symbol `<'. If > present...") But it's not really like that is it? Separatingtokenswithwhitespaceissometh ingwedoallthetime. EXTRA white space shouldn't be prohibited, naturally, but I don't see any problem in requiring it in reasonably obvious places. -- Pete -- [and for those who still advocate the C-Shell style, herewith a quote from the BUGS: section of the man pages for csh: "Quoting conventions are contradictory and confusing." ]
pete@violet.berkeley.edu (Pete Goodeve) (11/06/90)
In <35613@cup.portal.com> (5 Nov), Dana B Bourgeois (FelineGrace@cup.portal.com) writes: > [.......] I've also liked the MSDOS > for create and re- > direct versus >> which is redirect and append. I hope you're aware that the Shell has accepted the ">>" convention since 1.3... (and it's a unix convention also BTW) -- Pete --
peter@sugar.hackercorp.com (Peter da Silva) (11/06/90)
In article <1990Nov4.215000.2760@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: > I really dislike wildcard expansion in the shell. Granted, it would have > been nicer in 1.3, since there was no library support of standard pattern > matching, but now that 2.0 has good, standardized routines to do this, I > can't for the life of me see how shell expansion is superior. (a) There are still machines outthere running 1.3. Like, most of them. (b) You still need quoting conventions. Quickly, how do you delete a file named "#?.c"? Why not use them consistently? (c) You're at the mercy of programmers who neglect to provide for it. VAX/VMS has had wildcard libraries forever, and it still trips me up. That's how you get files named "#?.c" in the first place. For things like "move", I'd rather go to slices: move {.*}.c \1.h You know, like in regular expressions... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/07/90)
In article <1990Nov6.075223.29417@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: + +In <1990Nov5.021744.3349@opusc.csd.scarolina.edu> (5 Nov), +Ken Yarnall (yarnall@opusc.csd.scarolina.edu) writes: +> Making the idiot user include whitespace or not seems to be an awkward way of +> handling it, to me. How do I remember if I should throw a space in, of if it +> isn't allowed? [.......] Seems to +> me that in any `modern' command-line interface, enforcing the amount of +> whitespace between tokens is clumsy ("In columns 1-10 appear the command +> name. Column 12 contains the optional redirection symbol `<'. If +> present...") +But it's not really like that is it? Separatingtokenswithwhitespaceissometh +ingwedoallthetime. EXTRA white space shouldn't be prohibited, naturally, +but I don't see any problem in requiring it in reasonably obvious places. But, I view the pipe symbol (and others like it) as a separator, too. I realize I'm being picky, here, but I don't see this as an `obvious' place for whitespace. If we use |, and require whitspace, then ls -l usr:big/ole/dir|more and ls -l usr:big/ole/dir | more are two completely different fish kettles. Confusion reigns. I like ls -l usr:big/ole/directory->more (which = ls -l usr:big/ole/dir -> more) much better, and since it builds on previous syntax, I don't think it's overkill. + -- Pete -- + +[and for those who still advocate the C-Shell style, herewith a +quote from the BUGS: section of the man pages for csh: + + "Quoting conventions are contradictory and confusing." ] Touche! ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
al158305@mtecv2.mty.itesm.mx (Gustavo Cordova Avila) (11/07/90)
peter@sugar.hackercorp.com (Peter da Silva) writes: >The problem is that in this case you have two sets of metacharacters >conflicting at the shell level. Think about the following: > list lformat=%s #?.c|#?.h | zoo ... >Now if you quote that: > list lformat=%s "#?.c|#?.h" | zoo ... >How does list know whether to expand it or not? What if you're using a shell >that does expansion? Well, then it doesn't expand! I'm using csh4.02a (I think), and if you put something in quotes it doesn't do anything to it, it gets passed as-is, and until now, I prefer it over any other shell, being it C= standard shell (1.3), ash, ksh, etc. Nothing beaten it yet. And what's this about using + for piping comands?? Don't you know that that's the char for indicating that the next is a command (in run's case) or more arguments... '->'??? It's easier to type only one char, and by custom it's always been '|'. Then again, I'm an old fashion guy, I remember when '=' was used for renaming! (remember cp/m? :) Well, gotta go... cu@the.mouse -- ************************** Gustavo Cordova Avila *************************** * al158305@mtecv2.mty.itesm.mx | Majoring in Electronics Systems Eng. * * pl158305@tecmtyvm.mty.itesm.mx | in Monterrey Tech, Mexico. * ****************************************************************************
peter@sugar.hackercorp.com (Peter da Silva) (11/07/90)
In article <2641@mtecv2.mty.itesm.mx> al158305@mtecv2.mty.itesm.mx (Gustavo Cordova Avila) writes: > And what's this about using + for piping comands?? Don't you know that > that's the char for indicating that the next is a command (in run's case) > or more arguments... Right, which is why I came up with the idea for a "pipe" command that works like "run", and will provide piping for all shells and Amigas: pipe cmd1 args + cmd2 args + cmd3 args Solves the metacharacter conflict problem nicely. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
a218@mindlink.UUCP (Charlie Gibbs) (11/08/90)
In article <7010@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Nov6.190147.10534@opusc.csd.scarolina.edu> >yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >> ls -l usr:big/ole/directory->more (which = ls -l usr:big/ole/dir -> more) > >So long as you make that: > > list usr:big/old/directory->more > >Because making - a metacharacter will break UNIX-style command options. Which >is probably a good thing, IMHO... they're usually the result of laziness on >the part of the programmer who did the Amiga port. To each his own, I guess. I much prefer Unix-style command options; Amiga-style keywords take us back to the good old days of COBOL's reserved words, which are a supreme pain in the butt. Why shouldn't I be able to have files called ALL or CLONE, and copy them by just saying COPY ALL CLONE without having to worry about quoting and other such stuff? Which other file names suddenly become "off limits" when someone makes up a new keyword in his program? The Unix "-" delimiter is unambiguous, and is easy to keep out of file names without getting all bent out of shape. As for pipe characters, my vote is for retaining the Unix "|" symbol. I can't think of any compelling reason to make people switch to something different. Besides, multi-character operators are a pain to parse (but my viewpoint is no doubt prejudiced by the amount of programming I do). Charlie_Gibbs@mindlink.UUCP Smash violence!
daveh@cbmvax.commodore.com (Dave Haynie) (11/08/90)
In article <1990Nov2.173103.18889@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >In article <1990Nov2.091542.25505@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >The major problem with any of the pipe implementations for the Amiga is >that they build "named" temporary files. Kinda bad, when you're trying >to use pipes as an IPC with files larger than a megabyte. For instance: >ilbmtoppm blah.iff|ppmquant 256|ppmscale -yscale 1.4|ppmtogif >blah.gif >Hmmm... Let's see, that's 3 megs worth of temp files. Say what? Looks more like 12K-24K of temp storage to me, if you're using one of the more common type of named pipe devices that sports a 4K buffer between input and output streams. While a pipe should really be based on a FIFO rather than a buffer (so you can start reading it as soon as it's created, or at least as soon as the first block is written to it, rather than waiting on the buffer to fill) there's no reason at all why any Amiga pipe device should act like MS-DOS fake pipes and use temporary files. A named pipe is hardly a temporary file. Do you really know of any Amiga pipe device/handlers that wimp out and actually require the whole file to be buffered? > See ya, Ralph -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
daveh@cbmvax.commodore.com (Dave Haynie) (11/08/90)
In article <1990Nov3.073201.8227@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >In <53407.657565922@atronx.UUCP>, Russell McOrmond (rwm@atronx.UUCP) writes: >> In a message posted on 2 Nov 90 09:15:42 GMT, >> pete@violet.berkeley.edu (Pete Goodeve) wrote: > Make an initial stab at a name, perhaps using the middle bits > of the current process address as a basis -- getting 'P!4283' say. Your whole process address, in hex, fits quite easily in a file name, with many more characters left over for additional stuff. >> PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" >> PG>please!) >> What's wrong with that notation? >Just that the "|" character is significant in AmigaDos pattern matching. >I'm not quite sure how you'd be certain of distinguishing its use there from >a pipe request. WShell handles this situation quite easily. If there is whitespace around the "|" character, and it's not quoted, it's a pipe, otherwise it's a file pattern character. I use this alot, and have never found a situation in which it would fail. > -- Pete -- -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/08/90)
In article <6997@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: +In article <1990Nov4.215000.2760@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: +> I really dislike wildcard expansion in the shell. Granted, it would have +> been nicer in 1.3, since there was no library support of standard pattern +> matching, but now that 2.0 has good, standardized routines to do this, I +> can't for the life of me see how shell expansion is superior. + +(a) There are still machines outthere running 1.3. Like, most of them. True, but most utilities that need pattern matching coded it in, and there has always been a standard, even if it wasn't directly supported. Now it is. +(b) You still need quoting conventions. Quickly, how do you delete a file + named "#?.c"? Why not use them consistently? Of course you do -- I never tried to imply that we could get rid of quoting...unless we go to really restricted filenaming, ala DOS. What I would like is a nice, intuitive, consistent system, which would minimize the need for quoting, and make those instances where it is needed clear. I do not think that is the case in the unix shells. +(c) You're at the mercy of programmers who neglect to provide for it. VAX/VMS + has had wildcard libraries forever, and it still trips me up. That's how + you get files named "#?.c" in the first place. Er, I'm not at the mercy of anybody. If a utility should make patterns available (imho), and doesn't, and it is a serious problem to me, I look for a replacement. Really, most of the programs that will need it are filesystem support utilities, which now have it in uniformity. For 1.3, there are replacements for the C: commands that don't implement it. At any rate, the real question was, which is better, not which was more readily available in AmigaDOS. 1.3 had the worst of both worlds -- neither shell nor library expansion. 2.0, I think, has the best. It is up to programmers, if they want their programmers to be flexible and robust, to use them. And there is always the arp.library for 1.3, + +For things like "move", I'd rather go to slices: + + move {.*}.c \1.h Yeah, right. That is much clearer...:-) +Peter da Silva. `-_-' ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
bruce@zuhause.MN.ORG (Bruce Albrecht) (11/08/90)
>In article <6990@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Nov4.150403.28982@cbnewsc.att.com> gregg@cbnewsc.att.com (gregg.g.wonderly) writes: >> I find the UN*X shells' quoting conventions to be quite adequate at >> avoiding the need to require a SPACE anywhere. If you want something which >> contains meta characters to become part of a parameter-word, you quote it. > >The problem is that in this case you have two sets of metacharacters >conflicting at the shell level. Think about the following: > > list lformat=%s #?.c|#?.h | zoo ... > >Now if you quote that: > > list lformat=%s "#?.c|#?.h" | zoo ... > >How does list know whether to expand it or not? What if you're using a shell >that does expansion? A Unix shell would pipe the first example as: list lformat=%s #?.c (pipe) #?.h (pipe) zoo and the second as: list lformat=%s "#?.c|#?.h" (pipe) zoo Generally, the shell knows about the quoting metacharacter, and it takes precedence over the other metacharacters. The backslash is always a single character quote, the quotation mark is always a quotation delimiter unless preceded by a backslash, and other characters are not considered metacharacters when quoted (although I believe some metacharacters for some shells are always metacharacters unless quoted with the backslash). -- bruce@zuhause.mn.org
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/08/90)
In article <2193@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
+Sure, and lets do away with the convention of requiring whitespace between the
+command and arguments, and between argument too. :-)
Okay, okay -- I exaggerated a bit. It's just that I spent my formative years
coding FORTRAN...
+
+Seriously, if it weren't for the ability of Unix shells to accept the pipe
+operator without delimiting whitespace, it would be a complete non-issue.
+Nobody would even think to question it.
What in the world makes you think that? It seems as obvious as any other
evolution that has taken place that allows greater flexibility. I hereby
declare that, even if Unix shells didn't allow whitespace surrounding pipe
symbols, I would have thought of it.
In fact, as I recall, when I first started using pipes, I placed whitespace
around them because it looked right, not because I read about it in the man
pages. I also didn't put whitespace around the symbols when I wanted to
crunch lots onto a line (I have this paranoid thing about real long command
lines), without being told that it was a great `feature' of csh that I could
decide which way I wanted to do it.
Unix is a marvelous invironment, and every modern operating system probably
owes it a bit of homage, but it is not the sacred chalise of All that is
Right and Holy.
+-larry
ken
--
Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-5218
`You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/08/90)
In article <99.273647DB@myamiga.UUCP> smp@myamiga.UUCP (Steve Palm) writes:
+My suggestion is to leave the current wildcard regular expressions alone.
+They are great. Perhaps add * for those out there who can't stomach #?.
Done in 2.0. I think that the pttern matching syntax was augmented a bit,
actually.
+For the pipe, leave it as |. After all, as someone pointed out, overloading
+this regular expression character works splendidly well and doesn't reserve
+yet another character. Besides, I believe that it would be clear when you
+wanted it to be a pipe character and when it was part of an expression.
That's the problem...it isn't always clear, unless you require whitespace
around the | when it is used as a pipe symbol. And even then, what happens
when a filename has a space in it? Hmmmmm, I guess you have to use quotes in
that case (something like: del "(test |test)me" to delete both `testme' and
`test me'), so that's okay. still, it seems less confusing to use a new
symbol.
+ /// AMIGA: | Steve Palm, Sysop of FidoNet node 1:11/16
ken
--
Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-5218
`You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"jesup@cbmvax.commodore.com (Randell Jesup) (11/08/90)
In article <52839.656702476@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: >Yes, we want Un-named Pipes - To use in our own programs as opposed to being >used within a Shell. Actually, what most people seem to want is command-line piping ala csh in unix (command | command | ...). This CAN be done without problems with the current named-pipe handler. All the shell has to do is choose a unique name for the pipe, open it twice, and pass the handles to the commands. That said, don't wait for | piping - there are some thorny issues, particularily in script compatibility. We are providing support for 3rd-party shells to become system-known "User Shells", and they will be used for any user shell interaction, without breaking applications which need to be able to call Execute() and System() with fixed commandlines. Bill Hawes is being the first guinea pig for this. When a shell installs as the default User Shell, NewShell automatically uses it, for example (no hacks needed). The System() call allows the application to specify the Boot Shell, the default User Shell (for things the user wrote), or a specific shell (by name). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
jesup@cbmvax.commodore.com (Randell Jesup) (11/08/90)
In article <53407.657565922@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: >Here's WHY you wish them to be un-named this way you KNOW that the names are >unique: I now do some convaluted task+timer thing to try to make sure I have >a unique name. With the number of times I use it, it's inevidable that the same >name gets used twice. No, unique names are trivial (I used to think we should add a "unique filename" call until this was pointed out to me: Use the current system time (Note: I mean CurrentTime(), not DateStamp().) This is guaranteed to be an increasing number and never return the same exact number. Just convert it to ascii and use it. >PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" >PG>please!) > >What's wrong with that notation? If you don't like that, what do YOU suggest. It conflicts with existing command-line usage - the | is used to separate alternates in pattern-matching. The problem is suddenly a script (let's say an installation script, or a command submitted by Execute() or System()), will suddenly do something unexpected. That doesn't mean 3rd- party shells can't use it for piping. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
pete@violet.berkeley.edu (Pete Goodeve) (11/08/90)
In <15682@cbmvax.commodore.com> (7 Nov), Dave Haynie (daveh@cbmvax.commodore.com) writes: > In article <1990Nov3.073201.8227@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > |> Make an initial stab at a name, perhaps using the middle bits |> of the current process address as a basis -- getting 'P!4283' say. > > Your whole process address, in hex, fits quite easily in a file name, with > many more characters left over for additional stuff. > Yeah, fer shure. In my zeal for generality, I made things more complicated than I need have. The moment I posted it I realized that I should have used hex. The important point though is that, even if you do use the full ID, it is STILL only an "initial stab". A single parent process may want to open several pipes, and will have to generate a new name for each. As Process structures are necessarily spaced fairly well apart, the simplest scheme is probably to start with the address, increment it by 1 for each new pipe, and generate the hex string from that. -- Pete --
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/08/90)
peter@sugar.hackercorp.com (Peter da Silva) writes: >Right, which is why I came up with the idea for a "pipe" command that works >like "run", and will provide piping for all shells and Amigas: >pipe cmd1 args + >cmd2 args + >cmd3 args > >Solves the metacharacter conflict problem nicely. I like the "+" convention, but I'd rather use "-<" and ">-" with it, so that I could say: cmda args -<{1,2} + cmdb args -<{1,2,3} + >-1 cmdc args -<2 + >-2 cmdd args -<4 + >-3 cmde args -<1 + >-4 cmdf args > result and have cheap to type, multiple input, multiple output "named" pipes, with the unlabeled version cmda args -< + >- cmdb args -< + >- cmdc args > result just passing stuff to the next line. This would be a nice syntax for Pete Goodeve's pipe mechanism (which does its interleave synchronization at the message-full level) when he gets the fan-out side working to go along with the fan-in side. The fan-out appearance of "-<" and the fan-in appearance of ">-" give these a nice intuitive appearance, IMHO. Whether the command line processor would be happier if all this started with Peter da Silva's "pipe" verb is up to the implementors; it might be easier for the human reader in any case, especially when trying to decipher someone else's command script. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
peter@sugar.hackercorp.com (Peter da Silva) (11/08/90)
In article <1990Nov6.190147.10534@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: > ls -l usr:big/ole/directory->more (which = ls -l usr:big/ole/dir -> more) So long as you make that: list usr:big/old/directory->more Because making - a metacharacter will break UNIX-style command options. Which is probably a good thing, IMHO... they're usually the result of laziness on the part of the programmer who did the Amiga port. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jap@convex.cl.msu.edu (Joe Porkka) (11/08/90)
jesup@cbmvax.commodore.com (Randell Jesup) writes: $ >In article <53407.657565922@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: $ >>Here's WHY you wish them to be un-named this way you KNOW that the names are $ >>unique: I now do some convaluted task+timer thing to try to make sure I have $ >>a unique name. With the number of times I use it, it's inevidable that the same $ >>name gets used twice. $ > No, unique names are trivial (I used to think we should add a "unique $ >filename" call until this was pointed out to me: Use the current system time $ >(Note: I mean CurrentTime(), not DateStamp().) This is guaranteed to be an This only works if everybody agrees on how to generate unique names. Providing a specific "UniqueName" call would create a standard way. UnqiueName() could simply be a macro if you'd like.
billsey@agora.uucp (Bill Seymour) (11/09/90)
In article <99.273647DB@myamiga.UUCP> smp@myamiga.UUCP (Steve Palm) writes:
:I would never have guessed that such a great amount of bandwith could be taken
:up with such a simple topic as pipes and wildcards... Live and learn...
:
:My suggestion is to leave the current wildcard regular expressions alone.
:They are great. Perhaps add * for those out there who can't stomach #?.
:
:For the pipe, leave it as |. After all, as someone pointed out, overloading
:this regular expression character works splendidly well and doesn't reserve
:yet another character. Besides, I believe that it would be clear when you
:wanted it to be a pipe character and when it was part of an expression.
But if we now reserve | for a pipe, what will I use for an 'OR'? That's
what | is used for now in the AmigaDOS pattern matching... I would be all for
using it in piping, if it hadn't been used before.
BTW, now that we have a 'NOT' (~) in the pattern matching algorythm,
any chance for [a-m,o-z] type patterns?
:--
: /// AMIGA: | Steve Palm, Sysop of FidoNet node 1:11/16
: /// FOR THE | UUCP: {gatech,ames,rutgers}!ncar!asuvax!stjhmc!myamiga!smp
:\\\/// CREATIVE | INTERNET: [not yet available]
: \XX/ MIND |_________________________________________________________
--
-Bill Seymour billsey@agora
***** American People/Link Amiga Zone Hardware Specialist NES*BILL *****
Bejed, Inc. NES, Inc. Northwest Amiga Group At Home Sometimes
(503) 281-8153 (503) 246-9311 (503) 656-7393 BBS (503) 640-0842andy@cbmvax.commodore.com (Andy Finkel) (11/09/90)
In article <1990Nov8.173836.19620@agora.uucp> billsey@agora.uucp (Bill Seymour) writes: > BTW, now that we have a 'NOT' (~) in the pattern matching algorythm, >any chance for [a-m,o-z] type patterns? yes, its in there. Character classes are in there, just the way you want them. > -Bill Seymour billsey@agora andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "It is much easier to suggest solutions when you know nothing about the problem." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/10/90)
In article <7010@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: +In article <1990Nov6.190147.10534@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: +> ls -l usr:big/ole/directory->more (which = ls -l usr:big/ole/dir -> more) + +So long as you make that: + + list usr:big/old/directory->more + +Because making - a metacharacter will break UNIX-style command options. Which +is probably a good thing, IMHO... they're usually the result of laziness on +the part of the programmer who did the Amiga port. Of course, that isn't true. I am not making `-' a metacharacter, I'm making `->' one. The shell will grab the `->' before ls ever sees the commandline, so my example works file. However, because of the great tonnage of utilities out there that use Un*x-style switches (Hm. I guess I refuse to call SOME of them lazy ;), we do need to avoid making `-' by itself special. +Peter da Silva. `-_-' ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/10/90)
In article <3761@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes:
+
+ To each his own, I guess. I much prefer Unix-style command
+options; Amiga-style keywords take us back to the good old days
+of COBOL's reserved words, which are a supreme pain in the butt.
+Why shouldn't I be able to have files called ALL or CLONE, and copy
+them by just saying COPY ALL CLONE without having to worry about
+quoting and other such stuff? Which other file names suddenly
+become "off limits" when someone makes up a new keyword in his
+program? The Unix "-" delimiter is unambiguous, and is easy to
+keep out of file names without getting all bent out of shape.
But, they're `in there' now, and it is pretty unrealistic to hope that they
will ever change.
+ As for pipe characters, my vote is for retaining the Unix "|"
+symbol. I can't think of any compelling reason to make people
+switch to something different. Besides, multi-character operators
+are a pain to parse (but my viewpoint is no doubt prejudiced by
+the amount of programming I do).
Make people change? Nobody's using a pipe character, now! We're talking
about AmigaDOS, not Un*x. Not everyone on the world (and I would hazard a
guess that not even most) comes home from a day at Eir Un*x box, and fires up
Eir AmigaDOS shell. There is no compelling reason that Randell and the
others should try to reshape AmigaDOS in the image of a Un*x shell...
+Charlie_Gibbs@mindlink.UUCP
ken
--
Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-5218
`You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/10/90)
In <1990Nov8.035305.14484@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >+ >+Seriously, if it weren't for the ability of Unix shells to accept the pipe >+operator without delimiting whitespace, it would be a complete non-issue. >+Nobody would even think to question it. > >What in the world makes you think that? It seems as obvious as any other >evolution that has taken place that allows greater flexibility. I hereby >declare that, even if Unix shells didn't allow whitespace surrounding pipe >symbols, I would have thought of it. Seems perfectly natural to me to use whitespace as a delimiter, especially between conceptually diffent parts of a command line. As an 'OR' operator, the '|' 'looks right' without whitespace because it separates two exact patterns, and if those patterns have no embedded spaces, then you don't want them in there. As a pipe operator it looks right (to me) with whitespace because its function is a separate function from whatever exists on either side of it. >In fact, as I recall, when I first started using pipes, I placed whitespace >around them because it looked right, not because I read about it in the man >pages. I also didn't put whitespace around the symbols when I wanted to >crunch lots onto a line (I have this paranoid thing about real long command >lines), without being told that it was a great `feature' of csh that I could >decide which way I wanted to do it. > >Unix is a marvelous invironment, and every modern operating system probably >owes it a bit of homage, but it is not the sacred chalise of All that is >Right and Holy. While I agree that flexibility in whitespace is a boon, I also think that adding yet another character (or combination of characters), to mean 'pipe' is a far more restrictive move than simply saying that the character preceding a pipe character must be a space. I don't think Unix is all right or holy either, and in fact I see a lot of rather severe limitations in various aspects of it that we do not suffer from on the Amiga. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/10/90)
In <1990Nov8.040930.14630@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >That's the problem...it isn't always clear, unless you require whitespace >around the | when it is used as a pipe symbol. And even then, what happens >when a filename has a space in it? Hmmmmm, I guess you have to use quotes in >that case (something like: del "(test |test)me" to delete both `testme' and >`test me'), so that's okay. still, it seems less confusing to use a new >symbol. I regularly use '|' as both a pipe and an 'OR' character on the Amiga, with no confusion at all. I use WShell, Conman, and Bill Hawes' PIP: device. Try it, you'll like it. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/10/90)
In <1990Nov6.190147.10534@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: > >But, I view the pipe symbol (and others like it) as a separator, too. I >realize I'm being picky, here, but I don't see this as an `obvious' place for >whitespace. > >If we use |, and require whitspace, then > >ls -l usr:big/ole/dir|more > >and > >ls -l usr:big/ole/dir | more > >are two completely different fish kettles. Confusion reigns. I like > >ls -l usr:big/ole/directory->more (which = ls -l usr:big/ole/dir -> more) > >much better, and since it builds on previous syntax, I don't think it's >overkill. And you don't see using two characters when one would do as overkill? You don't mind having Yet Another Restriction On Filenames? (yes, I have a few filenames with '->' in them). -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
rhialto@cs.kun.nl (Olaf Seibert) (11/10/90)
In article <1990Nov5.040638.6580@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >In fact the BCPL convention went further than this: the argument part of >the command line was simply left in the input stream for the program to >read; if it wanted it could keep ON reading that stream to get more >arguments -- this is how the '+' mechanism works (or did prior to 2.0 -- >dunno if it does still). > -- Pete -- As I have been peeking though memory, it appears to be some Tripos convention that FileHandles may have some buffer attached to them. The argument line pointer that a CLI process receives simply points into this buffer. Of course, none of this is documented in the DOS manual. Nor should it be, in my opinion. But just for the curious, would it be possible that, when 2.0 has firmly settled, someone reveals the interesting details of the Tripos data structures? Only when it would be of no use to anyone to actually use the provided information? I suspect that there would be some documentation of Tripos, somewhere. Could I get a reference? A copy just might be in our local CS library. -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
pete@violet.berkeley.edu (Pete Goodeve) (11/10/90)
In <1990Nov8.101107.5884@zorch.SF-Bay.ORG>, Kent Paul Dolan (xanthian@zorch.SF-Bay.ORG) writes: > > I like the "+" convention, but I'd rather use "-<" and ">-" with it, so > that I could say: > > cmda args -<{1,2} + > cmdb args -<{1,2,3} + | >-1 cmdc args -<2 + | >-2 cmdd args -<4 + | >-3 cmde args -<1 + | >-4 cmdf args > result > > and have cheap to type, multiple input, multiple output "named" pipes, > [....] > > This would be a nice syntax for Pete Goodeve's pipe mechanism (which > does its interleave synchronization at the message-full level) when he > gets the fan-out side working to go along with the fan-in side. > Hmmm. What an interesting idea... In fact it gets more intriguing as I think on it. "Fan out pipes" are something that even unix can't do, as far as I can see. (You can 'tee' to a pipe and a file, but not to two parallel pipes, can you?) And a convenient way of "broadcasting" data to a number of processes is something that I've had on my mind for a long, long time. Kent's scheme might need a fair amount of "thinking" on the part of the shell -- or 'pipe' program if that was the way it was done (in fact, with the '+' termiator, it could easily be a separate program) -- because several fan-out processes might have to be started. Could be done, though. My immediate intentions ["immediate" - hah! I've just been sitting on it for about three months...] were to make a simple 'ITEE' program, that would take one input (ppipc) stream, and distribute copies of this to as many outputs as you had specified in the command line. I guess you could have the 'pipe' command start copies of this -- or some variant -- as necessary. I've been thinking about the convention that Kent suggests, though, and I wonder if it wouldn't be better to reverse it: PIPE cmda args >-{1,2} + cmdb args >-{1,2,3} + -<1 cmdc args >-2 + -<2 cmdd args >-4 + -<3 cmde args >-1 + -<4 cmdf args > result This isn't much worse (to my eye!) in appearance that the other, but a) it does not conflict with standard redirection direction (:-)), and b) it makes command line parsing MUCH easier, because you're already looking for the '>' redirection character. Special sequences at the BEGINNING of a line are always easy to find. Of course you'd have to avoid file names beginning with '-'... In fact there are LOTS of variants one could consider. I suppose once could make the convention EXACTLY equivalent to the current one, with redirection in the standard AmigaDOS place after the command. Or you might use the pairs '|<' and '>|'. Whatever, it's worth thinking on. -- Pete --
mark.newton@f805.n680.fido.oz.au (Mark Newton) (11/10/90)
Original to: peter@sugar.hackercorp.com Some of C-Shell's metacharacters, namely those concerned with histroy, can be changed through the use of the "histchars" environment variable. Is there any reason why the pipe metachar can't me treated in a similar way under AmigaDos? Then you could use any pipe character you wanted. -mark --- TBBS v2.1/NM * Origin: ADAM, 2,100 MEGS R/W 32 line TBBS call us 08-370-5775 (680/805)
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/11/90)
In article <2203@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: +In <1990Nov6.190147.10534@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: +> +> [my contribution to the pipe symbol debate removed] + +And you don't see using two characters when one would do as overkill? You don't +mind having Yet Another Restriction On Filenames? (yes, I have a few filenames +with '->' in them). Well, no, I don't. We use `>>' for append, and noone is unhappy about that. This, to me, is just another logical extension of the "What to do with my output" symbols. And I think it looks like a pipe, so it won't be hard to remember. And I've tried it out -- it isn't even too hard to type! :-) And, what are you doing with filenames having the redirection symbol in them? Isn't that a rather bad idea? +-larry ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/11/90)
In article <2202@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
+
+I regularly use '|' as both a pipe and an 'OR' character on the Amiga, with no
+confusion at all. I use WShell, Conman, and Bill Hawes' PIP: device. Try it,
+you'll like it.
Except you have to use whitespace around the `|' when it means pipe, right?
Hey, I admit that this is a remarkably minor gripe, but I've developed some
affection for my pipe symbol, and think that it makes good sense in a lot of
ways.
+-larry
ken
--
Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-5218
`You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/11/90)
In article <2201@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: +In <1990Nov8.035305.14484@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: + +Seems perfectly natural to me to use whitespace as a delimiter, especially +between conceptually diffent parts of a command line. As an 'OR' operator, the +'|' 'looks right' without whitespace because it separates two exact patterns, +and if those patterns have no embedded spaces, then you don't want them in +there. As a pipe operator it looks right (to me) with whitespace because its +function is a separate function from whatever exists on either side of it. I agree with most of this, esp. the bit about the or operator. However, it is not so obvious to me that whitespace `should' surround a pipe symbol, in particular if there is no real need to require it, which there would not be if we don't overload the `|' symbol. + +>Unix is a marvelous invironment, and every modern operating system probably ^---did I really do that? Egads! +>owes it a bit of homage, but it is not the sacred chalise of All that is +>Right and Holy. + +While I agree that flexibility in whitespace is a boon, I also think that +adding yet another character (or combination of characters), to mean 'pipe' is +a far more restrictive move than simply saying that the character preceding a +pipe character must be a space. What is restrictive about it? It doesn't limit what you can do in any way that I can fathom. Strictly speaking, it is less restrictive, since one wouldn't have to require whitespace around it. +I don't think Unix is all right or holy either, and in fact I see a lot of +rather severe limitations in various aspects of it that we do not suffer from +on the Amiga. Amen, Brother. +-larry ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
bleys@tronsbox.xei.com (Bill Cavanaugh) (11/11/90)
Ken Yarnell writes: >Make people change? Nobody's using a pipe character, now! We're talking >about AmigaDOS, not Un*x. Not everyone on the world (and I would hazard a >guess that not even most) comes home from a day at Eir Un*x box, and fires up >Eir AmigaDOS shell. There is no compelling reason that Randell and the >others should try to reshape AmigaDOS in the image of a Un*x shell... Many of us DO use a pipe character thanks to Bill Hawes WShell, and many of us DO use UNIX as much as we use the Amiga shell. Why mess with something that works? UNIX and AmigaDOS are the only operating systems I've worked on with the capability to do multitasking on a command line. Why >shouldn't< the command syntax be compatible? I'm confused about this whole argument... The | character works well in WShell for both pipes and logical OR. I've never had a script written by ANYONE that failed with WShell, whether they were using it themselves or not. /**************************************************************** * All of the above copyright by the below. * * Bill Cavanaugh uunet!tronsbox!bleys * * "A language is a dialect with an army and a navy." * ****************************************************************/
peter@sugar.hackercorp.com (Peter da Silva) (11/12/90)
The point of my "pipe" verb is so the command line processor doesn't have to know about it... just like "run". -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (11/12/90)
> +For things like "move", I'd rather go to slices: > + move {.*}.c \1.h In article <1990Nov7.235254.13959@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: > Yeah, right. That is much clearer...:-) OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h with wildcards instead of slices? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/12/90)
In <1990Nov10.230424.29716@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >In article <2203@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >+In <1990Nov6.190147.10534@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >+> >+> [my contribution to the pipe symbol debate removed] >+ >+And you don't see using two characters when one would do as overkill? You don't >+mind having Yet Another Restriction On Filenames? (yes, I have a few filenames >+with '->' in them). > >Well, no, I don't. We use `>>' for append, and noone is unhappy about that. >This, to me, is just another logical extension of the "What to do with my >output" symbols. And I think it looks like a pipe, so it won't be hard to >remember. And I've tried it out -- it isn't even too hard to type! :-) Well, the 'append' is a logical extension of the redirection operator, and is a lot easier to type than any two separate characters. Funny... a '|' looks like a pipe to me. >And, what are you doing with filenames having the redirection symbol in them? >Isn't that a rather bad idea? I forget why they are there, but I had a reason at the time. I dn't see why it would be a bad idea. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/12/90)
In <1990Nov10.230910.29829@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >In article <2202@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >+ >+I regularly use '|' as both a pipe and an 'OR' character on the Amiga, with no >+confusion at all. I use WShell, Conman, and Bill Hawes' PIP: device. Try it, >+you'll like it. > >Except you have to use whitespace around the `|' when it means pipe, right? >Hey, I admit that this is a remarkably minor gripe, but I've developed some >affection for my pipe symbol, and think that it makes good sense in a lot of >ways. Yes, I use whitespace before the pipe, usually after as well, though it isn't necessary. I also use whitespace around the pipe symbol when I use it on a Unix box at work. You know, looked at in another way, the '|' as pipe character can be looked at as a two character sequence consisting of a space followed by a '|'. I just object to changing things for the sake of changing them, and generating other difficulties while we're at it. I think your pipe symbol would mess up the '-' used as command line switch, and possibly mess up the '-' used as 'character sequence' ie. as in [a-z]. It might also mess up the redirection operator ('>'). At any rate, one shell might be written to take care of any of these objections, but most other shell authors might object to messing with their efforts to remain at all close in syntax. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/12/90)
In <7025@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >> +For things like "move", I'd rather go to slices: > >> + move {.*}.c \1.h > >In article <1990Nov7.235254.13959@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >> Yeah, right. That is much clearer...:-) > >OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h >with wildcards instead of slices? Well, it probably _shouldn't work, but I just tried it with a few patterns, and found that this one works fine: mv *.(c|h) old.* That's using the ARP 'move' command. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jesup@cbmvax.commodore.com (Randell Jesup) (11/12/90)
In article <ggk.658869871@tirith.UUCP> ggk@tirith.UUCP (Gregory Kritsch) writes: >rhialto@cs.kun.nl (Olaf Seibert) writes: >>As I have been peeking though memory, it appears to be some Tripos >>convention that FileHandles may have some buffer attached to them. >>The argument line pointer that a CLI process receives simply points >>into this buffer. >So thats what the buffer variables are used for. Does anyone know where >they're interpreted - within Read() or the filesystem's ACTION_READ >code, or by some magical BCPL thing? By buffered I/O calls. These were BCPL-private in <= 1.3, and are public (and greatly extended) in 2.0. >>Of course, none of this is documented in the DOS manual. Nor should it >>be, in my opinion. But just for the curious, would it be possible that, >>when 2.0 has firmly settled, someone reveals the interesting details of >>the Tripos data structures? Only when it would be of no use to anyone to >>actually use the provided information? I'm afraid documenting more than we have to of private internals is liable to force us to allow people muck with them forever to retain compatibility. And, if as you say, it isn't of any use, what good does it do, except to encourage people to tie our hands? >There is a document on BCPL floating around. I had it two years ago, >but it was destroyed in a hard disk error (I think). It documents all >of the dos library, including the BCPL functions and how to call them. >From it, you can explain how some things work in AmigaDOS. That does show some of the internal BCPL global vector routines. However, programs calling them will NOT be supported forever, and NO ONE should write code to use them!!!! It costs us a fair bit of ROM and speed (and maintenance hassle) to support them for old BCPL programs, and at some point it may be dropped (though not soon). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/12/90)
In article <273cfa64-a75.2comp.sys.amiga.tech-1@tronsbox.xei.com> bleys@tronsbox.xei.com (Bill Cavanaugh) writes: + +Ken Yarnell writes: Er, Yarnall. +>Make people change? Nobody's using a pipe character, now! We're talking +>about AmigaDOS, not Un*x. Not everyone on the world (and I would hazard a +>guess that not even most) comes home from a day at Eir Un*x box, and fires up +>Eir AmigaDOS shell. There is no compelling reason that Randell and the +>others should try to reshape AmigaDOS in the image of a Un*x shell... + +Many of us DO use a pipe character thanks to Bill Hawes WShell, and many of +us DO use UNIX as much as we use the Amiga shell. I, for one, probably use csh as much or more than the Amiga Shell. Don't have the pleasure of owning WShell, but I may look into it after I get 2.0, if it offers significant advantages. + Why mess with something +that works? UNIX and AmigaDOS are the only operating systems I've worked on +with the capability to do multitasking on a command line. Why >shouldn't< +the command syntax be compatible? Better question: Why should they be? Actually, the real question is, should the writers of the Amiga Shell feel compelled to mimic Un*x tradition? I don't think it is something that they should worry about. +I'm confused about this whole argument... The | character works well in +WShell for both pipes and logical OR. I've never had a script written by +ANYONE that failed with WShell, whether they were using it themselves or not. What should I say? I just like -> more. I think it would be easier to parse command lines if the syntax were separate (Don't have to worry about the context. Really, given the structure of AmigaDOS, where the Shell doesn't bother with patterns, the shell shouldn't *have* to be worried with whether a symbol is a pattern-matching symbol or not. Just break the command line apart using the redirection symbols, and execute the resulting commands with the resulting arguments, setting the appropriate io streams.), anyway. But you're right; this is getting old. I think I may quit this debate, now, secure in the knowledge that I am, of course, right :-> (and, of course, the pun in the above smiley face is intended ;^) + * Bill Cavanaugh uunet!tronsbox!bleys * ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/12/90)
In article <7025@sugar.hackercorp.com> Peter da Silva writes: +> +For things like "move", I'd rather go to slices: + +> + move {.*}.c \1.h + +In article <1990Nov7.235254.13959@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: +> Yeah, right. That is much clearer...:-) + +OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h +with wildcards instead of slices? Well, this is as quick as I can get :-) First, some honesty: I have never done exactly what you ask, so I didn't know if the way I wanted to do it would work. So, I resolved to try it exactly once, the way I assumed it would work. If that didn't fly, I would admit it. Praise be to Allah, it did ;^) First, I used Arp's copy command. I don't know if C='s 1.3.2 will do this, or not, but the Arp pattern matching library does it just fine. Use the line copy #?.(c|h) old.#? Works like a champ. And this is how I expected it to work! I expect a `#?' in the 2nd expression to resolve to all of the characters in the current filename, which is gotten from the 1st expression. Admittedly, one can construct convoluted examples that won't be doable this way. Come up with a useful one, though, and I'll be impressed... +Peter da Silva. `-_-' ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
pete@violet.berkeley.edu (Pete Goodeve) (11/12/90)
In <7025@sugar.hackercorp.com> (11 Nov), Peter da Silva (peter@sugar.hackercorp.com) writes: > > OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h > with wildcards instead of slices? > -- Ah. You were asking a little while ago what Mat did that was unique. Well (with the aid of a short CLI script) that sort of renaming is EXACTLY one of the things I use it for. (The script is on Fish 374 too.) The syntax -- also showing one of the ways I use '^' -- is: REN whatever.(c|h) old.^F where '^F' in this case means the original filename. If I prefer whatever_OLD.c as the result, I do: REN whatever^.(c|h) ^0_OLD^1 where the '^' in the pattern is the slice point, and ^0 and ^1 are the resulting pieces. -- Pete --
honp9@jetson.uh.edu (Jason L. Tibbitts III) (11/13/90)
In article <1990Nov8.173836.19620@agora.uucp>, billsey@agora.uucp (Bill Seymour) writes: > But if we now reserve | for a pipe, what will I use for an 'OR'? That's > what | is used for now in the AmigaDOS pattern matching... I would be all for > using it in piping, if it hadn't been used before. It is required that the '|' used as logical-or be enclosed with its arguments in parenthesis. In some cases, the usual AmigaDos commands will accept the OR symbol without parenthesis, but this is not consistent with the spec. Do the pattern-matching functions in 2.0 require the parenthesis grouping? > BTW, now that we have a 'NOT' (~) in the pattern matching algorythm, > any chance for [a-m,o-z] type patterns? Not to be cliche or anything, but 'it's in there'. > -Bill Seymour billsey@agora -- \/ Jason L. Tibbitts III // | THEnet: {George|Jane|Elroy|Judy}::HONP9 /\/"Blob Shop Programmers: // | SesquiNet, Telnet, etc: HONP9@JETSON.uh.edu \/ Because We're Bored!" \X/ | CREN (BitNet): HONP9@UHVAX1 "Ewige /\ . DISCLAIMER ." Whose opinions did you think there were?" ; Blumenkraft"
pete@violet.berkeley.edu (Pete Goodeve) (11/13/90)
In <7594.273e8c18@jetson.uh.edu> (12 Nov), Jason L. Tibbitts III (honp9@jetson.uh.edu) writes: > > It is required that the '|' used as logical-or be enclosed with its arguments > in parenthesis. In some cases, the usual AmigaDos commands will accept the OR > symbol without parenthesis, but this is not consistent with the spec. Sorry, but the spec does NOT say that. The '|' simply divides the current character-group into two alternatives, whatever that group may be. Parentheses delimit INNER groups, but the outermost group is just the string itself. So this is perfectly OK: copy thisfile|thatfile|the_other to df0: It's probably worthwhile giving the original reference for the algorithm again (though 2.0 has now extended it considerably): Martin Richards, "A Compact Function for Regular Expression Pattern Matching" [Software--Practice and Experience, vol 9 (1979) 527-534] > > Do the pattern-matching functions in 2.0 require the parenthesis grouping? ... I hope not! -- Pete --
pete@violet.berkeley.edu (Pete Goodeve) (11/13/90)
In <1990Nov12.025436.3189@opusc.csd.scarolina.edu> (12 Nov), Ken Yarnall (yarnall@opusc.csd.scarolina.edu) writes: > In article <7025@sugar.hackercorp.com> Peter da Silva writes: > +OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h > +with wildcards instead of slices? > > Well, this is as quick as I can get :-) > > > First, I used Arp's copy command. [....] > > copy #?.(c|h) old.#? > > Works like a champ. [....] > > Admittedly, one can construct convoluted examples that won't be doable this > way. Come up with a useful one, though, and I'll be impressed... > Well how about this recent one of mine (for which I used my Mat script discussed elsewhere...)? I had been calling my 'IP:' module 'IPHandler' (.c, .o, .lnk etc...) and decided I would prefer 'IP-Handler'. Done on all the files in one step by: REN IP^Hand#? ^0-^1 (Had to edit the makefile and link file by hand, of course, but that was easy.) Not an isolated instance, either. The IP-device fan-out program I'm working on, I tentatively called 'Itee', without liking the name much (a 'tee' is only two way). Now someone has suggested 'mani' (for 'manifold') so I'm about to do: REN itee^#? mani^1 Useful enough? (:-)) -- Pete --
peterk@cbmger.UUCP (Peter Kittel GERMANY) (11/13/90)
In article <1990Nov12.101531.19828@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > >In <7025@sugar.hackercorp.com> (11 Nov), >Peter da Silva (peter@sugar.hackercorp.com) writes: >> >> OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h >> with wildcards instead of slices? >> -- >Ah. You were asking a little while ago what Mat did that was unique. >Well (with the aid of a short CLI script) that sort of renaming is EXACTLY >one of the things I use it for. (The script is on Fish 374 too.) The >syntax -- also showing one of the ways I use '^' -- is: > > REN whatever.(c|h) old.^F > >where '^F' in this case means the original filename. Well, as long as you only want to ADD something to the old filename, then you are done also under 1.3 with the List Lformat feature: LIST >ram:doit whatever.(c|h) lformat="rename %s%s old.%s%s" EXECUTE ram:doit DELETE ram:doit >If I prefer whatever_OLD.c as the result, I do: > > REN whatever^.(c|h) ^0_OLD^1 > >where the '^' in the pattern is the slice point, and ^0 and ^1 are the >resulting pieces. Well, and this one is impossible with the above. But next question: Can you REPLACE parts of the filenames this way? Like: text#?.german --> text#?.english This is the one I would have needed the last weeks several times. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/13/90)
In article <7594.273e8c18@jetson.uh.edu> honp9@jetson.uh.edu (Jason L. Tibbitts III) writes: +In article <1990Nov8.173836.19620@agora.uucp>, billsey@agora.uucp (Bill Seymour) writes: + +> But if we now reserve | for a pipe, what will I use for an 'OR'? That's +> what | is used for now in the AmigaDOS pattern matching... I would be all for +> using it in piping, if it hadn't been used before. + +It is required that the '|' used as logical-or be enclosed with its arguments +in parenthesis. In some cases, the usual AmigaDos commands will accept the OR +symbol without parenthesis, but this is not consistent with the spec. Not true with any spec I've read. +Do the pattern-matching functions in 2.0 require the parenthesis grouping? Definitely not. +> -Bill Seymour billsey@agora ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
dailey@frith.uucp (Chris Dailey) (11/13/90)
In article <3761@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: > As for pipe characters, my vote is for retaining the Unix "|" >symbol. I can't think of any compelling reason to make people >switch to something different. Besides, multi-character operators >are a pain to parse (but my viewpoint is no doubt prejudiced by >the amount of programming I do). I see no reason why a "|" character outside of a quoted string with (one or more) spaces on either side should pose a problem as the pipe indicator. R.E.'s usually don't (can't?) have spaces in them unless in a quoted string, right? For whatever my opinion is worth, I am in agreement with Charlie Gibbs (and at least a few others). >Charlie_Gibbs@mindlink.UUCP >Smash violence! -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu BRD += DDR; DDR = NULL; num_countries --;
peter@sugar.hackercorp.com (Peter da Silva) (11/13/90)
In article <1990Nov12.101531.19828@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > Ah. You were asking a little while ago what Mat did that was unique. ... > REN whatever.(c|h) old.^F > REN whatever^.(c|h) ^0_OLD^1 Oh, yeh. I use "sed" for this on UNIX. It works fine because we have pipes... : ren file... sedcmd FILES= PAT= for i do FILES="$FILES $PAT" PAT=$i done for i in $FILES do mv $i `echo $i | sed "$PAT"` done (now if this was comp.unix Randall Schwartz would jump in at this point with a perl script....) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jesup@cbmvax.commodore.com (Randell Jesup) (11/14/90)
In article <1990Nov13.125723.8271@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >In article <7594.273e8c18@jetson.uh.edu> honp9@jetson.uh.edu (Jason L. Tibbitts III) writes: >+It is required that the '|' used as logical-or be enclosed with its arguments >+in parenthesis. In some cases, the usual AmigaDos commands will accept the OR >+symbol without parenthesis, but this is not consistent with the spec. > >Not true with any spec I've read. > >+Do the pattern-matching functions in 2.0 require the parenthesis grouping? > >Definitely not. Uh, I advise trying it before saying that. A current "bug" in the pattern-match code means that it requires the parens. This may be promoted to a feature if it is sufficiently hard to fix (it's in a very tight, complex, hard-to-modify assembler module). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
pete@violet.berkeley.edu (Pete Goodeve) (11/14/90)
In <570@cbmger.UUCP> (13 Nov), Peter Kittel GERMANY (peterk@cbmger.UUCP) writes: > [.......] > But next question: > Can you REPLACE parts of the filenames this way? Like: > text#?.german --> text#?.english > This is the one I would have needed the last weeks several times. Actually, yes! I posted a similar example yesterday, but for your particular job, I'd use: REN text#?^.german ^0.english (The first '^' is the slice point -- you could have more than one --, and '^0' refers to the first slice.) -- Pete --
honp9@jetson.uh.edu (Jason L. Tibbitts III) (11/14/90)
In article <1990Nov13.125723.8271@opusc.csd.scarolina.edu>, yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: > In article <7594.273e8c18@jetson.uh.edu> honp9@jetson.uh.edu (Jason L. Tibbitts III) writes: > +In article <1990Nov8.173836.19620@agora.uucp>, billsey@agora.uucp (Bill Seymour) writes: > +> But if we now reserve | for a pipe, what will I use for an 'OR'? That's > +> what | is used for now in the AmigaDOS pattern matching... I would be all for > +> using it in piping, if it hadn't been used before. > +It is required that the '|' used as logical-or be enclosed with its arguments > +in parenthesis. In some cases, the usual AmigaDos commands will accept the OR > +symbol without parenthesis, but this is not consistent with the spec. > > Not true with any spec I've read. That's what I get for not R'ing TFM enough. I got the impression that the parentheses were required from a magazine article (in Transactor, I believe.) Unfortunately for me, the DOS gospel according to Bantam seems to say otherwise, and I cant find the article anyway. Oh, well, live and learn. > +> -Bill Seymour billsey@agora > Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU -- \/ Jason L. Tibbitts III // | THEnet: {George|Jane|Elroy|Judy}::HONP9 /\/"Blob Shop Programmers: // | SesquiNet, Telnet, etc: HONP9@JETSON.uh.edu \/ Because We're Bored!" \X/ | CREN (BitNet): HONP9@UHVAX1 "Ewige /\ . DISCLAIMER ." Whose opinions did you think there were?" ; Blumenkraft"
rhialto@cs.kun.nl (Olaf Seibert) (11/14/90)
In article <570@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >Well, as long as you only want to ADD something to the old filename, >then you are done also under 1.3 with the List Lformat feature: > LIST >ram:doit whatever.(c|h) lformat="rename %s%s old.%s%s" > EXECUTE ram:doit > DELETE ram:doit Well, with the ARP Shell you can do this in one step, using a pipe ;-), in the following way: LIST whatever.(c|h) lformat="rename %s%s old.%s%s" | execute >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
ben@epmooch.UUCP (Rev. Ben A. Mesander) (11/15/90)
>In article <7032@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Nov12.101531.19828@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >> Ah. You were asking a little while ago what Mat did that was unique. >... >> REN whatever.(c|h) old.^F >> REN whatever^.(c|h) ^0_OLD^1 > >Oh, yeh. I use "sed" for this on UNIX. It works fine because we have pipes... > >: ren file... sedcmd >FILES= >PAT= >for i >do > FILES="$FILES $PAT" > PAT=$i >done >for i in $FILES >do > mv $i `echo $i | sed "$PAT"` >done To push a belated point, I have the ARP shell, Ash, (ducking from Peter's blow...) and GNU sed on my Amiga. So I can do it either way, and I have pipes (|) that can tell if they are being used in a wildcard pattern or not. Yes, I know that Ash and the ARP commands break some scripts, but it's also possible to create two directories for commands, and assign c: to whichever you like. Personally, I've never met a script that broke with the ARP shell commands. I know, Peter, that you have apparently seen a lot of them. I know of one bug in ASH - it doesn't always expand <$$> the way that I want it to, but the advantages (pipes, better (In my opinion, OK?) regular expressions, less disk space) outweigh any problems I may come across. I've written some pretty hairy scripts to automate my UUCP setup, and have no problems with the ARP commands - but the scripts were written with and for the ARP commands, so that doesn't really count, does it? Compatability? Hell, I don't care, I've got an Amiga 1000! One more thing I'd like to inject into the pipe discussion is that the '+' mechanism is not unique to the 'run' command. You can use it after any command, and it will load the command and wait for you to press enter. Be sure not to break this - I used to use it all the time when all I had was a single-floppy 512K machine. I could do a: dir +<enter> (switch disks) <press enter again> to get a directory of a disk... (I had no docs, and so I didn't know about volume names). Just wanted to point out that + worked in other contexts besides 'run' already. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) (11/15/90)
In article <15839@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: +In article <1990Nov13.125723.8271@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: +>In article <7594.273e8c18@jetson.uh.edu> honp9@jetson.uh.edu (Jason L. Tibbitts III) writes: +> +>+Do the pattern-matching functions in 2.0 require the parenthesis grouping? +> +>Definitely not. + + Uh, I advise trying it before saying that. A current "bug" in the +pattern-match code means that it requires the parens. This may be promoted +to a feature if it is sufficiently hard to fix (it's in a very tight, complex, +hard-to-modify assembler module). erp. I don't have 2.0 (just a lowly 2500/30 here), but the guy down the street does, and I've spent a fair amount of time mucking with his machine. My conclusion-jumping was based on the manual's statements... +Randell Jesup, Keeper of AmigaDos, Commodore Engineering. ken -- Ken Yarnall /// yarnall@usceast.cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-5218 `You'd better tie me up.' -- from the movie, "Tie Me Up, Tie Me Down"
david@twg.com (David S. Herron) (11/15/90)
In article <1990Nov10.082242.22949@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > >In <1990Nov8.101107.5884@zorch.SF-Bay.ORG>, >Kent Paul Dolan (xanthian@zorch.SF-Bay.ORG) writes: [ an interesting idea which I (personally) think looks a bit ugly and daunting to type from the keyboard ..] >Hmmm. What an interesting idea... In fact it gets more intriguing as I >think on it. "Fan out pipes" are something that even unix can't do, as >far as I can see. (You can 'tee' to a pipe and a file, but not to two >parallel pipes, can you?) And a convenient way of "broadcasting" data to a >number of processes is something that I've had on my mind for a long, long >time. Unix has the capability of doing this - all the OS facilities are there it's just that it's hard to represent it in a linear line of text. Since Unix commands (under /bin/{,c,k}sh) are a linear line of text this is a problem. In fact, I vaguely remember seeing a multi-way `tee' program come across some sources group once. Another problem is -- where might this be used? As I said above, the notation you're suggesting is a bit ugly (to my eye). It's not the sort of command I'd be typing in off the top of my head and, besides, I've lived on Unix for years with just linear pipes. The few times where it might've been nice to have tree-structures of piped-together processes has always been in a shell script & it was pretty easy to use temp files of my own & delete them when done. For an ad-hoc creation of tree-structured piles of processes it seemed you'd want some sort of graphical shell in which you'd have process names and pipe symbols that you could drag around & connect up & play around with. cmd1 | ( tee /tmp/some-file; some-other-command </tmp/some-file; rm /tmp/some-file ) | cmd2 Hmm.. that just came to me, and is perfectly reasonable in Unix shell-ese. The string of commands under "some-other-command" would not even start until the "tee" process finishes, then any output it makes would go into `cmd2', _following_ the output of `tee'. Also if you iterate on the () (in Unix shell-ese that starts up a subprocess executing the command string within ()'s) you can create a fairly bizarre nesting of processes. Using `&' and `>' would send some-other-command off into the background so that `cmd2' can finish without having to wait for some-other-command to finish. But toss a few inline awk scripts into that pipeline and it quickly becomes un{read,maintain}able. > PIPE cmda args >-{1,2} + > cmdb args >-{1,2,3} + > -<1 cmdc args >-2 + > -<2 cmdd args >-4 + > -<3 cmde args >-1 + > -<4 cmdf args > result > >This isn't much worse (to my eye!) in appearance that the other, Well.. I guess there's just no pleasing some people. If I'm reading this right you want the input of cmdd to be some combination of the outputs of cmda, cmdb and cmdc. If each of those are executing concurrently how do you avoid mixing the outputs? If you make sure the outputs aren't mixed, how do you specify the order that cmdd see's. Would it be in the order specified in the command, random, or what? ohwell.. so long as unix-ese-speaking shell's are available then I'll be happy ;-).. (And, no, I didn't "grow up" on Unix .. I've used many many other kinds of systems .. I find the notation in Unix shell script-ese (Bourne or Korn shell.. I *emphatically* don't write programs with csh) to be very convenient & powerful.) -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Use the force Wes!
jap@convex.cl.msu.edu (Joe Porkka) (11/16/90)
yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >In article <15839@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >+In article <1990Nov13.125723.8271@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >+>In article <7594.273e8c18@jetson.uh.edu> honp9@jetson.uh.edu (Jason L. Tibbitts III) writes: >+> >+>+Do the pattern-matching functions in 2.0 require the parenthesis grouping? >+> >+>Definitely not. >+ >+ Uh, I advise trying it before saying that. A current "bug" in the Well, here I have a 3000 with 2.0. (ks 36.207) In my C.D. I have a file called "rmfunny.c" and "leak.c" I type ` list rmfunny.c|leak.c' and it says `No imformation for "rmfunny.c|leak.c": object not found' Also I have some files ending in 'c' and in 'p', typeing ' list #?.c|p' lists NO files at all, but ' list #?.(c|p)' DOES work. So, what do you think? Are they required? I think so. Even if not, WHAT IS THE BIG DEAL WITH FORCING SPACES BEFORE (AND/OR AFTER) THE | to indicate pipes? Then there is no problems with parsing, since spaces in filenames are REQUIRED to be in quotes, and the | would be REQUIRED to NOT be enclosed in the quotes with the filename. People who complain about having to type extra spacing probably grew up on BASIC and still like it. Besides sovling the ambiguity problem, spaces make things READABLE.
david@twg.com (David S. Herron) (11/16/90)
In article <7025@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> +For things like "move", I'd rather go to slices: > >> + move {.*}.c \1.h > >In article <1990Nov7.235254.13959@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: >> Yeah, right. That is much clearer...:-) > >OK, quick. How do you rename all whatever.c-or-h files to old.whatever.c-or-h >with wildcards instead of slices? Easy: for f in *.[ch]; do mv $f old.$f done CLUNK! Now changing the `extension' like your example above is harder: for f in *.[ch]; do mv $f `echo $f | sed 's/^\([^\.]*\)\.c$/\1.h/'` done CLUNK CLUNK! And if you like visual feedback add a "echo $f" in there. It may look ugly but at least it's succint ;-)... -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Use the force Wes!
ked01@ccc.amdahl.com (Kim DeVaughn) (11/16/90)
In article <1990Nov10.231801.29933@opusc.csd.scarolina.edu> yarnall@opusc.csd.scarolina.edu (Ken Yarnall) writes: > In article <2201@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > +While I agree that flexibility in whitespace is a boon, I also think that > +adding yet another character (or combination of characters), to mean 'pipe' is > +a far more restrictive move than simply saying that the character preceding a > +pipe character must be a space. > > What is restrictive about it? It doesn't limit what you can do in any way > that I can fathom. Strictly speaking, it is less restrictive, since one > wouldn't have to require whitespace around it. > > +I don't think Unix is all right or holy either, and in fact I see a lot of > +rather severe limitations in various aspects of it that we do not suffer from > +on the Amiga. > > Amen, Brother. > > +-larry Nope ... nothing "right or holy" about any of this kind of stuff. On the other hand, I've always been of the school of thought that says that a computer should be designed to be adaptable to work with *my* work habits. I should not be required to adapt to *its* work habits. IMO, *everything* in the user/machine interface should be programmable. This includes choice of wildcards and other "special symbols", as well as aliases, keymaps, pagers, shells, etc, etc, etc. /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
jap@convex.cl.msu.edu (Joe Porkka) (11/16/90)
ked01@ccc.amdahl.com (Kim DeVaughn) writes: >IMO, *everything* in the user/machine interface should be programmable. This >includes choice of wildcards and other "special symbols", as well as aliases, >keymaps, pagers, shells, etc, etc, etc. >/kim This is great in principle, but it makes it harder to share (or include with applications) things like scripts, since the script can't depend on wildcards, or command syntax. Supposedly with DOS 2.0, you can make replacement shells easier - so to customize things just use the shell of your choice. It is important though to be able to depend on AmigaShell to exist and stuff like wildcards to be the "standard" way.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (11/17/90)
In article <1990Nov15.163126.7290@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: > >Even if not, WHAT IS THE BIG DEAL WITH FORCING SPACES BEFORE (AND/OR AFTER) THE >| to indicate pipes? Then there is no problems with parsing, since spaces >in filenames are REQUIRED to be in quotes, and the | would be >REQUIRED to NOT be enclosed in the quotes with the filename. > >People who complain about having to type extra spacing probably grew >up on BASIC and still like it. Nah, nah. > >Besides sovling the ambiguity problem, spaces make things READABLE. I agree fully, but why do you mention BASIC? I belong to the crowd that used BASIC heavily on our PETs and CBMs and there the parser was so intelligent that you didn't need spaces! Only with the upcome of the "so intelligent" PCs we had to go back to spaces, sigh. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
pete@violet.berkeley.edu (Pete Goodeve) (11/17/90)
[As others have noted, this thread is now worn thin, but one more time for those who don't yet have it in their kill file...] In <8283@gollum.twg.com> (15 Nov), David S. Herron (david@twg.com) writes: > In article <1990Nov10.082242.22949@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: |> [..discussing Kent's suggested multi-way pipe syntax] |> [....] "Fan out pipes" are something that even unix can't do, as |> far as I can see. [.....] > > Unix has the capability of doing this - all the OS facilities are > there it's just that it's hard to represent it in a linear line of > text. Since Unix commands (under /bin/{,c,k}sh) are a linear line > of text this is a problem. [.....] Linear line of text? Tha's funny -- I seem to remember writing a shell script once... (:-)) [Er.. what's a NON-linear line, Teach..? (:-))] Certainly there's nothing in the unix kernel to STOP you doing it, but no shell HAS done it, have they? We were discussing the syntax that a system would need to do such a job, I thought. As to the particular suggested syntax, I think it IS probably rather more complex than it should be. I considered both Kent's and my suggestions as first-cut ones that would need to be hammered on. > > Another problem is -- where might this be used? Any place where you want more than one process to have IMMEDIATE access to data as it is generated. When you're dealing with real-time, this is quite often the case. One of my interests is lab data acquisition and processing, where you might want to both record raw data and process it for display. Then there's things like MIDI, where a single event stream might be patched to several muncher modules. Of more immediate interest is the desire to both display text in a console window and record it in a log file, as well as maybe passing it as data to some other process. > [....] I've lived on Unix for years with just linear pipes. > The few times where it might've been nice to have tree-structures > of piped-together processes has always been in a shell script & it > was pretty easy to use temp files of my own & delete them when done. > [......] > > cmd1 | ( > tee /tmp/some-file; some-other-command </tmp/some-file; rm /tmp/some-file > ) | cmd2 Yes of course temp files can often do the job, but pipes were invented to cover situations where they AREN'T suitable. Like, as I said, where you need the information NOW -- not when the file is closed. And what about never-ending processes generating information to pass on (or, in the fan-out situation, broadcast)?. The other feature of (unix-shell) pipes of course that has been of major concern in this thread is that -- unlike files, temp or otherwise -- they are unnamed; you can run several copies of a script at once, without them interfering with each other. There are more minor advantages to pipes as well, such as the convenience of NOT having to delete them when done. On the other hand, yes, I would only expect complicated pipe-work to appear in scripts -- not in command lines. My own use of pipes in unix (keyboard) commands seldom extends beyond stuff like "ls -l |grep Nov". Maybe once or twice I've had a two stage filter for something, but never more. On the Amiga most of my commands are scripts [Looking back at my currently visible history list, only a single command isn't a script!] and many of these use (named) pipes. Conversely, I have had occasion to redirect keyboard command I/O through pipes but not often. The Amiga environment is not unix [no comments please...]. Of course my concern is not really at all with "The Way Unix Does It", but what new and BETTER things can we do on the Amiga? And even if it's only OCCASIONALLY very useful, that's probably enough... Once a facility is available, you find applications you never would have thought of otherwise. > [Pardon my re-ordering...!!] > For an ad-hoc creation of tree-structured piles of processes it > seemed you'd want some sort of graphical shell in which you'd have > process names and pipe symbols that you could drag around & connect > up & play around with. Ahh, yes indeed. I have my dreams... > > [.....] If I'm reading > this right you want the input of cmdd to be some combination of > the outputs of cmda, cmdb and cmdc. If each of those are executing > concurrently how do you avoid mixing the outputs? [.....] You don't, of course. There wouldn't be much sense in using such a scheme if you had to keep them separate. But there are lots of cases where the problem doesn't arise (or that's exactly what you want!). For a start, the IP: device passes data by packet, so you don't, for instance, get the characters within lines from different sources being munged together. Then often you can be confident of the order in which data is going to be generated, so merging it is safe. As a particular example, suppose you have a program that takes commands and generates outputs, and you want to merge both into a single stream of command/output sequences. Graphically, you have: Commands --->-------------------> Merged Output | | split merge | | >---> Program ---->/ Because the splitter directs its outputs in a specified order, and because the program always produces its output after an interval -- however small -- you know your output sequence will be correct. -- Pete --
pete@violet.berkeley.edu (Pete Goodeve) (11/17/90)
In <8292@gollum.twg.com> (16 Nov), David S. Herron (david@twg.com) writes: > > Now changing the `extension' like your example above is harder: > > for f in *.[ch]; do > mv $f `echo $f | sed 's/^\([^\.]*\)\.c$/\1.h/'` > done > > It may look ugly but at least it's succint ;-)... > Heh heh! ...And this is the guy who was complaining about the PIPE command tentative syntax! (:-)) -- Pete --
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/18/90)
pete@violet.berkeley.edu (Pete Goodeve) writes: [heavily edited] > [As others have noted, this thread is now worn thin, but one more time > for those who don't yet have it in their kill file...] Not to worry, this is a tough problem, being attacked in a tech group where tough problems are the meat and potatos. Besides, see my concurrent post peeling the next layer off the onion to get to the rotten core; it is a _very_ tough problem when addressed in generality. The problem is in part that your and my and da Silva's little digression is mixed among raging arguments about the difficulty of hitting the space bar before the virigule, a problem all sides of which could have been presented in three lines at most. > We were discussing the syntax that a system would need to do such a > job, I thought. Yes, designing a syntax that is reasonably natural, contains relatively few landmines for the unwary, captures the full needed functionality, and is implementable with reasonable effort is a task in and of itself. Actually doing the implementation is another question. > As to the particular suggested syntax, I think it IS probably rather > more complex than it should be. I considered both Kent's and my > suggestions as first-cut ones that would need to be hammered on. Certainly in my case, since I can't implement what I design, I have to get by on my good looks and sweet disposition, which includes being pleasent to folks who didn't like my _perfect_ first draft. ;-) > The other feature of (unix-shell) pipes of course that has been of > major concern in this thread is that -- unlike files, temp or > otherwise -- they are unnamed; you can run several copies of a script > at once, without them interfering with each other. Well, be a bit careful here. In my proposal, and your amendment of it, the pipes were named by the numbers assigned to the output end of each pipe. From the command line, this would name the pipes. If the command were backgrounded and another piping command typed, there would be interference (or interaction, depending whether the results were desired). Given our proposal functioning, it would probably be best if the pipe names were silently prefixed with the current process ID. This would give them "relative names", which would provide the benefits of anonymous pipes being non-conflicting, while retaining the added functionality of tagging pipe ends to help the shell parser match up the correct pieces. An executing shell script, I hope, would have a process ID of its own to assign. This gives away the benefit of the AmigaOS named pipes that can hand data from one CLI window to another. though. Nothing says we can't mix and match; I don't see: PIPE type >-{2,3} some_garbage + type -<2 > pipe:a + type -<3 > * in CLI window 1, and type < pipe:a in CLI window 2 causing horrid problems. Perhaps I'm being naive. > Of course my concern is not really at all with "The Way Unix Does It", > but what new and BETTER things can we do on the Amiga? And even if > it's only OCCASIONALLY very useful, that's probably enough... Once a > facility is available, you find applications you never would have > thought of otherwise. And make a base from which others can build. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/18/90)
david@twg.com (David S. Herron) writes: > pete@violet.berkeley.edu (Pete Goodeve) writes: >> Kent Paul Dolan (xanthian@zorch.SF-Bay.ORG) writes: > [ an interesting idea which I (personally) think looks a bit > ugly and daunting to type from the keyboard ..] Perhaps, but easy and intutitive and solving many problems not currently capable of solution. You haven't seen "ugly" yet; see below. >> Hmmm. What an interesting idea... In fact it gets more intriguing as >> I think on it. "Fan out pipes" are something that even unix can't do, >> as far as I can see. (You can 'tee' to a pipe and a file, but not to >> two parallel pipes, can you?) And a convenient way of "broadcasting" >> data to a number of processes is something that I've had on my mind >> for a long, long time. > Unix has the capability of doing this - all the OS facilities are > there it's just that it's hard to represent it in a linear line of > text. Since Unix commands (under /bin/{,c,k}sh) are a linear line of > text this is a problem. In fact, I vaguely remember seeing a multi-way > `tee' program come across some sources group once. I don't think so. The example, reformatted below, explicitly has a process feeding a prior process, something which doesn't work with tempfiles. I could have included a loop, the notation supports it, but making it anything but an infinite data source then requires knowing the internals of the executing commands, a point I wanted to avoid raising in a first proposal. > Another problem is -- where might this be used? As I said above, the > notation you're suggesting is a bit ugly (to my eye). Anywhere you'd want a complex interconnection of interoperating programs; consider throwing up a half dozen requestors from a half dozen programs to control some multimedia spectacular. This allows them to be tightly coupled without being co-written. > It's not the sort of command I'd be typing in off the top of my head > and, besides, I've lived on Unix for years with just linear pipes. The > few times where it might've been nice to have tree-structures of > piped-together processes has always been in a shell script & it was > pretty easy to use temp files of my own & delete them when done. Except that temp files kill speed, hog space, and are quite inappropriate for the "immortal" processes that run from boot time to boot time in modern multitasking OSs. There was no suggestion that an extremely complex nest of multiple input, multiple output pipes had to be created _literally_ from the command line; like all complex processes, that model would give way in reality often to the scripts you suggest. > For an ad-hoc creation of tree-structured piles of processes it seemed > you'd want some sort of graphical shell in which you'd have process > names and pipe symbols that you could drag around & connect up & play > around with. This is certainly an alternative, and it has been tried several times; the lack of precision, problems of manipulation, and lack of a common agreement on terms and appearances have so far left the efforts mostly research toys. That doesn't lessen the ultimate value of a working "visual pipeboard" solution, but it does suggest that a simpler, shell oriented solution for the shell user has a place. > cmd1 | ( > tee /tmp/some-file; some-other-command </tmp/some-file; rm /tmp/some-file > ) | cmd2 > Hmm.. that just came to me, and is perfectly reasonable in Unix > shell-ese. The string of commands under "some-other-command" would not > even start until the "tee" process finishes, then any output it makes > would go into `cmd2', _following_ the output of `tee'. Also if you > iterate on the () (in Unix shell-ese that starts up a subprocess > executing the command string within ()'s) you can create a fairly > bizarre nesting of processes. Using `&' and `>' would send > some-other-command off into the background so that `cmd2' can finish > without having to wait for some-other-command to finish. But the chance for loops and avoiding temp files would still be missing, as would more crucial mechanisms not yet discussed; see below. I'm also not aware of uses for "&" to mean backgrounding except at line end; this may well be just my ignorance; I can't read most shell scripts I see. > But toss a few inline awk scripts into that pipeline and it quickly > becomes un{read,maintain}able. Hey, this is true of any computer science language you care to name; it hasn't stopped even sed, awk, and APL from being exceptionally useful. >> PIPE cmda args >-{1,2} + >> cmdb args >-{1,2,3} + >> -<1 cmdc args >-2 + >> -<2 cmdd args >-4 + >> -<3 cmde args >-1 + >> -<4 cmdf args > result >> >>This isn't much worse (to my eye!) in appearance that the other, > Well.. I guess there's just no pleasing some people. If I'm reading > this right you want the input of cmdd to be some combination of the > outputs of cmda, cmdb and cmdc. If each of those are executing > concurrently how do you avoid mixing the outputs? If you make sure the > outputs aren't mixed, how do you specify the order that cmdd see's. > Would it be in the order specified in the command, random, or what? More exciting and pertinent was the feed from cmde to cmdc, at least a nontrivial task in the current shells. I was more amazed that no one, in the context of AmigaOS, challenged my coopting of "{}" as metasymbols with the "obvious" meaning. The supposition that Amiga users are not Unix shell users in drag stands disproven, at least for that portion inhabiting USENet. You didn't have my advantage of sitting through Pete Goodeve's presentation of his pipe joiner at BADGE. The trick to keep things as straight as they need to be is that "things" are passed from pipe traffic producer to pipe traffic consumer in packets using AmigaOS's message and reply system. A simple flush() after each meaningful unit by the producer, combined with a sufficiently large pipe packet size, will serve to synchronize the pipe traffic into meaningful chunks for the consumer. >ohwell.. so long as unix-ese-speaking shell's are available then >I'll be happy ;-).. (And, no, I didn't "grow up" on Unix .. I've >used many many other kinds of systems .. I find the notation in >Unix shell script-ese (Bourne or Korn shell.. I *emphatically* >don't write programs with csh) to be very convenient & powerful.) Speaking of power ... ;-). I hadn't yet thrown my real spanner into the works, hoping to let this cud be first digested by the onlookers. The trouble with pipes, even if they contain fan-out and fan-in functionality just outside the bounds of the individual process with the acceptance for further effort of the above work, is that the present notation only usefully support processes that are, at least with respect to piped data, "filters": single input, single output. Filters are not the whole world, and, though tagged packetized data is a way to make a non-filter in concept act like a filter in reality with the addition of a smart fanout with respect to the tags, it would be nice to support the more interesting programs with m-way-data-in, n-way-control-in, o-way-data-out, p-way-control-out, 1-way-messages-out, and 1-way-log-out paths, a more realistic piece of the processing universe. In order to do this in a visual plumbing GUI, you have to have room for lots of "quick disconnect fittings" per process, with label and tags and "keying" to make sure the right pipe hits the right fitting and lots of other complexities that make the problem pretty intractible. It is much less complex to design this functionality into a script shell; you just have to provide a tag corresponding to the file handle for each pipe fitting, the stdin=0, stdout=1, stderr=2 of Unix filter processes the paradigmatic example. I won't claim to have any "non-ugly" ways, or ways that would be fun to type raw as opposed to editing into a script , to do this, but here is one possible example of how it could be done. I _will_ contend that making this possible from a scripting language would be nearly infinitely useful (if for no other reason than that it provides a model for the GUI solution), to allow multitasking support for high speed, low data storage overhead ways to interconnect and tightly couple processes by independent authors. Suppose we have three processes; the first eats a stream of text and a stream of editing commands, and emits the edited text and forward and reverse diff files. The second samples the system clock, times the edit commands and selectively feeds back new commands which vary depending on the time versus space efficiency of the current system load, and writes a log of its work, and a file of the time tagged load averages, to disk. The third does a consistency check of the diff files, feeds a control to the first when problems occur, and appends a join of its log and the second processes log to the input text file. All write any needed error messages to the system console. All run from boot up to shut down. (This is all nonsense created just to have an example, of course.) We will start with Pete's revision of my original proposal; why fight over trivia? However, despite his noting the ease of parsing if the inpipes are to the left, I have returned to the easier to read AmigaOS and Unix form with the command name first, after seeing how intensely ugly it looked the other way with this proposal's increased complexity burying the commands in mid line. Next is a summary of the three processes, providing file handle (fh) assignments, followed by a script entry to spawn and interconnect them. In hopes of making it all viewable on a single screen, vertical whitespace has been omitted, so you might want to single line step your newsreader through the next bit. It exactly fits in 24 lines with "process1:" at the top of the screen. I've made some arbitrary but reasonable guesses at file handles for clock and type. process1: reads text from fh0, editing commands from fh1, and diff control messages from fh2; it writes edited text to fh3, forward diff to fh4, reverse diff to fh5, copies its input commands to fh6, and logs errors to fh7. process2: reads the clock tics from fh0, reads command copies also from fh0 to get the best available times from interleaved messages, monitors process1's error log at fh1, runs at a higher priority than the other two processes, writes edit commands to fh2, writes a log to fh3, writes averages to fh4, and logs errors to fh5. process 3: reads the forward diff from fh0, the backward diff from fh1, and the process2 log from fh2; it writes added input for process1 to fh3, a joined log to fh4 and logs error messages to fh5. PIPE + clock -tic 20 >-6.0 + type -<<1.0 >-3.1 input_text + type -<<2.0 >-4.1 edit_commands + process1 -<3.0 -<4.1 -<5.2 >-.3 edited_text >-8.4 >-9.5 >-6.6 >-{7,11}.7 + changetaskpri 5 + process2 -<6.0 -<7.1 >-2.2 >-{9,12}.3 >-.4 averages >-11.5 + changetaskpri 0 + process3 -<8.0 -<9.1 -<10.2 >-1.3 >-.4 p3log >-11.5 + type -<11.0 >-.1 * + type -<12.0 >-.1 p2log & I _said_ it was ugly! ;-) If it isn't obvious, the m.n format is "pipename.filehandle", where the pipename belongs to the script and not really to the receiving process, but is named at the receiving process command line, and the pipes are (in this case, for tutorial purposes, not out of necessity), numbered sequentially vertically down the screen; while the file handles belong to the process on the same line. Sorry about having the clock output to file handle zero, though. ;-) So, for example, where process1 writes to the tee ">-(7,11}.7", the first half of the tee is being read by process2 at "-<7.1"; the pipename is "7", process1 is also using its filehandle fh7 (".7") (purely coincidence) to write the data, and process2 is usings its filehandle fh1 (".1") to read the data. Note that the next to the last "type" is synchronizing three inputs of the "stderr" outputs of process[123] to the console. Notice the omission of the pipename when input is from or output is to a file, but that the filehandle is still needed, thus several ">-.1 filename"s, for example. [I probably buggered the semantics of changetaskpri in there; do the obvious right thing.] I will freely confess that 1) this was an easy one, a hard one would get messy and require lots of parser working storage to process, 2) it took me over twenty minutes to type this easy one, and 3) I would never think of attempting to type this as a command, but would always make it a shell script, and then probably have to debug that. Nevertheless, it provides the kind of interconnection of processes lacking in Unix and its lookalikes at the command interface level. Lacking such facilities, processes like the above have to be designed and coded as monolithic projects, rather than loose coded and plugged together at the command interface. The seeming ugliness here would remove a much more intense process fork and file handle maintenance ugliness currently rife in the C code of large Unix programming suites. No, I can't write the code to make this work. Daydreaming about it passes the time. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
peter@sugar.hackercorp.com (Peter da Silva) (11/19/90)
Another alternative, ksh syntax. This one requres *named* pipes! mkarcv file $(search "pattern" @(list lformat="%s%s" directory)) all Where the commands are run concurrently and the name or contents of a generated file is inserted where the @(...) or $(...) was. This would do effectively: run list >pipe:temp0001 lformat="%s%s" directory run search >pipe:temp0002 "pattern" pipe:temp0001 mkarcv file (contents of pipe:temp0002 inserted in the line here) So $(...) is (as in ksh) equivalent to the UNIX shell syntax `...`, and the @(...) means (insert pipe name here). The biggest advantage here is that existing Amiga commands will work well without being turned into filters. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
pete@violet.berkeley.edu (Pete Goodeve) (11/19/90)
In <1990Nov18.141954.15308@zorch.SF-Bay.ORG> (18 Nov), Kent Paul Dolan (xanthian@zorch.SF-Bay.ORG) writes: > pete@violet.berkeley.edu (Pete Goodeve) writes: > [heavily edited] > |> [As others have noted, this thread is now worn thin, but one more time |> for those who don't yet have it in their kill file...] > > Not to worry, this is a tough problem, being attacked in a tech group > where tough problems are the meat and potatos. My remark was prompted, I guess, by finding a couple of folks at BADGE last week who had the topic in their kill files. Sorry you weren't there: we could have used the blackboard for some of this...! (:-)) > [.....] |> [unix-style pipes] -- unlike files, temp or |> otherwise -- are unnamed; you can run several copies of a script |> at once, without them interfering with each other. > > Well, be a bit careful here. In my proposal, and your amendment of it, > the pipes were named by the numbers assigned to the output end of each > pipe. From the command line, this would name the pipes. If the command > were backgrounded and another piping command typed, there would be > interference (or interaction, depending whether the results were > desired). Yeah, well there are names and names... I should have made the distinction that file names are GLOBAL in the system; whatever names we use to distinguish pipes within a command group are local to that group. I was simply assuming that your next statement (or something similar) would be the case: > Given our proposal functioning, it would probably be best if > the pipe names were silently prefixed with the current process ID. > [.......] > > This gives away the benefit of the AmigaOS named pipes that can hand data > from one CLI window to another. though. Nothing says we can't mix and > match; I don't see [gives example...] > causing horrid problems. Perhaps I'm being naive. No I don't see any problems at all with this either. I've been assuming that named pipes would be the only way of communicating between SEPARATE "Command Groups" (for want of a better term). [Your concurrent posting, Kent, will take a little longer to digest before I respond. (...say about two weeks! (:-)). Lots more to think about there.] -- Pete --
aduncan@rhea.trl.oz (Allan Duncan) (11/20/90)
From article <570@cbmger.UUCP>, by peterk@cbmger.UUCP (Peter Kittel GERMANY): ... > But next question: > Can you REPLACE parts of the filenames this way? Like: > text#?.german --> text#?.english > This is the one I would have needed the last weeks several times. For this case you just fire up Arp :-) Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
daveh@cbmvax.commodore.com (Dave Haynie) (11/20/90)
In article <579@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1990Nov15.163126.7290@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >>People who complain about having to type extra spacing probably grew >>up on BASIC and still like it. >>Besides sovling the ambiguity problem, spaces make things READABLE. Anyone complaining about spaces should spend a little time with SNOBOL4, in which the space character is often an operator. >I agree fully, but why do you mention BASIC? I belong to the crowd that >used BASIC heavily on our PETs and CBMs and there the parser was so >intelligent that you didn't need spaces! Only with the upcome of the >"so intelligent" PCs we had to go back to spaces, sigh. Actually, it's more like BASIC's parser was so SIMPLE, spaces were not required. For example, it would die in flames on an expression like: FOR FORMULA = LIFE TO DEATH:FRIEND = FRIEND + 1:NEXT The lack of space room was an artifact of the memory savings methods incorporated into these interpreters, and the fact that spaces took up run-time memory and should be avoided when possible. These took precedence over sophistication, and rightly so for the intended job, but they have no place on modern computers with reasonable amounts of memory. >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
peter@sugar.hackercorp.com (Peter da Silva) (12/07/90)
In article <18788@ultima.socs.uts.edu.au> mark.newton@f805.n680.fido.oz.au (Mark Newton) writes: > Some of C-Shell's metacharacters, namely those concerned with histroy, can be > changed through the use of the "histchars" environment variable. (minor irrelevant nitpick, not all Cshells allow this. Sigh) > Is there any reason why the pipe metachar can't me treated in a similar way > under AmigaDos? Then you could use any pipe character you wanted. A good idea, though make it a shell-local variable rather than an environment variable so you can set it in a script without screwing up everything else on the system. Remember, Amiga environment variables are system-global. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
pete@violet.berkeley.edu (Pete Goodeve) (12/09/90)
In <7218@sugar.hackercorp.com> (7 Dec), Peter da Silva (peter@sugar.hackercorp.com) writes: > In article <18788@ultima.socs.uts.edu.au> mark.newton@f805.n680.fido.oz.au (Mark Newton) writes: |> Some of C-Shell's metacharacters, namely those concerned with histroy, can be |> changed through the use of the "histchars" environment variable. |> Is there any reason why the pipe metachar can't me treated in a similar way |> under AmigaDos? Then you could use any pipe character you wanted. -- Another minor nitpick... I thought I already suggested this a couple of weeks back...!(:-)) > > A good idea, though make it a shell-local variable rather than an environment > variable so you can set it in a script without screwing up everything else on > the system. Remember, Amiga environment variables are system-global. I think it would be still better to have BOTH, so that you can let the user set his favourite once and forget it, and still allow scripts their own special preference if they need it. -- Pete --
peter@sugar.hackercorp.com (Peter da Silva) (12/09/90)
In article <1990Dec9.090708.20063@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > > I think it would be still better to have BOTH, I disagree: > so that you can let the user set his favourite once and forget it, Put it in his shell RC file, and then all his interactive shells will have it. That's effectively "global", without breaking scripts: > and still allow scripts their own special preference if they need it. No, batch scripts need to have a standard environment, particularly for things like metacharacters. If you have a global PIPECHAR variable, it needs to be ignored when not in interactive mode. (This is the MOST hosed feature of the C shell on UNIX, that scripts have to deal with whatever wacko stuff a user puts in their .cshrc) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
pete@violet.berkeley.edu (Pete Goodeve) (12/10/90)
In <7238@sugar.hackercorp.com> (9 Dec), Peter da Silva (peter@sugar.hackercorp.com) writes: > In article <1990Dec9.090708.20063@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: |> |> discussing pipe metacharacter selection] > > Put it in his shell RC file, and then all his interactive shells will have > it. That's effectively "global", without breaking scripts: > |> [....] > [No,] batch scripts need to have a standard environment, particularly for things > like metacharacters. > > If you have a global PIPECHAR variable, it needs to be ignored when not in > interactive mode. (This is the MOST hosed feature of the C shell on UNIX, that > scripts have to deal with whatever wacko stuff a user puts in their .cshrc) > -- Mmm, but wait a minute... .rc files SHOULD apply to ALL shells in an environment (and in this case I think unix has it right...(:-)), so scripts would be affected too. If they don't, how do you let scripts use things like aliases? The problem is you have to deal with scripts created by the user for his own convenience, as well as scripts imported from elsewhere. The latter will expect some kind of standard, but I do NOT want to have to remember two conventions -- my own favourite and the "standard" -- one for interaction, and the other for hacking out quick scripts, thank you. I was assuming that a script that needed a particular PIPECHAR would have a line enforcing that, so there would be no confusion. That's what I meant by "BOTH". -- Pete --
peter@sugar.hackercorp.com (Peter da Silva) (12/10/90)
In article <1990Dec10.084228.25707@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > Mmm, but wait a minute... .rc files SHOULD apply to ALL shells in an > environment (and in this case I think unix has it right...(:-)), so > scripts would be affected too. If they don't, how do you let scripts use > things like aliases? You don't. If you want your script to use your aliases then you should explicitly load in the .rc file. Normally scripts shouldn't see aliases. The way you fix this in UNIX is make your .cshrc look like: if ($?prompt) then source ~/.prompt source ~/.aliases set ignoreeof set noclobber set history=21 endif That way all the convenience stuff only gets set for interactive shells. I do system and software support for about 400 people, and a lot of the problems I get are caused by people putting weird shit in their .cshrc. If you MUST have your aliases, load them explicitly. The standard AmigaShell gets this right, as does the UNIX ksh. > I was assuming that a script that needed a particular PIPECHAR would have > a line enforcing that, so there would be no confusion. That's what I > meant by "BOTH". No, the default PIPECHAR for non-interactive shells should be fixed. Because most people don't change it and they'll forget to put the "default" in. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
ggk@tirith.UUCP (Gregory Kritsch) (10/30/20)
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) writes: >>>>>> On 19 Oct 90 23:31:48 GMT, waggoner@dtg.nsc.com (Mark Waggoner) said: >Mark> I don't know if this is quite what you want, but ConMan, the >Mark> console handler by William Hawes can be mounted as a pipe handler and >Mark> may provide what you are looking for. How exactly would you expect a My only comment on this is that it is rather a large amount of code, and not exactly supported either, since CBM has come up with similar functionality elsewhere. >Mark> may provide what you are looking for. How exactly would you expect a >Mark> "true" pipe handler to work, without significant cooperation from the >Mark> shell that is using the pipes. Myself, I desire to be able to implement two functions. I know I can't do this "properly" under 1.3, and I'm not sure about 2.0. Here's the definitions, for the curious. I'd like to know if this IS possible under 2.0, and if anyone can think of anything which can't be done with this definition. (If it can't be done under 2.0, I will eventually kludge it for 1.3 and see if it works with 2.0). BPTR POpen(char *cl, int mode, BPTR stdio) [First, I'm going to avoid some issues, like passing argc and argv, redirecting stderr, and getting rid of BPTRs..., to keep the discussion short and sweet]. This function will create a process and open a pipe to it as either the standard input or output. A file handle to the pipe will be returned. cl - standard command line. Redirection permitted, but only in one direction. mode - read or write mode pipe open. In read mode, the returned file handle will be the readable side of a pipe, and all output from the subprocess directed through Output() will be made available here. In write mode, the writable side of a pipe will be returned, the readable side will be the Input() of the subprocess. stdio - specify the 'other' standard io file. For read mode, this will correspond to the subprocess' Input(). For write mode, this will be the subprocess' Output(). int PClose(BPTR pfh) This function will close a process opened by POpen(). The important detail is that it will WAIT FOR THE COMPLETION AND RETURN THE RESULT of the subprocess. pfh - the file handle (read or write) returned by POpen(). >The PIP: device? As I recall, the ARP shell _did_ use this for real (i.e. >concurrent, no file redirect kludge) pipes. I recall Michael Richardson asking me once if I knew how the conman pip: worked. Neither of us could figure out how to open both ends of the pipe. >Chuck Phillips MS440 >NCR Microelectronics chuck.phillips%ftcollins.ncr.com >2001 Danfield Ct. >Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp -- Gregory Kritsch | University of Waterloo Fido: 1:221/208.11110 [1:163/109.30] | 1A Computer Engineering UUCP: ggk@tirith.UUCP |-------------------------- ...!watmath!xenitec!tirith!ggk | Amiga Fanatic
ggk@tirith.UUCP (Gregory Kritsch) (11/18/20)
rhialto@cs.kun.nl (Olaf Seibert) writes: >As I have been peeking though memory, it appears to be some Tripos >convention that FileHandles may have some buffer attached to them. >The argument line pointer that a CLI process receives simply points >into this buffer. Neato! That explains something weird thats been happening to me recently. I was playing with the Execute() call the other day, and found that calling Execute("",Input(),NULL); would actually create a new CLI, using the same window, the only strange bit being getting a double prompt on the first line. When the user types ENDCLI, control is returned to my program. I went on to try Execute("dmail -O",Input(),NULL); which loaded dmail as expected, and when I exited dmail, I again got the double prompt. So I made dmail's "!" (run shell) function work using the first form, and when I tried it, I got a double prompt, and the message about "Unknown command -O" (ie the argument list for dmail). So thats what the buffer variables are used for. Does anyone know where they're interpreted - within Read() or the filesystem's ACTION_READ code, or by some magical BCPL thing? >Of course, none of this is documented in the DOS manual. Nor should it >be, in my opinion. But just for the curious, would it be possible that, >when 2.0 has firmly settled, someone reveals the interesting details of >the Tripos data structures? Only when it would be of no use to anyone to >actually use the provided information? Almost none of the technical side of DOS is documented, and that which is is documented very poorly. However, there are enough examples floating around so that if you have an urge to experiemnt, you can figure things out. There is a document on BCPL floating around. I had it two years ago, but it was destroyed in a hard disk error (I think). It documents all of the dos library, including the BCPL functions and how to call them. From it, you can explain how some things work in AmigaDOS. The magazine "Kickstart" (from Europe) also did an article on Tripos once upon a time (I've dug it up now - issue 4, aug/sep 86. It appears to be published by Commodore Electronics Ltd and/or Ariadne Software Ltd., both of which are probably Europe-based). Some useful information there to, not covered anywhere else that I know of. >I suspect that there would be some documentation of Tripos, somewhere. >Could I get a reference? A copy just might be in our local CS library. Check with the University of Cambridge - thats where it comes from (and is apparently still in use there). >Olaf 'Rhialto' Seibert rhialto@cs.kun.nl >How can you be so stupid if you're identical to me? -Robert Silverberg -- Gregory Kritsch | University of Waterloo Fido: 1:221/208.11110 [1:163/109.30] | 1A Computer Engineering UUCP: ggk@tirith.UUCP |-------------------------- ...!watmath!xenitec!tirith!ggk | Amiga Fanatic