Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: PIPEs Message-ID: <6991@sugar.hackercorp.com> Date: 5 Nov 90 13:33:34 GMT References: <6977@sugar.hackercorp.com> <1990Nov4.054222.24999@agate.berkeley.edu> <6984@sugar.hackercorp.com> <1990Nov5.040638.6580@agate.berkeley.edu> Reply-To: peter@sugar.hackercorp.com (Peter da Silva) Organization: Sugar Land Unix - Houston Lines: 85 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. `-_-' .