mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (11/19/86)
In article <954@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >I would have thought that a generally implemented facility as pattern >matching would be described in the introductory sections of the manual >instead in the text of the description of a specific command. Nope. Pattern matching is implemented on a per-command basis, not by the cli. Thus, commands may or may not pattern match, or may only pattern match for certain arguments. This is a win. It's not clear that AmigaDOS has the best solution, but at least it's a start. For those who don't think per-argument pattern matching is a win, consider "finger *" and "finger *@*.berkeley.edu". <mike
cc1@locus.ucla.edu (Michael Gersten) (12/01/86)
>For those who don't think per-argument pattern matching is a win, >consider "finger *" and "finger *@*.berkeley.edu". Ok. Whats wrong with finger \*@\*.berkeley.edu or finger "*@*.berkeley.edu" or set noglob finger *@*.berkeley.edu unset noglob ? Pattern matching on all commands is better as then every command has it by default. Try doing a join on the result of running disksalv. Try doing a usercommand *. Try doing a, well, you get the idea. Only the supplied BCPL commands assume that they only have one file name, and that because the supplied CLI won't expand wildcards. I've asked C-A to put multiple filename support in, but I don't think they will. Michael Gersten Views expressed here may not be those of the Computer Club, UCLA, or anyone in their left OR right mind. And that's the name o' that tune.
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/03/86)
In article <3237@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: >>For those who don't think per-argument pattern matching is a win, >>consider "finger *" and "finger *@*.berkeley.edu". > >Ok. Whats wrong with finger \*@\*.berkeley.edu or >finger "*@*.berkeley.edu" or >set noglob >finger *@*.berkeley.edu >unset noglob >? Because none of those do what the command ought to do - run a finger on all the *users* in the apropriate domain. All you've done is turned off the pattern matching, not made it work reasonably well. Worse yet, part of your turning of methods won't work if finger happens to be a shell script. Since it's not uncommon to have shell scripts that invoke other shell scripts, this can get to be a major pain in the ass. Why should I have to know how many levels of shell script are involved in a command when I run it? >Pattern matching on all commands is better as then every command has it >by default. Try doing a join on the result of running disksalv. Try doing >a usercommand *. Try doing a, well, you get the idea. Only the supplied >BCPL commands assume that they only have one file name, and that because >the supplied CLI won't expand wildcards. I've asked C-A to put multiple >filename support in, but I don't think they will. I certainly hope not. It would be better if they fixed the library mechanism (the linkers, maybe?) so you could invoke routines in shared libraries without doing an explicit "openlibrary", then providing the pattern-matching code in a library. They should also provide hooks so you can pattern-match against things other than file names. Then the "user interface design philosophy" should encourage people to expand filenames against the file system, device names against devices (hmm - never tried that. It may work.), font names against fonts, command names againts file in PATH, process names/id's against etc. All of which niceness is impossible/painfull if the shell is expanding names for you. Oh, yeah - many of the supplied BCPL commands work quite well with patterns and multiple file names. I run things against #? quite a bit (search, delete, copy being the most notable ones). Also, there are quite a few PD C programs that only swallow one argument. In any case do you (as a user) really care if the command or the shell does it? If so, why? <mike
mark@ece-csc.UUCP (Mark Lanzo) (12/04/86)
to quote pieces from a couple of previous postings: >For those who don't think per-argument pattern matching is a win, >consider "finger *" and "finger *@*.berkeley.edu". and >Ok. Whats wrong with finger \*@\*.berkeley.edu or >finger "*@*.berkeley.edu" or >set noglob >finger *@*.berkeley.edu >unset noglob >? Well, I agree that the above works, but it sure is a crude way of doing things. Also, the filename expansion et al are supposed to be making the user interface EASIER to work with, and more regular. Suddenly having to add escape codes tends to defeat the purpose -- and is particularly confusing to neophyte users who don't readily understand these intricacies. The Amiga folks really ought to work on making the user interface better and easier to use, not more cryptic. There are lots of rough spots in the CLI interface which really should be improved upon; and in 99% of the cases could be without a great deal of difficulty. Anyways ... An idea: if there are any spare bits in a file's "protection" code (read/write/execute/delete/archive/whatever...), maybe one could be defined as a "Filename expansion" bit. I agree with the crowd wanting the filename expansion to be done automatically by the system since it would contribute greatly to a uniform user interface and makes writing application a good deal easier at the same time. It seems silly to have to include gobs of filename expanding code in every program I write which can accept a filename as an argument (which is probably most programs). Still, it would be nice to be able to disable the filename expansion for a few special programs (such as Unix "finger"). So, what if the system by default expanded filenames on the command line before calling a program, UNLESS some special bit in the file's access code was set? Just a thought .... -- Mark -- flames to /dev/null please!
cmcmanis@sun.uucp (Chuck McManis) (12/05/86)
In article <3135@ece-csc.UUCP> Mark Lanzo writes :
*>I agree with the crowd wanting the filename expansion to be done automatically
*>by the system since it would contribute greatly to a uniform user interface
*>and makes writing application a good deal easier at the same time.
*>It seems silly to have to include gobs of filename expanding code in every
*>program I write which can accept a filename as an argument (which is
*>probably most programs).
The 3.1 version of the lattice compiler has a library routine to do filename
expansion/pattern matching in either AmigaDOS mode (#? etc) or MS-DOS mode
with *.* etc. This at least frees one from having to write gobs of code
but does leave it up to the application to expand it.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.dpz@topaz.RUTGERS.EDU (David P. Zimmerman) (12/06/86)
>>Ok. Whats wrong with finger \*@\*.berkeley.edu or >>finger "*@*.berkeley.edu" or >>set noglob >>finger *@*.berkeley.edu >>unset noglob >>? > >Well, I agree that the above works, but it sure is a crude way of doing >things. Also, the filename expansion et al are supposed to be making the ... >An idea: if there are any spare bits in a file's "protection" >code (read/write/execute/delete/archive/whatever...), maybe one could be >defined as a "Filename expansion" bit. That's an interesting hack, but a hack nonetheless. Lord knows we have enough problems with AmigaDOS without having to introduce hacks into it - leave the file status bits for the status of the file. Of course, now I've got to give my own idea. Make a system call that given a wildcard will return the appropriate expansion. You still have ease of wildcarding for the programmer, and yet also have consistency for the user. No hacks, no muss, no fuss, and a lot less work for the OS, which only has to do expansion when asked to. -dpz- -- David P. Zimmerman "When I'm having fun, the world doesn't exist." Arpa: dpz@rutgers.rutgers.edu Uucp: ...{harvard | seismo | pyramid}!rutgers!dpz
cc1@locus.ucla.edu (Michael Gersten) (12/06/86)
In article <1805@jade.BERKELEY.EDU> you write: >In article <3237@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: >>>For those who don't think per-argument pattern matching is a win, >>>consider "finger *" and "finger *@*.berkeley.edu". >> >>Ok. Whats wrong with finger \*@\*.berkeley.edu or >>finger "*@*.berkeley.edu" or >>set noglob >>finger *@*.berkeley.edu >>unset noglob >>? > >Because none of those do what the command ought to do - run a finger >on all the *users* in the apropriate domain. All you've done is turned >off the pattern matching, not made it work reasonably well. Worse yet, >part of your turning of methods won't work if finger happens to be a >shell script. Since it's not uncommon to have shell scripts that >invoke other shell scripts, this can get to be a major pain in the >ass. Why should I have to know how many levels of shell script are >involved in a command when I run it? What I did was just what you did--namely, pass a *@* to the finger program. If it doesn't know how to handle this, is that my fault? As for shell scripts, I'm not sure I understand the question/complaint. [my comments about the benefit of pattern matching, and using join as an example] >I certainly hope not. It would be better if they fixed the library >mechanism (the linkers, maybe?) so you could invoke routines in shared >libraries without doing an explicit "openlibrary", then providing the ... >Oh, yeah - many of the supplied BCPL commands work quite well with ONLY 4 or 5 BCPL commands work with patterns; list uses a BRAIN-DAMAGED form of matching that can only check the current directory. I feel that the CLI should properly handle *:file (ops, #?:file) things. In fact, I tried doing a DIR #?:, and got a requester for a disk. So, the problem isn't that it should be done, the question is who should do it. As a user, I don't care AS LONG AS ALL COMMANDS DO IT. As a programmer I prefer to have it done for me. As a pesimistic observer, I note that many people won't do it unless it is as simple as 'PatternMatch (argc, argv)'; even then, some still won't. Finally, I *HATE* programs that assume that their first filename is for input, and the second one is output. TYPE is that way. I lost several files that way (do NOT say read the manual; I did, and that was NOT clearly pointed out) Lastly, what do font names/process names have to do with file expansion? Michael Gersten Views expressed here may not be those of the Computer Club, UCLA, or anyone in their left OR right mind. And that's the name o' that tune.
james@uw-atm.UUCP (James M Synge) (12/06/86)
In article <3135@ece-csc.UUCP>, mark@ece-csc.UUCP (Mark Lanzo) writes: > An idea: if there are any spare bits in a file's "protection" > code (read/write/execute/delete/archive/whatever...), maybe one could be > defined as a "Filename expansion" bit. > ... > So, what if the system by default expanded filenames on the command line > before calling a program, UNLESS some special bit in the file's access > code was set? Thats EXACTLY the way it should be done. I use the Primos OS which does things this way. So, if you write a 'normal' program and don't do anything special, the command processor automatically handles wild card expansion (and many other features). The bits can either be in the executable format, or in the file header, as long as there is a standard. -- --------------------------------------------------------------------------- James M Synge @ Dept. of Atmos Sci, U of Washington (@ DEC in NH, January) VOX: 1 206 543 0308 (W) UUCP: uw-beaver!geops!uw-atm!james 1 206 455 2025 (H) ARPA: geops!uw-atm!james@beaver.cs.washington.edu
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/09/86)
In article <7527@topaz.RUTGERS.EDU> dpz@topaz.RUTGERS.EDU (David P. Zimmerman) writes: >>An idea: if there are any spare bits in a file's "protection" >>code (read/write/execute/delete/archive/whatever...), maybe one could be >>defined as a "Filename expansion" bit. > >That's an interesting hack, but a hack nonetheless. Lord knows we >have enough problems with AmigaDOS without having to introduce hacks >into it - leave the file status bits for the status of the file. We looked at doing something like that for Unix. It'd work better for AmigaDOS (since nothing uses the rwx bits yets), but it still suffers from wanting to glob against things other than files. >Of course, now I've got to give my own idea. Make a system call that >given a wildcard will return the appropriate expansion. You still >have ease of wildcarding for the programmer, and yet also have >consistency for the user. No hacks, no muss, no fuss, and a lot less >work for the OS, which only has to do expansion when asked to. Right idea, but not quite done right. The routine belongs in a shared library, not in the OS (with the note that AmigaDOS/C doesn't handle shared libraries well, of course!). Cramming everything into the OS produces things like 4BSD: bloated (Berkeleyphiles don't get upset; V the system isn't any better.) So how about it? Matt, want to convert your.lib into a shared library, and put the regexp code into it? I can even provide PD regexp code. <mike
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/09/86)
Two problems with making MYLIB it a dynamic library: (1) Currently, a library form of MY.LIB would be too unstable in that people using new programs with old libraries will tend to crash their machines rather than get linker errors (2) The library is never complete... I keep adding things to it. (3) Not everybody will have the library. I want to be able to post uuencoded executables that work for everybody. -Matt
page@ulowell.UUCP (Bob Page) (12/10/86)
mwm@eris.BERKELEY.EDU (Mike Meyer) wrote: > ... AmigaDOS (since nothing uses the rwx bits yet) ... Um, don't muck around with these bits, OK? And don't assume that nobody will ever use them, either. And btw, it's rwxd, even though the d is useless if the w is on. >Right idea, but not quite done right. The routine belongs in a shared >library, not in the OS Since this discussion is about shell vs application wildcard expansion, I'll put in my two cents: the shell should do it unless the USER says not to. For the most part, it won't matter either way, but if the shell does it, the interface is CONSISTENT. Escaping the wildcard characters and/or using some magic like `noglob' is acceptable .. use an alias if you use the command like that all the time. (You _are_ using a shell that understand aliases, right?) ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
mwm@eris.UUCP (12/10/86)
In article <839@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >mwm@eris.BERKELEY.EDU (Mike Meyer) wrote: >> ... AmigaDOS (since nothing uses the rwx bits yet) ... > >Um, don't muck around with these bits, OK? And don't assume that >nobody will ever use them, either. And btw, it's rwxd, even though >the d is useless if the w is on. I'm not going to. But that would be the easiest way to testbed the thing. I think that approach is wrong, anyway. >>Right idea, but not quite done right. The routine belongs in a shared >>library, not in the OS > >Since this discussion is about shell vs application wildcard expansion, >I'll put in my two cents: the shell should do it unless the USER says >not to. For the most part, it won't matter either way, but if the >shell does it, the interface is CONSISTENT. Consistent, yes? Best - I don't think so. It forces uglyness on things that want some args globbed, and some not globbed. It also breaks if you use a dd-like interface. >Escaping the wildcard characters and/or using some magic like `noglob' >is acceptable .. use an alias if you use the command like that all >the time. (You _are_ using a shell that understand aliases, right?) I don't think so. Ugly is ugly, and having to explain aliases to even a sophisticated user who's unfamiliar with the system is a pain. Try explaining the VMS alias facility to a Unix wizard, for instance. Also, that STILL doesn't solve the problem of wanting to glob against things other than files. Am I the only one that cares about that? Are the proponents of shell globbing not able to provide an answer? Oh, yeah - there's always the VMS approach. It gives what is by FAR the nicest user interface, but requires the most work for the command installer. Each command has a description of it's arguments hidden in a file somewhere, and the command processor (DCL) checks that. Prompts for missing arguments, globbing against apropriate universes, type-checking on arguments; ALL provided by DCL! Carried to extremes, you even get auto-completion on arguments. Anyone want to do a DCL-like shell for AmigaDOS? :-) <mike
mic@ut-ngp.UUCP (Mic Kaczmarczik) (12/12/86)
has a description of it's arguments hidden in >a file somewhere, and the command processor (DCL) checks that. Prompts >for missing arguments, globbing against apropriate universes, >type-checking on arguments; ALL provided by DCL! Carried to extremes, >you even get auto-completion on arguments. > >Anyone want to do a DCL-like shell for AmigaDOS? :-) > > <mike How about a TOPS-20 EXEC-like shell, with filename expansion, instant help text, and noise words? Although the TOPS-20 approach is similar to VMS, TOPS-20 programs invoke a subroutine library to parse command lines an item at a time. DCL uses a table (stored as an executable image, hint, hint) to parse the command line before the program is even loaded, so the program has no chance to intervene during command parsing. Of course, the programmer has to do even *more* work, so I suppose I could live with table-driven parsing, as long as I could use question mark and command completion :-) There is code in Amiga Kermit to do this sort of thing already, but it would need some work to put it into a shell. If anybody writes a shell like this, PLEASE put as much of the code as you can into reentrant *libraries*, so you don't pay as large a penalty for having more than one shell loaded! That's the reason I'm sticking with the CLI; I just can't see spending 20-40K worth of memory on my poor little 512K system just to run another copy of a shell... --mic--
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/12/86)
In article <3313@curly.ucla-cs.UCLA.EDU> cc1@locus.ucla.edu (Michael Gersten) writes: >What I did was just what you did--namely, pass a *@* to the finger >program. If it doesn't know how to handle this, is that my fault? If it's ok for finger to do it's own pattern matching, why isn't it ok for list, dir, etc. to do their own pattern matching? >As for shell scripts, I'm not sure I understand the question/complaint. Consider a shell script: for i in $* do echo $i done which acts like echo, but puts each word on a seperate line. Now, try convincing it to echo a "*". Notice that your quoting mechanisms don't work right. >ONLY 4 or 5 BCPL commands work with patterns; list uses a BRAIN-DAMAGED >form of matching that can only check the current directory. How many of the rest of them use file names? Does it make sense for them to do pattern matching if they aren't dealing with file names? And you're right, list is brain-damaged. >I feel that the CLI should properly handle *:file (ops, #?:file) things. >In fact, I tried doing a DIR #?:, and got a requester for a disk. Not clear that shell file name expansion should handle assigned names, as they are not part of the file system. On the other hand, if you're doing pattern matching, then it doesn't matter that they're not part of the file systems. Those commands that need to deal with them can. >So, the problem isn't that it should be done, the question is who >should do it. As a user, I don't care AS LONG AS ALL COMMANDS DO IT. Sorry, but as a user, I want the pattern matching to work against the set of objects with the same type as the argument. I don't really care who does it either, but it's going to require some work on the part of the programmer NO MATTER HOW YOU DO IT. >As a programmer I prefer to have it done for me. As a pesimistic >observer, I note that many people won't do it unless it is as simple >as 'PatternMatch (argc, argv)'; even then, some still won't. I'd like to have it done for me, too. But I'd much rather be able to do it right than have the CLI impose an arbitrary mechanism on me. >Finally, I *HATE* programs that assume that their first filename is >for input, and the second one is output. TYPE is that way. I lost >several files that way (do NOT say read the manual; I did, and that >was NOT clearly pointed out) Gee, I didn't have any problem with it. But I'd much rather have something that looked like type <input arguments> outfile=filename with abbrevs (Dillon's shell does abbrevs, at least for built-in command names. Nice going, Matt). That's kind of redundant with shell redirection. Nice for users who don't like the cryptic "type >filename <input arguments>", though. Of course, if the shell is doing file name expansion, then you loose the ability to grab the output name by pattern. >Lastly, what do font names/process names have to do with file expansion? Look at the subject line: it says "Pattern matching", *NOT* file expansion. That's the point - not every command deals with files, and having your command processor act like they do is a crock. Wouldn't it be nice if you could use the exact same regular expressions for commands that dealt with processes (or font names) as you do for commands that deal with files? WITHOUT having to quote them. Or do you find consistency a problem? <mike
wilkes@beatnix..UUCP (John Wilkes) (12/13/86)
In article <4421@ut-ngp.UUCP> mic@ngp.UUCP (Mic Kaczmarczik) writes: [lots of stuff...] >to VMS, TOPS-20 programs invoke a subroutine library to parse command >lines an item at a time. [more stuff] Actually, Tops-20 had a system call (the COMND% JSYS) to handle parsing, not a subroutine library. For my money, this is the best command parser ever invented. I especially like the command recognition and completion features. Filename completion is essential when filenames longer than six or seven characters are allowed. BTW, Tops-20 system calls also understood the wildcard conventions; wildcards are not expanded by the Tops-20 Exec (command parser). I spent a little time trying to convert the Kermit parser to Manx (without success), and I've had fantasies about putting Kermit's Tops-20 parser into an Amiga library or device. I'll do that in my abundant spare time, I guess ;-). -- John Wilkes -- UUCP: {ihnp4|decwrl|pyramid}!sun!elxsi!beatnix!wilkes USPS: ELXSI, 2334 Lundy Pl., San Jose CA 95131 # My Employer appologizes for the fact that I have access to the network. # Furthermore, my Employer has absolutely no responsibility for the above # random ramblings, which are clearly the product of a deranged mind.
vanam@pttesac.UUCP (Marnix van Ammers) (12/14/86)
In article <1908@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >In article <3313@curly.ucla-cs.UCLA.EDU> cc1@locus.ucla.edu (Michael Gersten) writes: >>As for shell scripts, I'm not sure I understand the question/complaint. > >Consider a shell script: > > for i in $* > do > echo $i > done > >which acts like echo, but puts each word on a seperate line. Now, try >convincing it to echo a "*". Notice that your quoting mechanisms don't >work right. Maybe I don't understand exactly what you're trying to do, but it seems to work just fine here (I'm running on Sys V release 2 unix) if I type 'echo "*"', the system echoes an asterisk. All I have to do is quote it. If I want to pass a '*' on the command line, I also quote it. If I want to pass a quoted '*' on the command line, then I quote the quote with a backslash as in '\*'. In any case, to put in my 2 cents, I want to see the CLI do consistent file name expansion. I don't want each individual program to do it in it's own way. I don't have any problems with file name expansion with the unix shell, and I don't see why I would with my Amiga.
mic@ut-ngp.UUCP (Mic Kaczmarczik) (12/15/86)
pproach to the TOPS-20 approach. You're right, it's a system call, but my point was that the program itself can invoke COMND%, instead of waking up and asking what DCL parsed from its static table, which I think puts more flexibility into the programmer's hands. Sorry for the lack of precision. --mic--
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/16/86)
In article <357@pttesac.UUCP> vanam@pttesac.UUCP (-Root Admin-) writes: >In article <1908@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >>In article <3313@curly.ucla-cs.UCLA.EDU> cc1@locus.ucla.edu (Michael Gersten) writes: >>>As for shell scripts, I'm not sure I understand the question/complaint. >> >>Consider a shell script: >> >> for i in $* >> do >> echo $i >> done >> >>which acts like echo, but puts each word on a seperate line. Now, try >>convincing it to echo a "*". Notice that your quoting mechanisms don't >>work right. > >Maybe I don't understand exactly what you're trying to do, but it seems >to work just fine here (I'm running on Sys V release 2 unix) if I type >'echo "*"', the system echoes an asterisk. All I have to do is quote it. You're right, you don't understand what I'm trying to do. Watch: Script started on Tue Dec 16 02:48:11 1986 eris% cat > lecho for i in $* do echo $i done ^D eris% chmod 777 lecho eris% lecho this is a test this is a test eris% lecho * bin dead.article lecho news root services src things.to.do tmp typescript eris% lecho \* bin dead.article lecho news root services src things.to.do tmp typescript eris% lecho '*' bin dead.article lecho news root services src things.to.do tmp typescript eris% lecho \\* No match. eris% lecho '\*' \* eris% lecho \\\* \* eris% ^D script done on Tue Dec 16 02:49:15 1986 [Enter extreme sarcasm mode.] So explain why the nice, clean, consistent file expansion breaks for the command lecho (_l_ine echo)? Geez, I thought quoting always worked. [Exit extreme sarcasm mode.] Ok? Can you propose a fix? I can - two of them. Both have been mentioned here by me and others. 1) Tag each command as to whether it should have file names expanded. Unwieldy for a number of reasons, previously explained. 2) Allow each command to do it's own pattern matching. We've hashed this over already, but I'll talk about it more later [collective groan and lot's of 'n' keys being hit, I'm sure.]. >If I want to pass a '*' on the command line, I also quote it. If I want >to pass a quoted '*' on the command line, then I quote the quote >with a backslash as in '\*'. Except, as demonstrated above, it doesn't always work. >In any case, to put in my 2 cents, I want to see the CLI do consistent >file name expansion. I don't want each individual program to do it in >it's own way. I don't have any problems with file name expansion with >the unix shell, and I don't see why I would with my Amiga. I see far to many problems with Unix file name expansions, and they've caused the shell to get bigger and uglier since Unix v6. And all the problems *still* haven't been solved. I don't want to see the AmigaDOS CLI start down this road!!!! A good solution will have the following properties: 1) All commands accept the same regular expressions for patterns. 2) If it doesn't make sense to have more than one word for an argument, that argument is NOT patterned matched. 3) Each argument is pattern matched against all objects with the same "type" as the argument, if it's pattern matched at all. There are two ways to do this. 1) Provide a library of routines to do the pattern matching. By making this a shared library, you can tweak the syntax of the regular expressions on your system, and it will work for EVERY command the same way. The problem is, you have to convince programmers to use this facility. 2) Provide a CLI that knows about what the arguments to a command are, and does the right thing. This still requires someone to do the work of describing the arguments, but allows the user to do it. A good CLI on these lines could make the Unix shells look like they were straightjackets when it comes to flexibility. A super version of this could be a TWENEX-like CLI, as described by mic@ngp.utexas.edu (haven't ever used tops-20/twenex, so I forgot about it; you're right, mic - it'd be a lot nicer than VMeSs.) Look, even Matt Dillon doesn't want the CLI to expand file names. He's truly pegged it: if you really don't like it, write your own shell (I've written a few for Unix; it's not hard). Leave the CLI small so that people running different shells don't have to pay for features they don't need from it. If you really feel unable to write your own shell, either buy one that's on the market, or get one of the (three? four? more?) PD ones that's floating around. <mike
hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/16/86)
In article <1908@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >Consider a shell script: > > for i in $* > do > echo $i > done > >which acts like echo, but puts each word on a seperate line. Now, try >convincing it to echo a "*". Notice that your quoting mechanisms don't >work right. consider this perhaps instead (sorry)... #! /bin/sh for i in $@ do echo $i done $@ is "$1" "$2" ... $* is $1 $2 ... this is just another important piece in the quoting mechanism, which is a detail that can not be left out. - -- Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu Fig is a 5 stage concept.
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/17/86)
In article <2306@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >In article <1908@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >> for i in $* >> do >> echo $i >> done >consider this perhaps instead (sorry)... > >#! /bin/sh >for i in $@ >do > echo $i >done > >$@ is "$1" "$2" ... >$* is $1 $2 ... Hmm - not quite. It should be "$@", not just plain $@. $@ (unqouted) is identical to $* (unquoted). "$@" is what you described $@ as, whereas "$*" is "$1 $2 $3 ... ". In either case, it *STILL* doesn't work. If you feed your version an unquoted '*', then the shell that I'm typing at (to invoke the command script) will expand the '*'. If I quote it once (any of '*', "*" or \*), then the shell strips off one level of quotes, which feeds it to the for loop as "*", which feeds it to the echo as an unquoted '*', where it gets expanded by the shell into a list of file names. Note: We've just gotten baroque enough so that differences between shells will start to show up, which is why I didn't mention the $@ mechanism before. ksh vs. SysV sh vs BSD sh vs earlier shells can (and probably will) do different things. I should have expected someone would know about $@, but not know that it still doesn't work, and just started there. Of course, my apologies if your shell actually does the right thing, and let me know which version of Unix you're running. To top it off, the $@ mechanism hands back "" if you invoke the script without any arguments. Makes for interesting things, especially if one of the commands involved is a cd (anyone want to guess what a 'cd ""' does? :-) I hope the above provides sufficient proof that the Unix shell file expansion mechanism is *NOT* simple, no matter what it may look like to the casual user. <mike
news@cit-vax.Caltech.Edu (Usenet netnews) (12/18/86)
Organization : California Institute of Technology Keywords: shell scripts From: tim@tomcat.Caltech.Edu (Tim Kay) Path: tomcat!tim mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >vanam@pttesac.UUCP (-Root Admin-) writes: >>mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >>>cc1@locus.ucla.edu (Michael Gersten) writes: >>>>As for shell scripts, I'm not sure I understand the question/complaint. >>>Consider a shell script: >>> for i in $* >>> do >>> echo $i >>> done >>>which acts like echo, but puts each word on a seperate line. Now, try >>>convincing it to echo a "*". Notice that your quoting mechanisms don't >>>work right. >> >>Maybe I don't understand exactly what you're trying to do, but it seems >>to work just fine here (I'm running on Sys V release 2 unix) if I type >>'echo "*"', the system echoes an asterisk. All I have to do is quote it. > >You're right, you don't understand what I'm trying to do. Watch: > [demonstration deleted] But, if you write the lecho shell script as for i in "$@" do echo "$i" done it does the following tomcat% lecho tomcat% lecho hello, world hello, world tomcat% lecho * 3d 640k int.pas lecho printer shell t.pas tex typescript wow tomcat% lecho \* * tomcat% lecho "*" * So, the quoting mechanism under Unix *works*. It isn't all that difficult to prove (literally) that you can do anything you want. NEVERTHELESS. I don't like nor remember nor understand all the features of the quoting mechanism under Unix, and I think that each program should expand its own arguments. A shell should be kept very small. Timothy L. Kay tim@csvax.caltech.edu Department of Computer Science Caltech, 256-80 Pasadena, CA 91125
news@cit-vax.Caltech.Edu (Usenet netnews) (12/18/86)
Organization : California Institute of Technology Keywords: From: tim@tomcat.Caltech.Edu (Tim Kay) Path: tomcat!tim mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >To top it off, the $@ mechanism hands back "" if you invoke the script >without any arguments. Makes for interesting things, especially if one >of the commands involved is a cd (anyone want to guess what a 'cd ""' >does? :-) I previously posted a "working" version of lecho. Note that when it is fed no arguments, a blank line is produced. 'cd ""' does different things under Sys V than under 4.2. Under Sys V, "" is an invalid filename, so you get "No such file or directory". Under 4.2, the filename "" is the same as ".", so you cd to the current directory (a no-op). Timothy L. Kay tim@csvax.caltech.edu Department of Computer Science Caltech, 256-80 Pasadena, CA 91125
Lear@ru-red.UUCP (Eliot Lear) (12/18/86)
I would like to point out that several emulators for the TOPS-20 cmnd jsys have been written for unix and I imagine it would not be terribly hard to port them to the Amiga. The cmnd jsys was the system call that gave you all that noise, completion, and wildcard expansion. I will investigate further if any one is interested. As a side note to us -20 fanatics, from what I understand, someone wrote an entire Jsys emulation package in order to MM, the niftiest mail subsystem I've ever seen. ...eliot
michael@stb.UUCP (Michael) (12/29/86)
In article <1908@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: > In article <3313@curly.ucla-cs.UCLA.EDU> cc1@locus.ucla.edu (Michael Gersten) writes: > >What I did was just what you did--namely, pass a *@* to the finger > >program. If it doesn't know how to handle this, is that my fault? > > If it's ok for finger to do it's own pattern matching, why isn't it ok > for list, dir, etc. to do their own pattern matching? > One moment. If you are talking about a program that is designed to work with something that the CLI cannot possibly see, then the command can pattern match. If you are working with something that the CLI can see, then the CLI should expand it. > >As for shell scripts, I'm not sure I understand the question/complaint. > > Consider a shell script: > > for i in $* > do > echo $i > done > > which acts like echo, but puts each word on a seperate line. Now, try > convincing it to echo a "*". Notice that your quoting mechanisms don't > work right. Very simple. set noglob foreach i ($*) echo $i end That does it, no? > > >ONLY 4 or 5 BCPL commands work with patterns; list uses a BRAIN-DAMAGED > >form of matching that can only check the current directory. > > How many of the rest of them use file names? Does it make sense for > them to do pattern matching if they aren't dealing with file names? > And you're right, list is brain-damaged. Here is a quick look at c: and the programs that use files: Assign AddBuffers CD Copy delete diskchange echo ed edit execute fastdir filenote info install join list makedir 'newcli from' path relable search run sort type Z (manx editor) > > >I feel that the CLI should properly handle *:file (ops, #?:file) things. > >In fact, I tried doing a DIR #?:, and got a requester for a disk. > > Not clear that shell file name expansion should handle assigned names, > as they are not part of the file system. On the other hand, if you're > doing pattern matching, then it doesn't matter that they're not part > of the file systems. Those commands that need to deal with them can. > On the contrary, they are part of the file system. AmigaDos recognizes them, does it not? Next thing you know, you'll claim nil: is not part of the file system. Would you claim that /dev/null is not part of the file system? [comments about the ease of having the shell do it vs. the desire for odd programs to do it their own way] > >Finally, I *HATE* programs that assume that their first filename is > >for input, and the second one is output. TYPE is that way. I lost > >several files that way (do NOT say read the manual; I did, and that > >was NOT clearly pointed out) > > Gee, I didn't have any problem with it. But I'd much rather have something > that looked like > > type <input arguments> outfile=filename > > Of course, if the shell is doing file > name expansion, then you loose the ability to grab the output name by > pattern. > Oh yea? What about cat *.c > exist* where there exists a file called existensialistic_programming_fun > >Lastly, what do font names/process names have to do with file expansion? > > Look at the subject line: it says "Pattern matching", *NOT* file > expansion. That's the point - not every command deals with files, and > having your command processor act like they do is a crock. Wouldn't it > be nice if you could use the exact same regular expressions for > commands that dealt with processes (or font names) as you do for > commands that deal with files? WITHOUT having to quote them. Or do you > find consistency a problem? > > <mike OK, Now I understand what you are driving at. But here is one major question for you: How will you do it? At some point, you have to have a routine that takes ARGV, ARGC, and a list for pattern matching. How are you going to do it so that it can easily do file, font, library, device, message ports, active tasks, etc, etc, etc. For anything based on an exec node list, its not hard. But not everything is. Michael. -- Michael Gersten ihnp4!ucla-cs!cepu!ucla-an!remsit!stb!michael "But you can't go to war for not liking the same jokes" "Why not? It's as good a reason as any other"
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (01/01/87)
In article <825@stb.UUCP> michael@stb.UUCP (Michael) writes: >One moment. If you are talking about a program that is designed to work with >something that the CLI cannot possibly see, then the command can pattern match. > >If you are working with something that the CLI can see, then the CLI should >expand it. Uh, if a program can see the names, why can't the CLI see them? After all, it's just a program. More importantly, how is the CLI supposed to know what it should or shouldn't expand, and what that expansion should be against? [Good old shell scripts again!] >Very simple. > set noglob > foreach i ($*) > echo $i > end > >That does it, no? Very nice - much better than the "$@" solutions, as those don't work on all shells. Of course, in either case you have to depend on the programmer who wrote the script to do it correctly. Experience tells me that neither AT&T nor Berkeley will always get it right. >> >ONLY 4 or 5 BCPL commands work with patterns; list uses a BRAIN-DAMAGED >> >form of matching that can only check the current directory. >> >> How many of the rest of them use file names? Does it make sense for >> them to do pattern matching if they aren't dealing with file names? >> And you're right, list is brain-damaged. > >Here is a quick look at c: and the programs that use files: >Assign >AddBuffers >CD >Copy delete diskchange echo ed edit execute fastdir >filenote info install join list makedir 'newcli from' >path relable search run sort type Z (manx editor) I disagree - many of them deal with devices, not files. Part of them aren't standard utilities. Echo doesn't deal with files, just words. If you delete these things you have left: assign CD delete ed edit execute filenote join list makedir newcli path search run sort copy type In addition, assign, cd, execute, newcli, and run only deal with one file, and it only makes sense for them to deal with one file. They should complete, not pattern match. I don't know if ed and edit deal with multiple files, so I'm going to assume they don't (add two further on if they do but don't pattern match.) Makedir and filenote don't accept multiple files, but should. Sort and type have the broken from/to semantics. Path, search and join should do pattern matching, but don't. List does patterns (brokenly), delete, copy and search do patterns correctly. In summary: 7 commands for which multiple arguments don't make sense; 2 for which they do, but don't support them; three with bogus semantics; three that don't support pattern matching but should, and three that do things right. Or 10 for which it can be argued that things are done right, six for which things are done wrong. You really thing unix does that much better? I suspect that over half the commands have arguments that don't deal with files, which makes their command line handling (as far as I'm concerned) wrong. >> >I feel that the CLI should properly handle *:file (ops, #?:file) things. >> >In fact, I tried doing a DIR #?:, and got a requester for a disk. >> >> Not clear that shell file name expansion should handle assigned names, >> as they are not part of the file system. On the other hand, if you're >> doing pattern matching, then it doesn't matter that they're not part >> of the file systems. Those commands that need to deal with them can. >> >On the contrary, they are part of the file system. AmigaDos recognizes them, >does it not? Next thing you know, you'll claim nil: is not part of the file >system. Would you claim that /dev/null is not part of the file system? It appears that one of the really nice features of Unix has confused you. You see, /dev/null is TWO things. Firstly, it's part of the Unix file system; or more accurately, it's in the Unix file system namespace. It can be any arbitrary file. I can put data in it, take it back out, grep for things in it, and have it all work; like so - Script started on Wed Dec 31 23:42:50 1986 eris# file /dev/null /dev/null: character special (3/2) eris# mv /dev/null /dev/save.me eris# echo hello > /dev/null eris# cat /dev/null hello eris# rm /dev/null eris# mv /dev/save.me /dev/null eris# file /dev/null /dev/null: character special (3/2) eris# ^D script done on Wed Dec 31 23:43:38 1986 On the other hand, the file named /dev/null *BY CONVENTION* points to a trivial device. The ability to have arbitrary filenames point to arbitrary devices is a major win for Unix. AmigaDOS isn't so nice, device names are magic; they aren't files, they are DEVICES. To see the difference, try listing par:. Or how about copying df0: to a single file in RAM:? Odd, it won't do it. Unix does reasonable things for both of these attempts. So I just made your prediction come true; nil: isn't part of the file system. It's part of the OS, so of course AmigaDOS recognizes it. Symbolic names that point to a directory are something else again. A nice feature (that Unix ought to have, and done better than VMS), but they confuse the issue. >> Gee, I didn't have any problem with it. But I'd much rather have something >> that looked like >> >> type <input arguments> outfile=filename >> >> Of course, if the shell is doing file >> name expansion, then you loose the ability to grab the output name by >> pattern. > >Oh yea? What about >cat *.c > exist* Sorry, but "> exists*" is NOT "outfile=filename". One is short and cryptic, the other nice and readable. Done right, you'd input "o=fi*" (or something similar) in the second case, but could write it out longhand for scripts (where readability can be important). [A description of pattern matching versus filename expansion] >OK, Now I understand what you are driving at. But here is one major question >for you: > >How will you do it? >At some point, you have to have a routine that takes ARGV, ARGC, and a list >for pattern matching. How are you going to do it so that it can easily >do file, font, library, device, message ports, active tasks, etc, etc, etc. Well, there are a couple of ways. One would be to provide a single subroutine that took three arguments: argv, argc and a description of what the arguments should look like (that last may take more than one argument; possibly varargs code needs to be used). It could either twiddle argc and argv (which would violate the ANSI standard) or you could call it multiple times (try "man 3 getopt" to see what I mean). Other library combinations are possible. However, I've decided that the shell should do it, based on command description files. The main reason for this is that it gives the user LOTS of power in tailoring the interface. I've just realized that you could still do it in a library and give the user that power. On Unix, the result would (almost certainly) be an ugly hook to find the correct description file. AmigaDOS might work better though. Have to go think about it. >For anything based on an exec node list, its not hard. But not everything is. Not much harder than doing file expansion. The hard part in every case is getting a list of all the objects in the "universe." And any of the above approaches means that it only has to be done once (barring reinventing the wheel). The shell description I've mentioned that talks about all this (among other things) has been written. I realized that it would be suitable for publication in SIGSmall/SIGPC, and wrote it for that. I'm going to be uploading the result in the next day or two, and will post a draft here. <mike
cc1@locus.ucla.edu (Michael Gersten) (01/03/87)
(Posting from ucla because stb isn't receiving news during the holidays) > = Mike Myers >> = Me >>One moment. If you are talking about a program that is designed to work with >>something that the CLI cannot possibly see, then the command can pattern match. >> >>If you are working with something that the CLI can see, then the CLI should >>expand it. > >Uh, if a program can see the names, why can't the CLI see them? After >all, it's just a program. More importantly, how is the CLI supposed to >know what it should or shouldn't expand, and what that expansion >should be against? Very simple: it doesn't, and can't. However, files should be matched against files, fonts against fonts, etc. But, the CLI can't tell what it is, or can it? It can guess, i.e. foreach type (type-list) foreach arg (arg-list) match (type, arg) end end or something similar. The problem: A. Different people would want different orders in type-list B. Different people would want different things in type-list C. Some things may be hard to put into type-list >[Good old shell scripts again!] >>Very simple. >> set noglob >> foreach i ($*) >> echo $i >> end >> >>That does it, no? > >Very nice - much better than the "$@" solutions, as those don't work >on all shells. Of course, in either case you have to depend on the >programmer who wrote the script to do it correctly. Experience tells >me that neither AT&T nor Berkeley will always get it right. I agree, and Microsoft and SCO aren't much better. >>Here is a quick look at c: and the programs that use files: >>Assign >>AddBuffers >>CD >>Copy delete diskchange echo ed edit execute fastdir >>filenote info install join list makedir 'newcli from' >>path relable search run sort type Z (manx editor) > >I disagree - many of them deal with devices, not files. Part of them >aren't standard utilities. Echo doesn't deal with files, just words. Here we have some disagrements. I feel that ANY time a program deals with files, it should be expanded, even if it is only one file (like CD). As for non-standard, thats only Z and fastdir. Besides, echo does deal with filenames--on Unix, I use it as a fast ls to see if a file exists. >If you delete these things you have left: >assign CD delete ed edit execute filenote join >list makedir newcli path search run sort copy type > ... >further on if they do but don't pattern match.) Makedir and filenote >don't accept multiple files, but should. Sort and type have the >broken from/to semantics. Path, search and join should do pattern >matching, but don't. List does patterns (brokenly), delete, copy and >search do patterns correctly. > >In summary: 7 commands for which multiple arguments don't make sense; >2 for which they do, but don't support them; three with bogus 3 with bogus semantics. Thats one STRONG reason for this stuff to be in a common subroutine library or by the shell. >semantics; three that don't support pattern matching but should, and >three that do things right. Or 10 for which it can be argued that >things are done right, six for which things are done wrong. > >You really thing unix does that much better? I suspect that over half >the commands have arguments that don't deal with files, which makes >their command line handling (as far as I'm concerned) wrong. Hmm.. I can't think of a command for which the file-name expansion hurts me. Mail and history are a different problem (bang bang) [discussion of devices/disk names, should they be expanded] >>On the contrary, they are part of the file system. AmigaDos recognizes them, >>does it not? Next thing you know, you'll claim nil: is not part of the file >>system. Would you claim that /dev/null is not part of the file system? >It appears that one of the really nice features of Unix has confused >you. You see, /dev/null is TWO things. Firstly, it's part of the Unix >file system; or more accurately, it's in the Unix file system >namespace. It can be any arbitrary file. I can put data in it, take it >back out, grep for things in it, and have it all work; like so - [example of using /dev/null to refer to something else] >On the other hand, the file named /dev/null *BY CONVENTION* points to >a trivial device. The ability to have arbitrary filenames point to >arbitrary devices is a major win for Unix. > >AmigaDOS isn't so nice, device names are magic; they aren't files, >they are DEVICES. To see the difference, try listing par:. Or how >about copying df0: to a single file in RAM:? Odd, it won't do it. >Unix does reasonable things for both of these attempts. Well, lets see. I can mount arbitrary device handlers with arbitrary Dos device names, but I can't unmount. So, the only restrictions are that I can't avoid the colon at the end, and I can't change a name once gdven. As for copying df0: to ram:, or TYPE DF0: TO DF1:, or something: I belive this is a fault of the BCPL programs doing checks that they shouldn't be checking. If I am wrong, *** BUG REPORT *** And it REALLY should be fixed for 1.3 (speaking of which, I've found about 4 bugs in 1.2 so far. Will send them out in a week if no others show up) >So I just made your prediction come true; nil: isn't part of the file >system. It's part of the OS, so of course AmigaDOS recognizes it. >Symbolic names that point to a directory are something else again. A >nice feature (that Unix ought to have, and done better than VMS), but >they confuse the issue. > Actually, I think they should be FULLY integrated, and if they aren't, blame Dos; if they are, blame the BCPL programs. >> >>Oh yea? What about >>cat *.c > exist* > >Sorry, but "> exists*" is NOT "outfile=filename". One is short and >cryptic, the other nice and readable. Done right, you'd input "o=fi*" >(or something similar) in the second case, but could write it out >longhand for scripts (where readability can be important). I don't know about you, but I HATE outfile=x type things. Absolutely HATE. DO NOT put that into amiga dos. Religious fight up ahead 8<) Besides, quoting > is easy: \> or '>'. Quoting 'outfile=file*' is not as easy, and you have to get it to expand and then ignore the outfile= part. [Comment about how to do file expansion] Well, we both agree that the shell should do it. We both agree that it should be user configurable. Soon, we'll have something we both hate equally--that will be it. Michael Gersten Best reply: backbone!ucla-cs!cepu!ucla-an!remsit!stb!michael scgvaxd!stb!michael is not reliable right now Views expressed here may not be those of the Computer Club, UCLA, or anyone in their left OR right mind. And that's the name o' that tune.
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (01/07/87)
In article <3549@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: >> = Mike Myers Uh, since I'm Mike Meyer (not plural, and add an e), and I said these things, I think I'll correct the attribution. >>Uh, if a program can see the names, why can't the CLI see them? After >>all, it's just a program. More importantly, how is the CLI supposed to >>know what it should or shouldn't expand, and what that expansion >>should be against? > >Very simple: it doesn't, and can't. However, files should be matched >against files, fonts against fonts, etc. But, the CLI can't tell what >it is, or can it? It can guess, i.e. It can if it's told what they are. See the article I posted a couple of days ago that's a draft of "A Shell for Modern Personal Computers," which describes one way of doing just that. >A. Different people would want different orders in type-list >B. Different people would want different things in type-list >C. Some things may be hard to put into type-list The above paper does it a different way, which avoids these problems. >>Very nice - much better than the "$@" solutions, as those don't work >>on all shells. Of course, in either case you have to depend on the >>programmer who wrote the script to do it correctly. Experience tells >>me that neither AT&T nor Berkeley will always get it right. > >I agree, and Microsoft and SCO aren't much better. MicroShaft and SCO are selling AT&T software (either V or III, nowadays. I don't think anyone is still selling v7), so chances are you are seeing AT&T bugs. My experiences with MicroShaft are such that I'd expect them to introduce a whole new set of bugs without fixing any of the old ones. [End obligatory large software vendor bashing.] >Here we have some disagrements. I feel that ANY time a program deals >with files, it should be expanded, even if it is only one file >(like CD). As for non-standard, thats only Z and fastdir. >Besides, echo does deal with filenames--on Unix, I use it as a fast >ls to see if a file exists. I've used that trick before, but that's a kludge. Ls is nicer, and nearly as fast on well-run systems. With only ONE argument, I'd much rather have completion. If you can get to a 4.3 system, do "set filec", and then try typing escapes in the middle of file names. If you can't do that, get a copy of microGNUEmacs, and play with typing spaces at prompts for buffer and command names. >3 with bogus semantics. Thats one STRONG reason for this stuff to >be in a common subroutine library or by the shell. It's even better to put it where the user can play with it. See the above-mentioned posting. >>You really thing unix does that much better? I suspect that over half >>the commands have arguments that don't deal with files, which makes >>their command line handling (as far as I'm concerned) wrong. > >Hmm.. I can't think of a command for which the file-name expansion >hurts me. Mail and history are a different problem (bang bang) Almost every time I use sed, I have to go out of my way to quote the arguments. Without filename expansion, this wouldn't be a problem. Other expansion tricks hurt other programs. Of course, you probably do what I do, and make sure things never have the magic characters in them. We have odd restrictions on the names in our CMS system because of oddities in the Unix shell! >>AmigaDOS isn't so nice, device names are magic; they aren't files, >>they are DEVICES. To see the difference, try listing par:. Or how >>about copying df0: to a single file in RAM:? Odd, it won't do it. >>Unix does reasonable things for both of these attempts. > >Well, lets see. I can mount arbitrary device handlers with arbitrary >Dos device names, but I can't unmount. So, the only restrictions are that >I can't avoid the colon at the end, and I can't change a name once >gdven. Huh? You mean you can create a device gort/foo: ??? How about gort/my_foo:, then do a "list gort" to see the devices in it. I think not, but could be wrong (never had a reason to do anything THAT bizarre). >As for copying df0: to ram:, or TYPE DF0: TO DF1:, or something: >I belive this is a fault of the BCPL programs doing checks that they >shouldn't be checking. If I am wrong, > >*** BUG REPORT *** I don't think it's a bug report - I think it's confusion on your part. Have you ever worked with a large system which had similar features (TOPS-10, VMS, and probably others)? On those systems, devices (and system logicals) ARE NOT part of the file name space. Then again, they tend to have ugly three-part file names: device, followed by a magic character; a directory path, with magic characters at both ends, and finally a file name. Probably split into a name and an extension, with a magic character seperating. Compared to such kludgyness, AmigaDOS is nice Of course, you still have to deal with the problem of "list par:" saying "packet request type unknown". Or is that a bug, also? >Actually, I think they should be FULLY integrated, and if they aren't, >blame Dos; if they are, blame the BCPL programs. I tend to think they aren't fully integrated, and think that DOS should be blamed. But it's hard to blame the designers: they did that work before Unix really became popular, and the way they did it was the way almost everyone else was doing it back then. "Blame it on TRIPOS." >I don't know about you, but I HATE outfile=x type things. Absolutely HATE. >DO NOT put that into amiga dos. Religious fight up ahead 8<) > >Besides, quoting > is easy: \> or '>'. Quoting 'outfile=file*' is not >as easy, and you have to get it to expand and then ignore the outfile= part. You don't have to quote it if the command is doing the expanding instead of the shell. You seem to have ignored the possibility of it being shortend to o=fi*, also. And o= isn't noticable harder to type than > (to key presses, either way, on the Amiga keyboard). Of course, the shell can do all of this for you. See the afore-mentioned posting for details. >Well, we both agree that the shell should do it. We both agree that >it should be user configurable. Soon, we'll have something we both >hate equally--that will be it. Yes, but we got to the shell doing it via totally different paths. You started wanting a dumb shell, ala Unix, that just expands everything. I started wanting more intelligent handling of arguments. Making that user-configurable pushes things from the command to the command processor. See the much-mentioned paper to see where that leads you, and how FAR that is from a dumb "file-expand-every-argument" shell. If that posting hasn't gotten to you by the time you see this, something probably broke. Please let me know. <mike