mjl@ut-emx.UUCP (Maurice LeBrun) (03/11/89)
A topic rises from the grave.. The postings on Unix vs Amigados path-names and wildcard characters in the last month have been very interesting. From observing the various arguments I came up with the following results: wildcards winner: Unix pathnames winner: a toss up, tie-breaker going to Unix although I am not completely unbiased in this regard (but fairly close, I figure, since I didn't know much about Unix before my Amiga, actually learning a fair amount *about* Unix from my Amiga; I was amazed at the similarities). I too am a bit ambivalent about the pathnames, but would rather the Unix style be supported. As far as wildcards go, the #? symbol is irritating and the following is an atrocity: 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) Funny thing is, it reminds me of the directory specification in VMS, which I also hate (ouch! those brackets), despite having used it for years. Sure, you say, it's just a little extra typing with some characters that are hardly ever used in ordinary text, NO BIG DEAL! :-) Well, user interface *is* important, especially for people who use a computer often (read: *users*, not just programmers). Unix compatibility may be important, no? Somewhere I must have missed it, did anyone scream this several hundred times, and I just missed it? I don't want *all of Unix* especially, but I'd like something a bit closer than at present. I don't give a **** about device drivers, for example. The average user (maybe I'm above-average :-) deals only with the OS at a fairly high level -- certainly a better effort to be more Unix-like at this level can be made (without going with all of it). BTW, I was a fanatical Matt Dillon Shell fan (thanks Matt! [is this a cliche by now?]) but eventually switched to Conman/WShell/ARexx. I'm almost completely happy, but still not quite. Then again, maybe none of you really exist. Maurice LeBrun | "So then I says to Borg, `You know, Institute for Fusion Studies | as long as we're under siege, one of us University of Texas at Austin | oughta moon these Saxon dogs.'" Internet: | mjl@fusion.ph.utexas.edu | (Far Side)
jac@ssibbs.UUCP (James Crotinger) (03/12/89)
In article <11135@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) writes: [stuff about unix vs. amigados...] > > Unix compatibility may be important, no? Somewhere I must have missed > it, did anyone scream this several hundred times, and I just missed it? > > I don't want *all of Unix* especially, but I'd like something a bit > closer than at present. I don't give a **** about device drivers, for > example. The average user (maybe I'm above-average :-) deals only > with the OS at a fairly high level -- certainly a better effort to be > more Unix-like at this level can be made (without going with all of it). > I agree. I don't particularly want UNIX on my Amiga. But I would like to have the UNIX commands that I'm getting used to using on other machines. Maurice and I work on some machines at Livermore which run an OS called CTSS (Cray Time Sharing System). Generally, it sucks big time. But in the last couple of years they've been moving towards "UNIX compliance". They've added a hierarchical file system (yes, they really didn't have one before!), a big complement of UNIX commands in all the natural places, UNIX style file protection, links, etc. Now they're on the final leg, and are adding system calls which will make the system look more like UNIX from a programmers point of view. I'd like to see AmigaDOS move in a similar direction. I don't want AMIX. But I would like to have a similar working environment across the various machines I have to use. > > Maurice LeBrun | "So then I says to Borg, `You know, > Institute for Fusion Studies | as long as we're under siege, one of us > University of Texas at Austin | oughta moon these Saxon dogs.'" > Internet: | > mjl@fusion.ph.utexas.edu | (Far Side) Jim -- Jim Crotinger crotinger%mit.mfenet@nmfecc.arpa
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (03/12/89)
In article <11135@ut-emx.UUCP> mjl@ut-emx.UUCP (Maurice LeBrun) writes: >The postings on Unix vs Amigados path-names and wildcard characters in >the last month have been very interesting. From observing the various >arguments I came up with the following results: >wildcards winner: Unix [deleted stuff] > As far as wildcards go, the #? symbol is >irritating and the following is an atrocity: > >1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) The problem is not that #? is inferior, but that it is not implmented fully. I hope that CBM makes an arrangement with the ARP people and puts the Pattern-Matching and FindFirst/FindNext routines in a library that is part of the standard distribution [after fixing the bugs:-)]. If we had character classes, people would stop complaining about #?. It seems absurd because the # by itself has no real meaning right now. I go into contortions in nameing my files because I can't use character classes. If one had them, you will come to agree that #? is logical. There is nothing wrong with `cp *.c *.h t:'. On the other hand there is nothing wrong with `copy #?.c #?.h to t:' either, except that it is not implemented. [I just discovered that the ARP copy will not do what I expected. Why? It is trivial to add this functionality when you have arp.library and its `MULTIARGS' stuff.] -- It is the man, not the method, that Nath solves the problem. vkr@osupyr.mast.ohio-state.edu -Poincare. (614)-366-9341
daveh@cbmvax.UUCP (Dave Haynie) (03/14/89)
in article <11135@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: > Keywords: Amigados unix filesystem > A topic rises from the grave.. > I too am a bit ambivalent about the pathnames, but would rather the > Unix style be supported. As far as wildcards go, the #? symbol is > irritating and the following is an atrocity: #? is actually two symbols. You can use them separately. UNIX is redundant in having both * and ?, and it's missing a "#" equivalent, isn't it. And how would you succinctly state: Delete #?(.cp|.h|%) in UNIX-ese? > 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) That's a detail of the AmigaDOS copy program, not the wild card system. That you can express the equivalent of the UNIX cp program using Amiga wild cards is a example of their power. If you don't like the Amiga copy command syntax: Copy file1 file2/directory rather than the UNIX syntax: cp file1 file2 cp file1 ... [fileN]] directory then you should complain about the command, not the wildcards. > Funny thing is, it reminds me of the directory specification in VMS, > which I also hate (ouch! those brackets), despite having used it for > years. I hate VMS brackets too. I think all forms of intelligent life feel the same way. The "(" ")" in AmigaDOS isn't at all related. The UNIX analog in wild card construction is "[" "]". > Unix compatibility may be important, no? Somewhere I must have missed > it, did anyone scream this several hundred times, and I just missed it? UNIX compatibility is important in UNIX systems, not VMS, MS-DOS, Amiga, or Apollo systems, each of which uses somewhat different wild card conventions. UNIX and Amiga wild cards are significantly more powerful than VMS or MS-DOS. Apollo Aegis wild cards are just plain weird, though on very simple level look like a UNIX/Amiga hybrid. > Maurice LeBrun | "So then I says to Borg, `You know, -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
jwright@atanasoff.cs.iastate.edu (Jim Wright) (03/14/89)
In article <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: |in article <11135@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: |> | Delete #?(.cp|.h|%) Is "%" a literal character in this context or is it a pattern matching specification? I think much, if not most, of the perceived problems with AmigaDOS wildcards comes from the fact that a lot of people already know Unix (or even MSDOS) wildcards, but AmigaDOS ones don't *seem* to be well documented to for the average user. It's hard to use them without knowing them. |> 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) | |That's a detail of the AmigaDOS copy program, not the wild card system. Which leads to what I consider the other half of the problem. Making use of the full wildcarding system should be trivially simple for programmers. If it were easy to get at, everyone would use it. Sounds like a great candidate for library routines to me. |Apollo Aegis wild cards are just plain weird, though |on very simple level look like a UNIX/Amiga hybrid. Confirmed member, Aegis-bashers anonymous. :-) |> Maurice LeBrun | "So then I says to Borg, `You know, |Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" | {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy -- Jim Wright jwright@atanasoff.cs.iastate.edu
gore@eecs.nwu.edu (Jacob Gore) (03/14/89)
/ comp.sys.amiga / daveh@cbmvax.UUCP (Dave Haynie) / Mar 13, 1989 / >And how would you succinctly state: > > Delete #?(.cp|.h|%) > >in UNIX-ese? rm *{.cp,.h,%} > > 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) > > That's a detail of the AmigaDOS copy program, not the wild card system. Interesting that you should mention that. In Unix, it would be a detail of the shell, not the program. Unix commands do not have consistent option specifications, but they ARE consistent, as the user sees them, when it comes to wildcards. This, of course, is because most of them don't deal with wildcards at all, because they know the shell is there to do it for them. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
monty@sagpd1.UUCP (Monty Saine) (03/14/89)
in article Message-ID: <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) says:
<UNIX compatibility is important in UNIX systems, not VMS, MS-DOS, Amiga,
^^^^^^^^^^^^^^^^^^^^ ^^^^^
Are we forgetting that Unix and Amiga are merging with the 2500UX ?
It seems to me that we should be working towards a closer user commonality
with UNIX if we are now supporting a UNIX port on the Amiga. It will be a
real pain to have one system with two different sets of wild cards based
on how you boot it up.
Just my two cents worth
Monty
********************************************************************************
" All side effects are effects."
" We can never do merely one thing."
" --First Law of Ecology"
********************************************************************************daveh@cbmvax.UUCP (Dave Haynie) (03/15/89)
in article <876@atanasoff.cs.iastate.edu>, jwright@atanasoff.cs.iastate.edu (Jim Wright) says: > In article <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > | Delete #?(.cp|.h|%) > Is "%" a literal character in this context or is it a pattern > matching specification? Well, it was a silly example, but "%" matches the empty set. Which of course, in that example, would expand to: Delete #?.cp #?.h #? But hopefully everyone gets the idea. > ...AmigaDOS ones don't *seem* to be well documented to for > the average user. It's hard to use them without knowing them. That is true, or at least it used to be back in the A1000 days, when you didn't get an AmigaDOS manual at all with the system. It also appears to me that many folks out there don't do anything more sophisticated with wild cards than what you can do in UNIX with "*" and "?". That does mean you might get a little be less frustrated switching over to VMS or MS-DOS, but really LIKE to have powerful wild cards. I really use alternation, etc, all the time. Even for folks who don't want anything more than "*" and "?", if you can't mentally substitute "#?" for "*", you're either just being stubborn or you probably don't won't know what to do with anything more sophisticated than MS-DOS anyway, so why bother with an Amiga. > Which leads to what I consider the other half of the problem. > Making use of the full wildcarding system should be trivially > simple for programmers. If it were easy to get at, everyone > would use it. Sounds like a great candidate for library routines > to me. I don't think you'll get much argument on that one. A standard library routine would make all pattern matching consistent, and extend it's use throughout the system, such as in file requesters. > |Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > Jim Wright > jwright@atanasoff.cs.iastate.edu -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
daveh@cbmvax.UUCP (Dave Haynie) (03/15/89)
in article <10260015@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) says: > / comp.sys.amiga / daveh@cbmvax.UUCP (Dave Haynie) / Mar 13, 1989 / >>And how would you succinctly state: >> Delete #?(.cp|.h|%) >>in UNIX-ese? > rm *{.cp,.h,%} In AmigaDOS, "%" matches the NULL character. Which, of course, made the above example reduce to "Delete #?", which wasn't what I had intended. I figured you could do it in UNIX pretty closely, which is exactly my point. Try it in VMS or MS-DOS.... >> > 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) >> That's a detail of the AmigaDOS copy program, not the wild card system. > Interesting that you should mention that. In Unix, it would be a detail of > the shell, not the program. Not really. In UNIX, _pattern matching_ is done by the shell, true. But it is still up to a program to decide how the expanded parameters passed by the shell will be interpreted. Some Amiga shells also expand patterns for the command, but if that commands isn't written to handle more than one file, you're SOL. UNIX "cp" must have to knowledge to copy files argv[1] through argv[argc-2] to directory argv[argc-1]. AmigaDOS "Copy" doesn't do this, and that's the main difference here. > Unix commands do not have consistent option specifications, but they ARE > consistent, as the user sees them, when it comes to wildcards. This, of > course, is because most of them don't deal with wildcards at all, because > they know the shell is there to do it for them. That part is true. As long as wild card expansion is available as a standard library call, it's not much matter who does the expansion; there are minor advantages to both methods, and you can always choose the shell that suits you. On the Amiga, it makes as much sense to have consistent pattern matching in file requesters and other similar places. We need this function as a standard library call. > Jacob Gore Gore@EECS.NWU.Edu > Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (03/15/89)
From article <6235@cbmvax.UUCP>, by daveh@cbmvax.UUCP (Dave Haynie): > [discussion of AmigaDOS versus Unix wild card styles deleted.] > That's a detail of the AmigaDOS copy program, not the wild card system. I think this is the real problem with the way AmigaDOS handles wild cards. Instead of building the pattern matching code into each command I'd like to see filename patterns expanded by the shell, as in Unix. The shell would then pass the appropriate arguments to the commands, providing the user with a standard, consistent way to specify a filename pattern for every command. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
daveh@cbmvax.UUCP (Dave Haynie) (03/16/89)
in article <352@sagpd1.UUCP>, monty@sagpd1.UUCP (Monty Saine) says: > in article Message-ID: <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) says: > <UNIX compatibility is important in UNIX systems, not VMS, MS-DOS, Amiga, > ^^^^^^^^^^^^^^^^^^^^ ^^^^^ > Are we forgetting that Unix and Amiga are merging with the 2500UX ? > It seems to me that we should be working towards a closer user commonality > with UNIX if we are now supporting a UNIX port on the Amiga. It will be a > real pain to have one system with two different sets of wild cards based > on how you boot it up. Well, so far today, I've worked on system running AmigaDOS, VAX/VMS, UNIX, and Aegis. Each system has it's own commands, it's own file name conventions, it's own directory naming conventions, and it's own wildcard system. It's really no big deal to move between such differences. Even if I had a way to make UNIX, VMS, and Aegis respect Amiga wildcards, I'd still have to rename the command set, rework the directory naming conventions, and of course the file naming conventions. Personally, I'd rather learn the operating system I'm currently using then try to redesign the stupid thing. If there's a real problem with a particular aspect of the OS (for instance, AmigaDOS not having it's wildcard system implemented as an OS function call), it should be fixed. But changing a convention just to match another convention doesn't fix anything. If I make AmigaDOS look more like UNIX, maybe Aegis users will get pissed off. This reminds me alot of the arguments that crop up occasionally over in comp.lang.c. Every so often, some fan of Pascal or Modula2 gets up and starts complaining about how C uses "=" instead of ":=", "==" instead of "=", "&&" insead of "AND", "%" instead of "MOD", etc. My feelings on this are exactly the same -- either learn the language|OS that you're using, or maybe you should consider using a different languaga|OS (please read "you" as the collective "you" -- I'm not intending to flame Monty in person here). If Amiga wildcards are so contrary to your thought processess, rather than changing the operating system to suit your way of thinking, maybe you should run UNIX on your Amiga instead. Or run a custom Amiga shell that fools you into thinking you're on a UNIX system. Or try going with AmigaDOS for awhile instead of fighting it -- it's really quite a nice system, honest! > Monty -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
dbk@teroach.UUCP (Dave Kinzer) (03/16/89)
In article <6294@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: [yes, deletions many] > >this are exactly the same -- either learn the language|OS that you're >using, or maybe you should consider using a different languaga|OS >-- >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" I have been skipping this thread for the most part because this is exactly the way I feel and the arguements about how this nit-pickey thing or that is *wrong* essentially piss me off. I have no difficulty actually using the operating system to get my jobs done, and if I have to learn a few thing, well I ain't too old yet. It pains me (and is probably my fault for not speaking up sooner) that the quoted text above had to come from somebody at Commodore. This has, IMHO, gotten quite out of hand. Thank you for tolerating this waste of bandwidth... | // GOATS - Gladly Offering All Their Support Dave Kinzer (602)897-3085| | // >> In Hell you need 4Mb to Multitask! << uunet!mcdphx!teroach!dbk | | \X/ #define policy_maker(name) (name->salary > 3 * dave.salary) |
mjl@ut-emx.UUCP (Maurice LeBrun) (03/16/89)
[eat what?] In article <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <11135@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: > [stuff deleted] > >> 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) > >That's a detail of the AmigaDOS copy program, not the wild card system. Agreed. Somewhere between my brain and fingers my thoughts turned to mush on this one. For the record: Amigados wildcards appear more powerful than Unix wildcards. However, I still don't think I should have to resort to the above command line to accomplish this very simple task. To quote a few "obvious" truths : o Simple tasks should be accomplished with ease. o More complex tasks may be accomplished with more difficulty, though simplicity is preferable. and so on.. Since the required task (say copy two unrelated files to t:) is extremely simple, I shouldn't have to contort my fingers to get it done. If it is too much to ask that copy be modified to allow multiple arguments for filenames (rename also), why not supply a separate 'mv' and 'cp' command for those of us who really like the Unix syntax? There are alternate methods of specifying file-lists without resorting to multi-args, such as using commas to delimit files. Although this is an excellent idea, there is a lot of precedent to using spaces, and I like this syntax. It's also a lot easier when you need to put a front end on a utility because the writer didn't provide for multiple file names (simple arguments in that case). To sum up, I still see the following things as being important: o '*' accepted as a universal wildcard o a library exist for expansion of wildcards by utilities o 'copy' and 'rename' extended to allow multiargs, or perhaps provide 'cp' and 'mv' commands (in addition) instead. Adding an 'mv' utility might be best because 'rename' can do fun things with groups of files if there are only 2 args. o Unix relative pathnames accepted anywhere AmigaDos pathnames are. (Maybe some real incompatibilities here, I'm unsure) This last thing would be nice, but probably not essential. Certainly some of this is taken care of by ARP. I really can't understand why Commodore isn't trying to acquire ARP, or at least duplicate it. >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession Maurice LeBrun | "So then I says to Borg, `You know, Institute for Fusion Studies | as long as we're under siege, one of us University of Texas at Austin | oughta moon these Saxon dogs.'" Internet: | mjl@fusion.ph.utexas.edu | (Far Side)
mjl@ut-emx.UUCP (mjl) (03/16/89)
--- In article <6294@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <352@sagpd1.UUCP>, monty@sagpd1.UUCP (Monty Saine) says: > >> in article Message-ID: <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) says: > >> <UNIX compatibility is important in UNIX systems, not VMS, MS-DOS, Amiga, >> ^^^^^^^^^^^^^^^^^^^^ ^^^^^ >> Are we forgetting that Unix and Amiga are merging with the 2500UX ? >> It seems to me that we should be working towards a closer user commonality >> with UNIX if we are now supporting a UNIX port on the Amiga. It will be a >> real pain to have one system with two different sets of wild cards based >> on how you boot it up. > >Well, so far today, I've worked on system running AmigaDOS, VAX/VMS, >UNIX, and Aegis. Each system has it's own commands, it's own file name >conventions, it's own directory naming conventions, and it's own >wildcard system. It's really no big deal to move between such >differences. [stuff deleted] I disagree completely, to put it gently. I for one do *not* like to do SIMPLE things completely differently on different systems. Complex things, system-specific things, sure. But file copies? Moves? Directory deletes? There are about a half-dozen to a dozen operations BASIC to ANY hierarchical file system, and there is no bloody way I want N different ways of doing them for N different systems. Standards are always difficult in their adoption, and this is no exception. Unix conventions *may* be a good model here, because (a) it is popular and growing in popularity geometrically and (b) it is pretty well thought out. To witness (a), a lot of computer manufacturers now offer Unix or a Unix-like file system as standard or an option (Cray [UNICOS], Dec [Ultrix], Apple[AUX], NeXT [Mach], C/A [AMIX] !!, the beat goes on); as well as look-alikes that run under the native OS (Eunice or Dec/Shell under VMS). Dec's VAXC compiler even offers automatic translation between Unix-style and VMS-style pathnames. Where Unix *obviously* needs improvement, go for it! Otherwise, tread very, very carefully, and compatibility at *some* level is a good thing. For the record, the very existence of the 2500UX is encouraging. However, I don't necessarily want the *entire Unix system* running on my machine, and don't think an all-or-nothing approach is the only solution. Dave also offers the following anecdote: >This reminds me alot of the arguments that crop up occasionally over in >comp.lang.c. Every so often, some fan of Pascal or Modula2 gets up and >starts complaining about how C uses "=" instead of ":=", "==" instead of >"=", "&&" insead of "AND", "%" instead of "MOD", etc. [stuff deleted] Well, I used to own both a '70 Camaro and a '74 Vega (still have the Camaro :-). As you might guess, they drove *completely* different, though it wasn't too hard switching between them. But then, the steering wheels were in approximately the same place, as was the brake pedal, accelerator, dash gauges, turn signals, mirrors, seats, radios... >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" Maurice LeBrun | "So then I says to Borg, `You know, Institute for Fusion Studies | as long as we're under siege, one of us University of Texas at Austin | oughta moon these Saxon dogs.'" Internet: | mjl@fusion.ph.utexas.edu | (Far Side)
mjl@ut-emx.UUCP (mjl) (03/16/89)
--- In article <107@ssibbs.UUCP> jac@ssibbs.UUCP (James Crotinger) writes: [stuff deleted] >Maurice and I work on some machines at Livermore which run an OS called >CTSS (Cray Time Sharing System). Generally, it sucks big time. But in the >last couple of years they've been moving towards "UNIX compliance". They've >added a hierarchical file system (yes, they really didn't have one before!), >a big complement of UNIX commands in all the natural places, UNIX style >file protection, links, etc. Now they're on the final leg, and are adding [here too] An interesting bit of trivia here is that the system really looks reasonably like Unix (to the untrained eye), except that there's NO SHELL (at least no Unix shell). Each utility does its own wildcard expansion, via a library call. They are working on a csh port, though. > Jim Crotinger Maurice LeBrun | "So then I says to Borg, `You know, Institute for Fusion Studies | as long as we're under siege, one of us University of Texas at Austin | oughta moon these Saxon dogs.'" Internet: | mjl@fusion.ph.utexas.edu | (Far Side)
daveh@cbmvax.UUCP (Dave Haynie) (03/17/89)
in article <11241@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: > In article <6235@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <11135@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: > [stuff deleted] >>> 1> copy (*.c|*.h) t: (what's wrong with `cp *.c *.h t:' ??) >>That's a detail of the AmigaDOS copy program, not the wild card system. > If it is too much to ask that copy be modified to allow > multiple arguments for filenames (rename also), why not supply a > separate 'mv' and 'cp' command for those of us who really like the > Unix syntax? Well, I'd really like to see the Copy command more robust. And if you want 'mv' and 'cp' direct equivalents, there are lots of these available in the public domain, and they're really not that hard if you want your own version. But you can't expect them to be a standard part of the AmigaDOS operating system, any more than you can expect UNIX to adopt as standard the Copy and Rename commands with complete AmigaDOS syntax. > There are alternate methods of specifying file-lists without > resorting to multi-args, such as using commas to delimit files. > Although this is an excellent idea, there is a lot of precedent to > using spaces, and I like this syntax. No one's arguing this. Since the space-parsing is already done, it would be pretty simple to make Copy more intelligent, without introducing more cruft. > To sum up, I still see the following things as being important: > o '*' accepted as a universal wildcard If you still think this is important, you're still missing my point. '*' in AmigaDOS means "stdio" or "stdin", depending on where it's used. It's not an AmigaDOS wild card, it's used in UNIX and MS-DOS as such (though with slightly different meaning). If AmigaDOS lacked that kind of wild card, I'd say fine. But continuing to insist on AmigaDOS adding '*' is just reflecting your personal biases. > o a library exist for expansion of wildcards by utilities Absolutely. I don't think you'll get any disagreement on the need for a standard system call for wildcard expansion or matching. > o 'copy' and 'rename' extended to allow multiargs, or perhaps provide > 'cp' and 'mv' commands (in addition) instead. Adding an 'mv' utility > might be best because 'rename' can do fun things with groups of > files if there are only 2 args. Whaddya think this is, Berkeley UNIX or something. If the Copy command is robust enough, you don't need two or three versions. If you don't like the name "Copy", use an alias. Rename is really just that, Rename. It amounts to sending an ACTION_RENAME (or whatever it's actually called) packet to a file handler for the file you specify first. What I call a "Move" command would be more robust, and actually do some additional processing to handle things like "Rename #?.o DirectoryName" or something. Obviously, Rename with a little more intelligence could figure out that if I specify "Rename File Directory", I really mean "Rename File Directory/File". > o Unix relative pathnames accepted anywhere AmigaDos pathnames are. > (Maybe some real incompatibilities here, I'm unsure) > This last thing would be nice, but probably not essential. No, no, no! You want UNIX, go buy UNIX. Again, I can't see a standard UNIX adpoting AmigaDOS path conventions, and until they do, I can't see why AmigaDOS should adpot UNIX path conventions. Next thing you know, someone's going to be demanding AmigaDOS also understand the evil VAX/VMS path conventions. Get real! >>Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > Maurice LeBrun | "So then I says to Borg, `You know, -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
andy@cbmvax.UUCP (Andy Finkel) (03/17/89)
In article <11242@ut-emx.UUCP> mjl@emx.UUCP (Maurice LeBrun) writes: >Well, I used to own both a '70 Camaro and a '74 Vega (still have the >Camaro :-). As you might guess, they drove *completely* different, >though it wasn't too hard switching between them. But then, the >steering wheels were in approximately the same place, as was the brake >pedal, accelerator, dash gauges, turn signals, mirrors, seats, radios... Think of wildcards as the location of the gas tank fill spout, then. You worked that one out, didn't you ? -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "The salesperson said this computer is the next best thing to sliced bread, but didn't say what to do about the crumbs in the disk drive." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
charles@hpcvca.HP.COM (Charles Brown) (03/17/89)
> / hpcvca:comp.sys.amiga / daveh@cbmvax.UUCP (Dave Haynie) >> ...AmigaDOS ones don't *seem* to be well documented to for >> the average user. It's hard to use them without knowing them. > That is true, or at least it used to be back in the A1000 days, when you > didn't get an AmigaDOS manual at all with the system. You still don't... do you? I just bought an Amiga2000 and it did not include an AmigaDOS manual. It did not include several other things that it should have so I contacted Commodore Support and was told that the AmigaDOS is not included. >> Which leads to what I consider the other half of the problem. >> Making use of the full wildcarding system should be trivially >> simple for programmers. >> Jim Wright > I don't think you'll get much argument on that one. A standard library > routine would make all pattern matching consistent, and extend it's use > throughout the system, such as in file requesters. > Dave Haynie I prefer that the shell implement wild cards. That way it is always consistent. It also potentially makes the commands smaller. One thing I find irritating about the current Amiga commands is that I cannot say: copy dir1/file1 dir2/files* dir3/file3 dir4 If the shell implemented wild cards, then copy would allow any number of files and this would work. -- Charles Brown charles%hpcvca@hplabs.hp.com Not representing my employer.
deraadt@xenlink.UUCP (Theo A. DeRaadt) (03/17/89)
In article <6317@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > In article <11242@ut-emx.UUCP> mjl@emx.UUCP (Maurice LeBrun) writes: > >Well, I used to own both a '70 Camaro and a '74 Vega (still have the > >Camaro :-). As you might guess, they drove *completely* different, > >though it wasn't too hard switching between them. But then, the > >steering wheels were in approximately the same place, as was the brake > >pedal, accelerator, dash gauges, turn signals, mirrors, seats, radios... > > Think of wildcards as the location of the gas tank fill spout, > then. You worked that one out, didn't you ? You use the gas tank fill spout once in a while, when you fill up. If you drive lots, maybe every second day. Maybe once a week. I sit down at a Unix box. I write some code. I will use "*" within 5 minutes, guaranteed. I'd say that's an "accelerator", not a "gas tank fill spout". So, every day. Unix. Amiga. Unix. Amiga. You don't get used to how bad the Amiga commands are. <tdr.
usenet@cps3xx.UUCP (Usenet file owner) (03/18/89)
>> I don't think you'll get much argument on that one. A standard library >> routine would make all pattern matching consistent, and extend it's use >> throughout the system, such as in file requesters. >> Dave Haynie > >I prefer that the shell implement wild cards. That way it is always >consistent. It also potentially makes the commands smaller. > Before CBM puts path name pattern stuff in a library or in a Shell or whereever they end up putting them, how about extending them a bit? There are a few of options option missing that I have found would be very nice to have namely an '&' and an exclusion operator is exclusion, as in 'match everything but this' For example: (^(Makefile))&[a-z]#?) this would match everything that is made of only letters, and is not 'Makefile' There probly should be special treatment for directory names, so that you can specify if the pattern should match directories,files or both. While we're at it, how aobut matching file protection bits too? and once you've done all that, you might as well add filedates also. The file dates and protection bits specifications could concievably be options only with a file requester. If there is going to be a standard requester, there should be a special pattern to tell the shell to pull up the requester and then replace the commandline pattern with the results of the requester. Please don't flame that this is too much, its just a wish list after all. In Real Life: Joe Porkka porkka@frith.egr.msu jap@syssun.cl.msu.edu (35.8.1.1) Life is just a game, so relax and be happy.
gsarff@landru.UUCP (Gary Sarff) (03/18/89)
In article <600@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) >From article <6235@cbmvax.UUCP>, by daveh@cbmvax.UUCP (Dave Haynie): >> [discussion of AmigaDOS versus Unix wild card styles deleted.] >> That's a detail of the AmigaDOS copy program, not the wild card system. > > I think this is the real problem with the way AmigaDOS handles wild >cards. Instead of building the pattern matching code into each command I'd >like to see filename patterns expanded by the shell, as in Unix. The shell >would then pass the appropriate arguments to the commands, providing the >user with a standard, consistent way to specify a filename pattern for >every command. > You could have a standard consistent way to use wildcards with commands with the wildcarding code built in to each one if they would all use THE SAME method, i.e. a linkable library routine that all the programmers who write the utilities must use. I am using an operating system that does this, so that the utilities expand the wildcards themselves instead of the shell. One problem I DO NOT have that UNIX utilities do is that I can wildcard a huge number of files, my entire hard disk say and not worry about huge command line lengths. You run into this on many Unix systems that are running Usenet News, go to some directory like /usr/spool/news/talk/politics (or maybe comp.sys.amiga on a busy week 8-) and do a grep Subject: * or something and watch the thing tell you "command line too long". So, all the nice Unix utilities that you wanted to wildcard won't work anymore because the shell can't build the whole command line, now you are well and stuck unless you want to write a shell script to do the files one at a time, (No I don't need other examples of how to do this, that isn't the point). On the other hand if the utilities do the expansion I can do grep Subject: /usr/spool/news/*/* i.e. grep all files in all subdirectories, how long do you think the command line for that would be if the shell put each file name on grep's command line, complete with directory path? The OS I am using has the utilities all written using the same routines to expand wildcards, to retrieve command line arguments, etc. So that ALL utilities act in the same way. Command line arguments can be positional, or keyword or both, and can be switches or values, the syntax is that switches (boolean, or value) start with a colon (:), followed by the alphabetic characters making up the switch, such as del /.*/*.c :exclude=abs.c,sub.c :before=20-mar-1989_08:00:00 :auto where :exclude= is a value switch, i.e. a list of values follows the switch. :auto is a boolean switch, only :auto or :noauto are acceptable. :auto means do not prompt for operator verification, just delete the files. :Noauto would be the same as not using the Auto switch at all. But it would do what the user expects if they were strange enough to use it. It all means delete all the files in all subdirectories of the current dir, with extensions of .c that were created on or before 20th march etc, EXCEPT the two files abs.c and sub.c, and DO NOT ask me if I am sure I want to delete them. The great thing to me about these routines is that they are quite flexible, with unambiguous switch completion. So I wouldn't have to spell out :exclude, I could just say :excl or maybe :ex or even :e if no other arguments for this command start with :e. Also the command line parsing routine, which calls the wildcard expansion routines and the argument parsing routines allows you to place things in any order that pleases you, something not possible really on the Amiga. So I could have as easily have said del :exclude=abs.c,sub.c /.*/*.c :auto :before=20-mar-1989_08:00:00 or any of the other possible variations of position and shortening of :exclude, :before, and :auto switch names. Interspersed with switches and file wildcards I can redirect I/O with < and > symbols, on the Amiga as of now we have to put these right after the command name if we are going to use them at all, in the above example they could have been put anywhere on the line and the < and > need not be consecutive arguments either. The shell will find them, open the needed I/O channels and remove them from the command line so that the argument numbers that the program sees will not include them at all. Since these routines are used in all utilities, any command that says it will allow file wildcarding, will let me used things like /.*/* and :exclude,:before, :since, etc, etc. because the routines are the same in each utility. Of course they could be in the shell and it could do all this but some wildcard directives could be complicated and this delays program start up. Seems on the Amiga this would be ideal for a shared library. This behaviour is something that both Amigados and Unix are sadly lacking in. They both look like their utilities were designed by many different people over time who didn't talk to each other and so we get this mishmash of command characteristics, in Unix some commands want files then -'ed switches, others the switches first, then the file names, some will process a directory tree, some won't, and so on, and no one really seems to care, they just say, "It's Unix, we can't change it", and I agree sort of, it's way too late for Unix to change. But on a new system one would hope that there would have been some consistency to the way things were done, and a little more power to the wildcarding too. Well enough ranting, blame it on my upbringing with a different OS. 8-) ----------------------------------------------------------------------------- "Do you have any Venezualan Beaver cheese?" -- The Cheese Shop, Monty Python I've often wondered why no one makes cheese from cat's milk?
sparks@corpane.UUCP (John Sparks) (03/19/89)
To those who keep complaining about wanting AmigaDos to be a unix clone:
I regularly use both Unix and AmigaDOS. And I like them both. I don't mind them
being slightly different in syntax, and have no problem with switching between
the two. I even work on MSDOS, VMS, and RSTS/E. As they say: variety is the
spice of life.
Standards (read total compatability) have their uses. They make it easier to
learn how to operate a car, or a computer, or TV, etc. But they also stifle
innovation and change. Look at the trouble we are having in getting a new
High Definition Television system started. Why? because it has to be compatable
with our old NTSC 'standard' and Europes PAL 'standard'. Standards also tend
to make everything 'vanilla' so that it works on anything. Would you like
all computers to be the same, totally compatible, like MSDOS clones?
The same goes for operating systems. Each has it's advantages and
disadvantages. Unix has an easy to use '*' wildcard. But AmigaDos's '#' and '?'
operatives give you much more flexability than unix. And AmigaDos has
filenotes. Unix doesn't.
Why don't you complain to AT&T to provide filenotes for unix?
If you want unix, by a 2500UX and run AMIX. But then you will complain that
unix doesn't do some of the nice things you can do with AmigaDos.
If you just want AmigaDos to look like unix, you can always use aliases in
Shell. You can get ARP, I believe it uses '*' as a wildcard.
As for AmigaDos 1.3 . I think it's great!
--
John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps
______________| sparks@corpane.UUCP | 502/968-5401 thru -5406
If we weren't supposed to juggle, tennis balls wouldn't come three to a can.schow@bnr-public.uucp (Stanley Chow) (03/19/89)
In article <6306@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <11241@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: > >> To sum up, I still see the following things as being important: > >> o '*' accepted as a universal wildcard > >If you still think this is important, you're still missing my point. '*' in >AmigaDOS means "stdio" or "stdin", depending on where it's used. It's not >an AmigaDOS wild card, it's used in UNIX and MS-DOS as such (though with >slightly different meaning). If AmigaDOS lacked that kind of wild card, >I'd say fine. But continuing to insist on AmigaDOS adding '*' is just >reflecting your personal biases. > I agree with Dave. The AmigaDOS wildcard convention is perfectly adequate (in fact, I think it is nicer than most). > >> o Unix relative pathnames accepted anywhere AmigaDos pathnames are. >> (Maybe some real incompatibilities here, I'm unsure) >> This last thing would be nice, but probably not essential. > >No, no, no! You want UNIX, go buy UNIX. Again, I can't see a standard >UNIX adpoting AmigaDOS path conventions, and until they do, I can't see >why AmigaDOS should adpot UNIX path conventions. Next thing you know, >someone's going to be demanding AmigaDOS also understand the evil >VAX/VMS path conventions. Get real! > Well, I don't want Unix. I am already forced to have a HP 9000 on my desk at work. I don't want my Amiga to adopt the dreadful Unix syntax. (I will admit it is nice to have a fast Unix box for reading news :-). The requests sounded very funny. As Dave says, you want Unix, you buy Unix. I am very happy with Amiga. Why should I trade in a fast Amiga for a slow Unix? Especailly when Unix has all those weirdo command syntaxes? Next thing you know, someone is going to ask for all editors be vi-compatible. In particular, the Unix convention of expanding wildcard in the shell strikes me as very silly. I wasn't around when it was introduced, but I would guess that early Unix had not wildcard, then some wizard wanted to add wildcard but did not want to chagne every program, so the shell was chosen. (I am surely several thounsand people will now tell me a committee of the top ergonometrist studied the problem and designed the Unix solution). Consider the problems of expanding wildcard in the shell: - increditably long lines are passed around. - i type in "foo*", the shell looks through the directory and picks up all matching names, pasts them together, then the application program goes through each name and looks through the directory again. Even with good hashing and caching, this is still silly. - Many commands end up with really strange silly syntax since the shell ends up mucking up the parameters. Ever considered my Unix has no RENAME command? In MS-DOS, I can do 'rename *.foo *.bar', try that on Unix. - The shell does not know which parameters are filenames and ends up expanding them all. This means I have to escape '*'. Unix have far too many funny characters, why should Amiga be draged down to the same level? I really thank that the arp people have it right: provide a set of library routines for the expansion operations. This makes the shell easier, the application smaller and faster, and makes the syntax of commands easier to comprehand. Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 What? Me? Say something bad about Unix? When the company is buying them by the hundreds? Come on, I like what I am doing so it must have been someone else pretending to be me.
karl@sugar.hackercorp.com (Karl Lehenbauer) (03/19/89)
Various people write about AmigaDos vs. Unix wildcard/pathnames. I find my development cycle on the Amiga to be essentially identical to that on Unix. This is the vi-make-test cycle...with a little 'sdb' thrown in on the side. ...and incidentally, 'sdb' on the Amiga is largely superior to sdb on Unix. Most Unix users do not yet have a multiwindowed environment like the one we Amiga users take for granted. Although you can "bang out" from many Unix utilities and you can kick tasks off in the background, windows are far superior to such things. (It is arguable that there are certain advantages to job control, but if the choice was mutually exclusive, I'd take windows over job control any day.) On the user side, the Amiga's icon-oriented environment is much more intuitive than X-Windows; most Unix people don't have an icon-oriented environment at all. While experts have little use for them, I think it is undeniable that icon-oriented programs are easier to use when one uses them rarely or is trying to figure them out without a manual, like we all are inclined to do. Also, try using a command-line-oriented paint program, if you can find one -- there are some applications that simply require the icon-oriented, event-driven model. Note also that there is no emerging Unix windowing and icon-oriented user interface standard. IBM and DEC have succesfully fractured Unix with this coup. Hell, IBM has even said they're not necessarily committed to whatever user interface OSF comes up with -- they've cut their own deal with Steven Jobs for NextStep. We have a standard environment now, have had for years, and will continue to have it while the Unix community suffers the giant shudders and heaves along the way to sorting this out. The Amiga exec is realtime. There is no standard realtime Unix. That's pretty important for games, sequencers, etc. I do like the way the Unix shells expand wildcards. I think the answer on the Amiga is to write a new _main that expands wildcards. This can be done without modifying the shell or the CLI and it maintains compatibility with older programs. Also, you don't have to convince Commodore that it's the way to go to do it, plus it solves the problem with the only expenses being that you link in a small number of hundreds of bytes of code that you wouldn't need in a perfect world and that older programs that don't expand wildcards still wouldn't expand wildcards. Command environments are mainly for developers. The Amiga command environment is not that bad. It's too late to change the file system naming conventions. The Amiga does a whole lot of things most Unix systems do not do. Commodore is going to sell a million Amigas this year. 'Nuff said. -- -- uunet!sugar!karl | "Time is an illusion. Lunchtime doubly so." -- | -- Ford Prefect -- Usenet BBS (713) 438-5018
Walter_Thomas_Reed@cup.portal.com (03/20/89)
{ A bunch of people write: }
>> [discussion of AmigaDOS versus Unix wild card styles deleted.]
>> That's a detail of the AmigaDOS copy program, not the wild card system.
> I think this is the real problem with the way AmigaDOS handles wild
>cards. Instead of building the pattern matching code into each command I'd
>like to see filename patterns expanded by the shell, as in Unix. The shell
>would then pass the appropriate arguments to the commands, providing the
>user with a standard, consistent way to specify a filename pattern for
>every command.
>
]You could have a standard consistent way to use wildcards with commands
]with the wildcarding code built in to each one if they would all use
]THE SAME method, i.e. a linkable library routine that all the programmers
]who write the utilities must use. I am using an operating system that does
]this, so that the utilities expand the wildcards themselves
Well, This is what ARP does in a shared library, using the GADS call for
command syntax and wild card calls for expansion. It allows your program
to be smaller than ones using a linked library.
What is so bad about ARP people? it has templates for help built in and
allows many programs to have the same syntax. (actualy, all programs can have
the same syntax, it's just that arp uses the old AmigaDOS compatible formats
so people don't get all mixed up going between ARP and non-arp stuff.)
There is a good chance of ARP getting into 1.4 you know. If it does, then
all the problems could be solved. All commands could use the arp wild card
routines (which don't have the problem of creating a command line too long
error.)
What we need is for the compiler people to include ARP stuff, and commodore
to be compatible with it (for resident stuff.) Then ARP should be compatible
with commodore too (Environment Vars and such.) Of course the ARP people have
to give permission for these companies to do this, but they seem willing.
What developers and programmers need is an official word from commodore saying
"We will support ARP." That's all we need. Well, a standard format for the
command line could be set too.
Well, What say?paolucci@snll-arpagw.UUCP (Sam Paolucci) (03/20/89)
In article <3645@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
->On the user side, the Amiga's icon-oriented environment is much more intuitive
->than X-Windows; most Unix people don't have an icon-oriented environment at
->all.
I don't understand your comment that "the Amiga icon-oriented environment is
much more intuitive than X-Windows". The window manager in X-Windows is
just a program just like any of the other client programs in X-Windows.
As such, there are many window managers in use with very different
user presentation. If one wanted to, one could write a window manager
which would look exactly like Workbench, and you could customize
you menus to boot. Currently, there are at least two companies that
are writing window managers that behave exactly like MS Windows.
Your statement must be based on an observation of a particular (simple)
window manager.
The second part of your statement is probably right, but the first part
is clearly wrong.
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.govdeven@pawl.rpi.edu (Deven Corzine) (03/21/89)
In article <353@bnr-fos.UUCP> schow@bnr-public.uucp (Stanley Chow) writes: >In article <6306@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <11241@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: >> >>> To sum up, I still see the following things as being important: >> >>> o '*' accepted as a universal wildcard >> >>If you still think this is important, you're still missing my point. '*' in >>AmigaDOS means "stdio" or "stdin", depending on where it's used. It's not >>an AmigaDOS wild card, it's used in UNIX and MS-DOS as such (though with >>slightly different meaning). If AmigaDOS lacked that kind of wild card, >>I'd say fine. But continuing to insist on AmigaDOS adding '*' is just >>reflecting your personal biases. > I agree with Dave. The AmigaDOS wildcard convention is perfectly adequate > (in fact, I think it is nicer than most). Oh, come on. Just how many users new to the amiga are EVER going to think of using "#?" for a wildcard?? '*' is VERY widely used and accepted, in Unix, MS-DOS and other operating systems. It was 3-4 months after I started using the Amiga before I found out there really WAS a "match everything" wildcard, namely "#?". I looked carefully through the documentation that came with the Amiga (500) to no avail. I guessed every possible single-character wildcard, and none worked. I had used regexp's under Unix, but it never occurred that ANYONE would be dumb enough to use a regexp-type (2 character) wildcard and then not even document it clearly. I was stuck with the assumption that some absolute moron forgot even to put in a wildcard and that there was none. And it was months before I heard reference to it in passing. And it was 6-8 months before I found out that there was a keyboard end-of-file character, namely ^\. (What? Only one character? What a concept!) The damn manual spent all its time explaining how to shuffle icons under workbench and how to diskcopy a disk. Nothing important was explained. The workbench didn't need as much explaination as it got, and the CLI needed FAR FAR more. It's like the person who wrote the manual thought no one would EVER use a command driven interface when there was a graphic one available. It makes me sick. Sorry guys, but there is just *NO* excuse for this sort of shit. >>> o Unix relative pathnames accepted anywhere AmigaDos pathnames are. >>> (Maybe some real incompatibilities here, I'm unsure) >>> This last thing would be nice, but probably not essential. >>No, no, no! You want UNIX, go buy UNIX. Again, I can't see a standard >>UNIX adpoting AmigaDOS path conventions, and until they do, I can't see >>why AmigaDOS should adpot UNIX path conventions. Next thing you know, >>someone's going to be demanding AmigaDOS also understand the evil >>VAX/VMS path conventions. Get real! I want Unix on an Amiga. What's wrong with that? Unix is a well-designed, well-thought-out operating system, with a simple and elegant paradigm. AmigaDOS is clumsy and obstrusive. I like the Amiga hardware. Exec is excellent. AmigaDOS sucks. Intuition I'd rather replace, but it's livable. As far as I'm concerned, I don't want to put up with using AmigaDOS as it is more than I have to. You like AmigaDOS? Fine. Use it. I want something fairly close to Unix myself. On an Amiga. >Well, I don't want Unix. I am already forced to have a HP 9000 on my desk >at work. I don't want my Amiga to adopt the dreadful Unix syntax. (I will >admit it is nice to have a fast Unix box for reading news :-). Dreadful Unix syntax indeed. Unix is a relatively simple design, through and through. Unix is intended to be functional, simple, but powerful. And that it is. Unix is not intended to cater to users who like things overly verbose, who like to type far more than they need to, who like the operating system to impose its ideas of how things ought to be done on you. Unix is flexible in the extreme. If you really want an AmigaDOS interface, you could write a Unix shell which would look like AmigaDOS. I, for one, would never want to. >The requests sounded very funny. As Dave says, you want Unix, you buy >Unix. I am very happy with Amiga. Why should I trade in a fast Amiga >for a slow Unix? Especailly when Unix has all those weirdo command >syntaxes? Next thing you know, someone is going to ask for all editors >be vi-compatible. Unix is an operating system. The Amiga is a computer. The Amiga can run Unix. (The 2500UX already does.) Your assumption that Unix is inherently slow is patently absurd. You are probably basing it on the speed of a Unix system when you run too much at once and start it thrashing on paging and swapping to disk. The Amiga can't even do that. It doesn't have an MMU. (Not a standard Amiga, at least.) If you ran Unix on the Amiga without paging (which isn't possible) or swapping (which is quite possible, but only really feasible with a HD) you will get similar speeds to programs running on the Amiga under AmigaDOS. The command syntaxes are concise, not verbose. *Most* people I've known find they far prefer the syntax once they finally learn it. I know I don't like having to type things like "format df0: name newdisk noicons" just to format a disk. As far as vi goes, I *like* vi. It is a good editor and in widespread use. I'd much rather use it than C-A's "ED"... (And I have never seen a *good* implementation of vi for the Amiga... *sigh*) >In particular, the Unix convention of expanding wildcard in the shell >strikes me as very silly. I wasn't around when it was introduced, but >I would guess that early Unix had not wildcard, then some wizard >wanted to add wildcard but did not want to chagne every program, so >the shell was chosen. (I am surely several thounsand people will now >tell me a committee of the top ergonometrist studied the problem and >designed the Unix solution). You sure have a lot to learn about Unix. The wildcards have been in the shell from the very beginning. It was an intentional design *feature*. Unix was born at Bell Laboratories way back in 1970. It went through major changes up to Unix V6 in 1975, which was later replaced with Unix V7 in 1979. Unix V7 was small, simple and elegant, and embodied the most important features of Unix. In fact, the only major feature missing from the First Edition of Unix (Unix V1, 1971) was pipes. Pipes were added in 1972 for Unix V2. The wildcards have been in the shell all along, and quite intentionally so. There was no committee. The Unix operating system and the C programming language were designed and written primarily by Ken Thompson and Dennis Ritchie. Without those TWO *programmers*, neither Unix nor C would exist today. Far from a "committee of the top ergonometrists"... NOW Unix and particularly ANSI C are ending up in the hands of committees, but the original degins by no means was. > Consider the problems of expanding wildcard in the shell: > - increditably long lines are passed around. So? Either the shell builds an incredibly long line and pulls the parameters from it to pass to the program, or you pass the program the command line directly (as the CLI does) and the program builds the same incredibly long line. Big lot of difference it makes. > - i type in "foo*", the shell looks through the directory and picks up > all matching names, pasts them together, then the application program > goes through each name and looks through the directory again. Even with > good hashing and caching, this is still silly. Is it now? Not necessarily... take a look at good old AmigaDOS... scanning a directory takes forever. Pulling a single entry from a directory as done at a reasonable speed. Besides, if the directory is cached, it is not a significant performance difference anyway, and not worth worrying about. > - Many commands end up with really strange silly syntax since the shell > ends up mucking up the parameters. Ever considered my Unix has no RENAME > command? In MS-DOS, I can do 'rename *.foo *.bar', try that on Unix. Unix uses 'mv' to rename files. No, it doesn't happen to handle multiple renames such as "rename *.foo *.bar". Big deal. You could write one if you really wanted to. Granted, the * would have to be escaped, or you could choose a different wildcard... say, '#?'... Or, you could write a shell with such a rename command builtin, since it handles the wildcard expansion to begin with. > - The shell does not know which parameters are filenames and ends up > expanding them all. This means I have to escape '*'. Unix have far too > many funny characters, why should Amiga be draged down to the same level? No, it doesn't know if they're filenames. It assumes they're filenames if you use a * or ?, and does wildcard matching for them accordingly. Note that if you really want to, you can generally disable automatic wildcard matching. ("set noglob" in csh) Unix doesn't try to force you to use the filenames to open the files. Maybe you want a list of the files in the current directory in some special format. Or just specified files. It doesn't matter. Well, let's see. Metacharacters in csh (has slightly more than sh) vs. metacharacters in the AmigaDOS CLI... '~' in csh, when at the start of a word, to get the following user's home directory. AmigaDOS can't handle multiple users, so naturally it has no equivalent. '`' in csh to delimit a string which is to be parsed, executed as a command (in a subshell), and its output to replace the `command` on the command line. An extremely powerful feature which AmigaDOS has nothing to compare to. '!' in csh, when used in expressions, as a logical NOT. Again, no equivalent in the AmigaDOS CLI (or AmigaShell) because it has no ability to handle expressions. More importantly, it is used for history substitutions in the csh. They are too complicated and powerful to be explained here. '@' as a word alone in csh (i.e. preceded and followed by white space) is a shorthand for the csh 'set' command, except that it allows an expression for the value to set thevariable to. AmigaDOS can't handle shell variables or expressions, so again, has no equivalent. But then, '@' is NOT a metacharacter; it's a word with meaning to the shell. '#' is used with $ ('$#') to count the number of words in a shell variable, is a filename matching character for AmigaDOS BCPL programs (it's not centralized in the shell) for 'any number of the following'. '$' is for variable (shell or environment) or parameter [special case of shell variable] substitution in csh, means nothing to AmigaDOS which has no shell variables. '%' is a modulus for expressions in csh, file-match-null for AmigaDOS. '^' is a shorthand for a form of history substitution. example: if last command was 'commnad', typing '^na^an^' will substitute 'an' for 'na', making the new command 'command'. AmigaDOS, again, has nothing close. '&' in csh as a word at the end of a command will make the process run in the background, and the csh will not wait for the process to exit before returning to the shell prompt. In AmigaDOS, you must background programs by prepending "run" to the command, and have the "run" program available. '*' in csh is a match-all file-matching character in csh, '*' is an escape character for AmigaDOS, and also refers to stdin or stdout as a file. (actually, console input and output; equivalent to /dev/tty under Unix) '(' and ')' in csh are to designate a subshell. AmigaDOS can't run subshells. Used with '|' for alternation in file-matching under AmigaDOS. '-' is conventionally used in Unix for options; it is not enforced. AmigaDOS generally uses keywords or "opt" to designate options. '_' means nothing to either. '=' is used in csh for setting shell variables, and '==' for equality tests and '!=' for inequality tests in expressions. (Similarly, '<=', '>=', '<', '>'...) AmigaDOS, again, can't handle shell variables or expressions. Again, not a metacharacter, but has meaning to the shell. '\' in csh as an escape character to escape any metacharacter including itself. Similar to AmigaDOS's '*'. '\' means nothing to AmigaDOS. '|' in csh designates a pipe, '|&' for a pipe with stderr redirected down the pipe as well as stdout. AmigaDOS has no concept of stderr, and can't deal with true pipes. Used with '(' and ')' for alternation in file-matching under AmigaDOS. '[' and ']' are for character classes in both csh and AmigaDOS. (I think...) '{' and '}' for file-matching string lists in csh, similar to () in AmigaDOS. Means nothing to AmigaDOS. "'" is a quote character between which metacharacters such as * are NOT processed. '\' is processed, to allow embedding a "'" in the string. Means nothing to AmigaDOS. '"' is a quote character for both, doesn't affect metacharacters. (might inhibit them in AmigaDOS.) ';' in csh is to separate commands on a line. AmigaDOS can only handle one command per line. ':' means nothing to either. '/' means nothing to either, but is used as a pathname separator. '?' is a file-matching match-any-character metacharacter for both. '.' means nothing to either, '.' and '..' refer to current and parent directory for Unix. ',' is used with '{' and '}' in csh, means nothing to AmigaDOS. '<' is used for input redirection by both, for AmigaDOS must be before arguments and not separated from the filename with a space. '>' is the same as '<' except for output redirection. So what do we have? In csh, you have user home directory lookup, executing command(s) in a subshell and using the output as command line parameters, history substitution, expressions, shell and environment variable support, quick substitution, backgrounding, subshells, pipes, job control, various forms of input, output and error stream redirection, (sh has more flexible redirection) and '{}()|,'"`!<>*?[]' must all be escaped, except between single quotes. Csh has looping and many other programming constructs, and a large number of builtin commands. And that is just one common Unix shell. You can easily rewrite the shell to suit you if you wish. Without changing the programs you run. In the AmigaDOS CLI, you have nothing. You can run programs. That's it. It has no builtin commands, no pipes, minimal I/O redirection, no subshells, no backgrounding, no history or substitution, no builtin commands, everything is external, and nothing is consistent, and it is not nearly as easily replaced as a Unix shell is. Yeah, clearly it would be a tragedy if AmigaDOS was to be dragged down to Unix's level. What could I have been thinking? >I really thank that the arp people have it right: provide a set of library >routines for the expansion operations. This makes the shell easier, the >application smaller and faster, and makes the syntax of commands easier to >comprehand. Unix has regexp library routines readily available. The filename globbing remains in the shell, with reason. Programs don't have to worry about wildcards, knowing the shell will handle them, it is handled centrally and to change the entire wildcard system, you merely need to replace the shell. You can not do the same with AmigaDOS. I like Unix, I want Unix on the Amiga. And there's no way you'll ever convince me AmigaDOS is a superior system. It isn't, and can't even be considered close, even given an enormous stratch of the imagination. So there. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
daveh@cbmvax.UUCP (Dave Haynie) (03/21/89)
in article <45@xenlink.UUCP>, deraadt@xenlink.UUCP (Theo A. DeRaadt) says: >> Think of wildcards as the location of the gas tank fill spout, >> then. You worked that one out, didn't you ? > I sit down at a Unix box. I write some code. I will use "*" within 5 > minutes, guaranteed. I'd say that's an "accelerator", not a > "gas tank fill spout". To extend the car metaphore, take the Audi 5000. Apparently lots of folks who aren't used to the car have had a hard time with the location of it's accelerator. Expert drivers, or folks who drive it every day, have no trouble going between an Audi accelerator pedal and that of any other car. > So, every day. Unix. Amiga. Unix. Amiga. You don't get used to how > bad the Amiga commands are. I don't get used to bad commands, whether on Amiga or a Unix machine. I use both all the time, and others as well. I like the Amiga conventions more than other system I use. Unix is OK, though it has it's quirks. VMS, MS-DOS, and Aegis seem more brain damaged, but I can still use them without "driving through the garage door". > <tdr. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
peter@sugar.hackercorp.com (Peter da Silva) (03/21/89)
In article <75@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > Your statement must be based on an observation of a particular (simple) > window manager. I think it is advisable to judge a system based on the default behavior. The default X-windows window manager is rather lacking in user-friendliness. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
limonce@pilot.njin.net (Tom Limoncelli) (03/21/89)
#define SARCASM ON In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes: > In article <353@bnr-fos.UUCP> schow@bnr-public.uucp (Stanley Chow) writes: > >In article <6306@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >>in article <11241@ut-emx.UUCP>, mjl@ut-emx.UUCP (Maurice LeBrun) says: [and more] back and forth and back and forth and back and forth and back and forth Wait! I hope nobody enters into the middle of this banter. If they did, they might conclude that every operating system has its good and bad points and maybe even start to think that there isn't one perfect operating system. Then the bandwidth of Usenet would be freed up a little and there'd be no reason for people to purchase high-speed modems. So... If you don't want to put Telebit, et al out of business, PLEASE KEEP GOING. IMHO. #define SARCASM OFF -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Madison, NJ -- 201-408-5389 Standard Disclaim er.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (03/21/89)
In article <3652@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: ->In article <75@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: ->> Your statement must be based on an observation of a particular (simple) ->> window manager. -> ->I think it is advisable to judge a system based on the default behavior. The ->default X-windows window manager is rather lacking in user-friendliness. What is the default window manager in X-Windows? Is it wm or uwm, or is it the freely available twm? Or maybe if you have a DEC machine it is the current DEC window manager, or maybe if you have an HP machine ... I hope you get my point. All of the above window manager are fairly different. So in X-Windows in general the standard window manager is the one you get from your machine's manufacturer, or any of the free ones. ->Peter "Have you hugged your wolf today" da Silva `-_-' ->...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
andy@cbmvax.UUCP (Andy Finkel) (03/21/89)
In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >Oh, come on. Just how many users new to the amiga are EVER going to >think of using "#?" for a wildcard?? '*' is VERY widely used and >accepted, in Unix, MS-DOS and other operating systems. It was 3-4 Well, due to reasons beyond our control, the AmigaDOS manual is published seperately. However, the book that came with your 500 did tell you of its existance. I agree that it should have told about the wildcards. Fortunately, there's a simpler solution to the problem than switching to Unix....we can update the manual. >I want Unix on an Amiga. What's wrong with that? Unix is a >well-designed, well-thought-out operating system, with a simple and >elegant paradigm. AmigaDOS is clumsy and obstrusive. I like the >Amiga hardware. Exec is excellent. AmigaDOS sucks. Intuition I'd >rather replace, but it's livable. As far as I'm concerned, I don't >want to put up with using AmigaDOS as it is more than I have to. You >like AmigaDOS? Fine. Use it. I want something fairly close to Unix >myself. On an Amiga. Nothing's wrong with wanting Unix on an Amiga. Freedom of choice is an important concept. That's one reason why we have the A2500 UX, after all. But liking Unix a lot doesn't automatically mean that AmigaDOS is bad. I personally don't have a problem with regular expressions for my pattern matching. I do want it on all the commands that it makes sense to have it; a shared library will be the desired method of implementation, rather than pack it into the shell. (creating very long command lines has some problems, as does those commands that don't want pattern matching) >Dreadful Unix syntax indeed. Unix is a relatively simple design, >through and through. Unix is intended to be functional, simple, but >powerful. And that it is. Unix is not intended to cater to users who Well, I actually got the impression that (at least under BSD systems) there was a certain amount of evolution, and actual disagreements over command syntax...the find command and the print spooler somehow pop into my mind. >really want an AmigaDOS interface, you could write a Unix shell which >would look like AmigaDOS. I, for one, would never want to. You mean, if you want a Amiga CLI and Amiga CLI type interface. The AmigaDOS interface is based on Exec message passing, tasks, and lightweight tasks. By the same token you can implement a Unix shell interface on top of AmigaDOS. In fact, you've even used some of them. >The command syntaxes are concise, not verbose. *Most* people I've >known find they far prefer the syntax once they finally learn it. I >know I don't like having to type things like "format df0: name newdisk >noicons" just to format a disk. The Unix command to format a disk (at least on my Sun 2) involves bringing the Sun down, running a special program called diag, then bringing the system up again. Then I generally run /etc/newfs [ -N ] [ -v ] [ -n ] [ mkfs-options ] block-special-file (since I seldom need to get into mkfs) How is this easier than format ? >As far as vi goes, I *like* vi. It is a good editor and in widespread >use. I'd much rather use it than C-A's "ED"... (And I have never >seen a *good* implementation of vi for the Amiga... *sigh*) So do one. Strikes me as something that a decent programmer and VI user could whip right out. I'm an emacs user. So one of the first things I did was port a version of microemacs, and adjust it so I was happy. >So? Either the shell builds an incredibly long line and pulls the >parameters from it to pass to the program, or you pass the program the >command line directly (as the CLI does) and the program builds the >same incredibly long line. Big lot of difference it makes. Actually, since my wildcards are implemented in the program, via a shared library call, what I do is call 'compile pattern' with my expression, then loop calling 'next match' until it tells me that no more matches are available. The long line problem >Or, you could write a shell with such a rename command builtin, since >it handles the wildcard expansion to begin with. This is not in the spirit of the Unix commands...which are supposed to be small things, each doing a job, which you can link together to form more powerful commands. If you find yourself saying that you can always build it into the shell... > >'`' in csh to delimit a string which is to be parsed, executed as a >command (in a subshell), and its output to replace the `command` on >the command line. An extremely powerful feature which AmigaDOS has >nothing to compare to. The standard AmigaDOS CLI commands can get their arguments from a pipe or a file, as well as from the command line. The primitives are there. > >'!' in csh, when used in expressions, as a logical NOT. Again, no >equivalent in the AmigaDOS CLI (or AmigaShell) because it has no >ability to handle expressions. More importantly, it is used for >history substitutions in the csh. They are too complicated and >powerful to be explained here. ! is rather overloaded character. I hate having to type all those \ or slip into sh when I want to do a bunch of UUCP mailing. The AmigaDOS IF statement allows you to use the NOT keyword to reverse the sense of an expression. You are correct that history substitutions are too complicated, though :-) I usually just bring back the line, edit it, and hit return, rather than count arguments. And, I do this from both AmigaDOS 1.3 Shell and Unix. [metachar discussion deleted for space reasons; also because I'm beginning to suspect you don't have the AmigaDOS manual.] >In csh, you have user home directory lookup, executing command(s) in a >subshell and using the output as command line parameters, history >that is just one common Unix shell. You can easily rewrite the shell >to suit you if you wish. Without changing the programs you run. So what you are saying is that because csh is more powerful, that AmigaDOS is useless ? You *can* write a csh type program on the Amiga. Matt did it. Randell did it. Jay Tees did it. Bill Hawes did it... This then, should be a shell discussion. The shell is not AmigaDOS. Because replacing the shell is more difficult under Unix (though not having written a Unix shell from the ground up, but only making some minor hacks on tcsh I can't really say for myself just how hard or easy it truly is) >need to replace the shell. You can not do the same with AmigaDOS. I >like Unix, I want Unix on the Amiga. And there's no way you'll ever >convince me AmigaDOS is a superior system. You're right. Until you get the AmigaDOS manuals, and learn what it is actually all about, and get 1.3, and the 1.3 manual, and read the manuals, there's no hope of telling you anything. And actually, convincing you would serve no purpose anyway. >So there. It's getting about that time; put your programming time where your keyboard is. Produce the csh clone of your dreams. Clone the Unix programmer interface, the Berkley Fast File system, whatever other parts of Unix you like. Anything you want. Since there's no way anyone can convince you of any redeeming characteristics of AmigaDOS, you're skills must be complete...its time to stop wasting time in discussions like this, and time to start coding. >Deven -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "The salesperson said this computer is the next best thing to sliced bread, but didn't say what to do about the crumbs in the disk drive." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
andy@cbmvax.UUCP (Andy Finkel) (03/21/89)
In article <45@xenlink.UUCP> deraadt@xenlink.UUCP (Theo A. DeRaadt) writes: >I sit down at a Unix box. I write some code. I will use "*" within 5 >minutes, guaranteed. I'd say that's an "accelerator", not a >"gas tank fill spout". Fine. Think of it as radio controls, then. One radio has push buttons and a digital readout. Another has a little red needle and a knob. Neither is *anything* like the other. There, happier with this one ? Well, at least no one here is speaking up for the \ character as the directory delimiter. :-) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "The salesperson said this computer is the next best thing to sliced bread, but didn't say what to do about the crumbs in the disk drive." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/21/89)
[ "Ours is not to reason why..." -- Oliver North ]
My turn.
As a person who was exposed to UNIX before AmigaDOS, my opinion is
that wildcard expansion belongs in the shell. This has a number of
advantages.
Wildcard expansion need not be done inside the application. Thus,
the writer need not look for and deal with special cases on the command
line. Also, wildcard expansion code will not appear in every copy of every
application launched (even with a wildcard expander in a shared library, you
still have to write code to call it). This saves code and disk space.
One single set of wildcards can be agreed upon and adhered to, since
all applications will see is a long string of command line arguments. Thus,
multiple standards (#? vs. *) are avoided, and the user need not have to
remember which program is using which set of wildcards this week.
It was suggested long ago that the amount of disk gronking that a
shell-based wildcard expander would be excessive. Well, what would the
launched command be doing if you handed it a wildcard?
The only disadvantage I can see with this is that, with large
directories, an expanded wildcard might exceed the 255 character limit of
BCPL strings.
IMHO, TINAR, and all that...
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctordarin@nova.laic.uucp (Darin Johnson) (03/22/89)
In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >In article <353@bnr-fos.UUCP> schow@bnr-public.uucp (Stanley Chow) writes: > >>In particular, the Unix convention of expanding wildcard in the shell >>strikes me as very silly. >> Consider the problems of expanding wildcard in the shell: >> - increditably long lines are passed around. > >So? Either the shell builds an incredibly long line and pulls the >parameters from it to pass to the program, or you pass the program the >command line directly (as the CLI does) and the program builds the >same incredibly long line. Big lot of difference it makes. This isn't true. Most OS's that I have seen that support wildcards from within programs (rather than from the shell) have library calls similar to directory reading routines (Examine, ExNext). So you could write a program that expands the wildcards, sticking each new thing onto an ever growing argv list. But even better, if you are writing something that doesn't need every argument before it starts, you can expand the wildcards incrementally, dealing with each argument, tossing it away, getting the next, etc. For example, rm/delete don't need to have every argument before they start deleting things. Of course, if rm had the expanded list, it could actually figure out that a file didn't exist and abort before deleting anything, but it doesn't do that anyway... However, I do like UNIX style wildcards, it's just a bit innefficient. It is handy though. The echo command with wildcards is pretty useful (a cheap version of find). The philosophy deep down is elegant - a command should do the same thing for "rm *.c" or "rm `find -xyz`". (actually, I don't like to use 'elegant' with unix. I don't think it was designed to be elegant as such. Diehards just like to say 'elegant' instead of 'works well with the kludges that are already there'.) >multiple renames such as "rename *.foo *.bar". Big deal. You could >write one if you really wanted to. Granted, the * would have to be >escaped, or you could choose a dif I don't know if it is that big of a deal. As much as I hate VMS, I grudgingly admit there are a few things about it that I really like, and can't live without. One of these is "rename *.c *.old_c". How about "rename *.% *.old_%" or "rename *.* ;1" (give everything a version number of 1)? In unix, I have to do "mkdir old; mv *.c old", or use a foreach statement. Of course, letting each program handle wildcards has a big pitfall, as experienced in some major OS's - the 'semantics' of wildcards can be different for different commands (causes confusion if "cc *.c" and "pascal *.pas" do different things). >(list of csh features/metachars elided) If the CLI had even half of this stuff, people on 512K machines would be in trouble. Most of the stuff is not used in common unix command lines, but is usually in shell scripts (I had to look up the @, how embarassing). The stuff I personally would like would be pipes and job control (the thing I like about & is that you can change your mind halfway through typing the command and not have to re-edit it). I don't really care about the history, since I usually use arrow keys anyway (NEWCON:). VMS uses arrow keys also (another thing I like about it), and the remaining time that I spend on UNIX, I use only a subset of the available history commands. Of course, the point is moot. There are commercial shells that do all this. (now how come I haven't seen TOPS or Lisp machine users clamoring for command and argument completion? That would be a nice hack :-) Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) Can you "Spot the Looney"?
garyo@prometheus.think.com (Gary Oberbrunner) (03/22/89)
Leo writes: > (even with a wildcard expander in a shared library, you still have to > write code to call it). Well yes, but so do you with normal arg parsing. I mean, how many different forms of (for arg = *argv; argc > 0; argc--, arg++) if (<arg is a file>) <process the file>; else ... blah blah blah... have you seen in your life? Dozens at least, I'd bet. Besides, a shared library wildcard routine can be patched out to suit the user's preferences, unlike a shell which has to be rewritten. Not to mention that local wildcards can be expanded over any name space, if done right. Just MHO, my 2 cents worth. -- As always, Gary ----------------------------------------------------------------------------- Remember, Truth is not beauty; Gary Oberbrunner Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo Knowledge is not wisdom; Love is not music; garyo@think.com Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265
jesup@cbmvax.UUCP (Randell Jesup) (03/22/89)
In article <6342@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >>Oh, come on. Just how many users new to the amiga are EVER going to >>think of using "#?" for a wildcard?? '*' is VERY widely used and >>accepted, in Unix, MS-DOS and other operating systems. It was 3-4 Well, I can think of a major SF book published in the last year that used #? for "anything". This book didn't have much to do with computers at all, it was essentially an aside. Perhaps the writer is an Amiga user. >>Dreadful Unix syntax indeed. Unix is a relatively simple design, >>through and through. Unix is intended to be functional, simple, but >>powerful. And that it is. Unix is not intended to cater to users who > >Well, I actually got the impression that (at least under BSD systems) >there was a certain amount of evolution, and actual disagreements >over command syntax...the find command and the print spooler >somehow pop into my mind. Most Unixes I've seen tended to have a lot of historical cruft and varying syntax, depending on which command/institution/whatever wrote the command in question. Some are position-dependant in their parameters, others aren't, some require - for options, some don't, some specify strings with -xstring, others with -x string, some allow -abcdef, others want -a -b -c -d -e -f, etc, etc. I admit that once you have a bunch of EP on a Unix it all seems fairly straightforward, but it's easy to forget all the man-page reading, and snooping scripts, and manual reading, and learning tricks from wizards, and (gasp) reading source. >>So? Either the shell builds an incredibly long line and pulls the >>parameters from it to pass to the program, or you pass the program the >>command line directly (as the CLI does) and the program builds the >>same incredibly long line. Big lot of difference it makes. > >Actually, since my wildcards are implemented in the program, >via a shared library call, what I do is > >call 'compile pattern' with my expression, >then loop calling 'next match' until it tells me that >no more matches are available. The long line problem As andy says, if you do expansion as needed (call "get next matching file" you lose all the command-line-buffer size problems, get faster response, and makes it easier to deal multi-directory wildcards (ala VMS "..." wildcard - the Unix equivalent is `find` with a bunch of options - not easy for a beginning user to grok (or even an intermediate one), putting aside the command-length problems.) >>'`' in csh to delimit a string which is to be parsed, executed as a >>command (in a subshell), and its output to replace the `command` on >>the command line. An extremely powerful feature which AmigaDOS has >>nothing to compare to. > >The standard AmigaDOS CLI commands can get their arguments from >a pipe or a file, as well as from the command line. The primitives >are there. You can write a shell that does that. I did. Jay Ts did. (Jay wrote Tshell, a nice commercial unix-csh clone.) >! is rather overloaded character. I hate having to type all those >\ or slip into sh when I want to do a bunch of UUCP mailing. >The AmigaDOS IF statement allows you to use the NOT keyword to reverse >the sense of an expression. You are correct that history substitutions >are too complicated, though :-) I usually just bring back the line, >edit it, and hit return, rather than count arguments. And, I do >this from both AmigaDOS 1.3 Shell and Unix. I truely HATE the usage of ! in csh. It annoys me no end (ditto for escaping other special characters). I tried to exorcise as much of that as possible when I wrote my shell for the amiga. Sorry for extending this discussion. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.hackercorp.com (Peter da Silva) (03/22/89)
A reason for putting wildcards in the shell that hasn't been brought up yet:
If you do the wildcard expansion in the program, then there's really no way
to predict just how another program is going to do it. Under UNIX, I know that
if I 'execl("/usr/local/random_program", "random", filename, 0);' then that
program will correctly interpret the filename as a filename. It won't barf
because it's got spaces in it, or because it's got a '*' in it (or a '#', for
that matter), and so on.
Even if I use "system" to run the program, I know that I can quote any funky
characters in the filename with quotes or backslashes and it'll work. If I
pass a quoted string to a random program on the Amiga (or MS-DOS, or any other
system where the expansion is done by the program) I never know what it'll do.
Speaking of quoting, how many of you are aware that '*' is the 'literal-next'
character in AmigaDOS? It's not surprising, since that's how it works in BCPL,
and it's documented... but how many folks out there honor it?
Why would you need it? What if you have a file with any one of '#?"' in it? How
do you quote that?
--
Peter "Have you hugged your wolf today" da Silva `-_-'
...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`deven@pawl.rpi.edu (Deven Corzine) (03/23/89)
In article <6342@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: [This was a heavily sarcastic article, intentionally so. However, I'm not usually so acerbic, really. :-)] >>Oh, come on. Just how many users new to the amiga are EVER going to >>think of using "#?" for a wildcard?? '*' is VERY widely used and >>accepted, in Unix, MS-DOS and other operating systems. It was 3-4 >Well, due to reasons beyond our control, the AmigaDOS manual is >published seperately. However, the book that came with your >500 did tell you of its existance. I agree that it should >have told about the wildcards. Fortunately, there's a simpler >solution to the problem than switching to Unix....we can update >the manual. That would make for a huge improvement. (Make a better index!) >>I want Unix on an Amiga. What's wrong with that? Unix is a >>well-designed, well-thought-out operating system, with a simple and >>elegant paradigm. AmigaDOS is clumsy and obstrusive. I like the >>Amiga hardware. Exec is excellent. AmigaDOS sucks. Intuition I'd >>rather replace, but it's livable. As far as I'm concerned, I don't >>want to put up with using AmigaDOS as it is more than I have to. You >>like AmigaDOS? Fine. Use it. I want something fairly close to Unix >>myself. On an Amiga. >Nothing's wrong with wanting Unix on an Amiga. Freedom of choice >is an important concept. That's one reason why we have the >A2500 UX, after all. But liking Unix a lot doesn't automatically >mean that AmigaDOS is bad. No, it doesn't. I have specific reasons why I think AmigaDOS is bad, the only relevance to Unix being that Unix often does it better. >I personally don't have a problem with regular expressions >for my pattern matching. I do want it on all the commands >that it makes sense to have it; a shared library will be the >desired method of implementation, rather than pack it into the shell. I'm not opposed to regexp file-matching, but I do consider a single character match-all wildcard to be a necessary expedient. '*' is preferably because it is widely used and accepted. But SOMETHING. I AM opposed to using so obscure a wildcard as #? and not making it clear that's what it is. >(creating very long command lines has some problems, as does >those commands that don't want pattern matching) True. >>Dreadful Unix syntax indeed. Unix is a relatively simple design, >>through and through. Unix is intended to be functional, simple, but >>powerful. And that it is. Unix is not intended to cater to users who >Well, I actually got the impression that (at least under BSD systems) >there was a certain amount of evolution, and actual disagreements >over command syntax...the find command and the print spooler >somehow pop into my mind. There are exceptions, of course. Find is a notable one. But overall, it is pretty consistent. Far more consistent than AmigaDOS. >>really want an AmigaDOS interface, you could write a Unix shell which >>would look like AmigaDOS. I, for one, would never want to. >You mean, if you want a Amiga CLI and Amiga CLI type interface. Basically, yes. I was referring to "AmigaDOS" instead of "AmigaDOS CLI" in the article to refer to the AmigaDOS CLI along with the programs (BCPL) which are used with it. The CLI alone is a pathetically simple and rather clumsy shell. It can not stand alone; it needs the external programs. >The AmigaDOS interface is based on Exec message passing, tasks, >and lightweight tasks. >By the same token you can implement a Unix shell interface on >top of AmigaDOS. In fact, you've even used some of them. AmigaDOS *does* have some good design features. My opinion happens to be that the design flaws outweigh the design features... >>The command syntaxes are concise, not verbose. *Most* people I've >>known find they far prefer the syntax once they finally learn it. I >>know I don't like having to type things like "format df0: name newdisk >>noicons" just to format a disk. >The Unix command to format a disk (at least on my Sun 2) involves >bringing the Sun down, running a special program called diag, >then bringing the system up again. Then I generally run >/etc/newfs [ -N ] [ -v ] [ -n ] [ mkfs-options ] block-special-file >(since I seldom need to get into mkfs) >How is this easier than format ? Format was a poor example for comparision; format is a common everyday command for an Amiga. Not so for Unix. The point was that AmigaDOS BCPL program generally make you type more than you should have to. >>As far as vi goes, I *like* vi. It is a good editor and in widespread >>use. I'd much rather use it than C-A's "ED"... (And I have never >>seen a *good* implementation of vi for the Amiga... *sigh*) >So do one. Strikes me as something that a decent programmer >and VI user could whip right out. I'm an emacs user. So >one of the first things I did was port a version of microemacs, >and adjust it so I was happy. I've considered it, but I've been converted; I switched to Emacs months ago and can't easily go back. And mg is pretty good, but too big. I'm not currently interested in making an effort to try to port real GNUEmacs to the Amiga. I'm sure someone will try it sooner or later. When I have an Amiga w/8M ram, 68030 and 80M HD, then I'll worry about it. :-) >>So? Either the shell builds an incredibly long line and pulls the >>parameters from it to pass to the program, or you pass the program the >>command line directly (as the CLI does) and the program builds the >>same incredibly long line. Big lot of difference it makes. >Actually, since my wildcards are implemented in the program, >via a shared library call, what I do is >call 'compile pattern' with my expression, >then loop calling 'next match' until it tells me that >no more matches are available. The long line problem Oh, so Examine()/ExNext() was your idea, then? ;-) >>Or, you could write a shell with such a rename command builtin, since >>it handles the wildcard expansion to begin with. >This is not in the spirit of the Unix commands...which are supposed >to be small things, each doing a job, which you can link together >to form more powerful commands. If you find yourself saying >that you can always build it into the shell... I'm afraid I must agree with you here. It doesn't belong in the shell. But you *could* put it there. Or you could choose a wildcard that won't need to be escaped... >>'`' in csh to delimit a string which is to be parsed, executed as a >>command (in a subshell), and its output to replace the `command` on >>the command line. An extremely powerful feature which AmigaDOS has >>nothing to compare to. >The standard AmigaDOS CLI commands can get their arguments from >a pipe or a file, as well as from the command line. The primitives >are there. Not nearly as flexible as `command` and of limited value. Also rather clumsy. >>'!' in csh, when used in expressions, as a logical NOT. Again, no >>equivalent in the AmigaDOS CLI (or AmigaShell) because it has no >>ability to handle expressions. More importantly, it is used for >>history substitutions in the csh. They are too complicated and >>powerful to be explained here. >! is rather overloaded character. I hate having to type all those >\ or slip into sh when I want to do a bunch of UUCP mailing. >The AmigaDOS IF statement allows you to use the NOT keyword to reverse >the sense of an expression. You are correct that history substitutions >are too complicated, though :-) I usually just bring back the line, >edit it, and hit return, rather than count arguments. And, I do >this from both AmigaDOS 1.3 Shell and Unix. Agreed, ! is overloaded. But I DO often use !$, for example. Like when I'm unsharing amiga sources/binaries from the net: mkdir program cd !$ unshar ../!$.post rm !$ etc. Can't do that with the CLI or AmigaShell. And it's very tiresome to use the history editing newcon: provides. (At least for that sort of thing. For fixing typos, it's fine.) >[metachar discussion deleted for space reasons; also because I'm >beginning to suspect you don't have the AmigaDOS manual.] Try again. I have the AmigaDOS manual. >>In csh, you have user home directory lookup, executing command(s) in a >>subshell and using the output as command line parameters, history >>that is just one common Unix shell. You can easily rewrite the shell >>to suit you if you wish. Without changing the programs you run. >So what you are saying is that because csh is more powerful, >that AmigaDOS is useless ? You *can* write a csh type >program on the Amiga. Matt did it. Randell did it. Jay >Tees did it. Bill Hawes did it... This then, should be >a shell discussion. The shell is not AmigaDOS. No, I'm saying that bitching about all the special characters in Unix shells and saying how bad it would be if the CLI was like that is rather silly... there ARE many special characters, because the shell DOES a lot for you. The AmigaDOS CLI does virtually nothing, and it shows. The shell is not AmigaDOS, and the CLI is the shell. But, AmigaDOS IS designed to cooperate with the CLI, and the external commands such as cd and all the rest of out BCPL pals are designed solely for the CLI. (Well, AmigaShell also, now.) So, I refer to "AmigaDOS" as a convenient shorthand for "the AmigaDOS CLI and associated BCPL programs". I understand the distinction. I didn't see much point in overelaborating on that point. (I was too busy overelaborating on the metacharacter point! :-) As far as Matt's shell goes... honestly, I was unimpressed by it. It was relatively simple, and while a vast improvement over the CLI (doesn't take much) it could have been far better. I only have an ancient version of Randell's shell, and it is remarkably similar to Matt's. I don't know how good the current version is. I have no clue who Jay Tees is. WShell (isn't that the one Bill Hawes wrote?) does sound to be a step above some others, but I've never used it, myself. I can't form an informed opinion on hearsay. >Because replacing the shell is more difficult under Unix >(though not having written a Unix shell from the ground up, > but only making some minor hacks on tcsh I can't really say > for myself just how hard or easy it truly is) Writing a Unix shell that does as much as the AmigaDOS CLI would take probably about 20 minutes. >>need to replace the shell. You can not do the same with AmigaDOS. I >>like Unix, I want Unix on the Amiga. And there's no way you'll ever >>convince me AmigaDOS is a superior system. >You're right. Until you get the AmigaDOS manuals, and learn what >it is actually all about, and get 1.3, and the 1.3 manual, and >read the manuals, there's no hope of telling you anything. >And actually, convincing you would serve no purpose anyway. I've got the manuals, I use 1.3. I am extremely openminded; I will listen fairly to anything anyone has to say. (within limits) I have spent a great deal of time poring over the AmigaDOS manual (which was not so well written) and I just don't like a lot of things about AmigaDOS. True, FFS fixes a lot of the old file system's problems, but I don't think it's enough. As for whether it's worth trying to convince me of anything... well, it's not for me to dictate what you do. I doubt you can convince me that the AmigaDOS environment is superior to the Unix environment. I acknowledge that AmigaDOS IS improving, but it's got a long way to go. >>So there. >It's getting about that time; put your programming time where your >keyboard is. Produce the csh clone of your dreams. Clone >the Unix programmer interface, the Berkley Fast File system, >whatever other parts of Unix you like. Anything you want. Since >there's no way anyone can convince you of any redeeming characteristics >of AmigaDOS, you're skills must be complete...its time to stop >wasting time in discussions like this, and time to start coding. If you paid attention to the thread in comp.sys.amiga.tech, you would realize I intend to do exactly that. I'm doing the Unix (V7 to begin with, probably will add SysV & BSD & amiga extensions) programmer interface first, including fork() and exec(). To begin with, it WILL call AmigaDOS for the actual file system, until I have time to write my own file system. I don't want to clone the Berkeley Fast File system; there are things I could see improving upon. AND ideas to pull from AmigaDOS. I never claimed AmigaDOS we *totally* worthless; merely that it should be far better. Actually, my skills ARE fairly complete, though there is always more to be learned. (not that I can likely convince you that that's true...) (your grammer could use some work, however. [re: "you're skills"]) Discussions like this are of little value. I'm not going to waste time indefinitely in useless flame wars. However, some discussion remains before I begin serious coding. It is difficult to write reliable code when the manuals are sketchy and ambiguous. I am clearing up the ambiguities now. Then, we shall see. Unfortunately, my time may be severely limited soon, due to mundanities, like paying off debts, working, generally trying to survive. But it won't stop me; it will only slow me. (How much, I can't predict.) You have made a pretty clear challenge. It is a challenge that shall not go unanswered, of that you may be assured. Timeframe unspecified, but code shall be forthcoming. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
rap@ardent.UUCP (Rob Peck) (03/24/89)
In article <DEVEN.89Mar23010115@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) writes: > > I've got the manuals, I use 1.3. I am extremely openminded; I will > listen fairly to anything anyone has to say. (within limits) I have > spent a great deal of time poring over the AmigaDOS manual (which was > not so well written) and I just don't like a lot of things about > AmigaDOS. True, FFS fixes a lot of the old file system's problems, > but I don't think it's enough. > Just in case you've never become aware of it... the Programmer's Guide To the Amiga (which I wrote) dedicates an entire chapter to the use of the publicly accessible commands of AmigaDOS. As for the C: directory commands, the Amiga Companion, available now from Amiga World, covers the commands and their options -- what the AmigaDOS (Users) Manual shoulda been. The second edition changes have been sent to the editors and they oughta be announcing second edition general availability (including dealers) RSN :-) Second edition will prolly carry a slightly higher price tag because of a major expansion to fully describe the 1.3 command templates and new options, replacing entirely any references to 1.2 in the process. (often "experienced" users cease reading or browsing Amiga World, so they might not become aware of certain things only advertised therein). Wanted to let you know about other possible sources of info. Rob Peck
andy@cbmvax.UUCP (Andy Finkel) (03/24/89)
In article <DEVEN.89Mar23010115@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes: >In article <6342@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >Actually, my skills ARE fairly complete, though there is always more >to be learned. (not that I can likely convince you that that's >true...) (your grammer could use some work, however. [re: "you're >skills"]) Discussions like this are of little value. I'm not going to >waste time indefinitely in useless flame wars. However, some I'm please you have accepted the challenge you've been leading up to. (no, not the 20 minute CLI, the Unix style interface) I look foward to seeing what you come up with. I certainly do agree that flame discussions about wildcards is wasted, which is why I *finally*, after what seemed like hundreds of messages of argument, posted something which I hope will end the thread. By the way, whenever you find yourself commenting on the grammer and/or spelling of a poster who disagrees with you (especially those little ones that are caused by quick typing :-) you should realize that your posting just aquired a negative informational content, and you should take out your handy editor and remove the offending lines so the momentary lapse into cheap shots does not go beyond your own terminal. Why, though I was tempted to respond in kind, you will find no trace of it here. >discussion remains before I begin serious coding. It is difficult to >write reliable code when the manuals are sketchy and ambiguous. I am >clearing up the ambiguities now. Then, we shall see. and .tech is the place for that discussion; I've even anwered your questions a couple times. I think we both agree that the place for the endless flame about #? vs * is nil: So get to work :-) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Operating systems are like television shows. Amiga OS is like ST-TNG, Mac OS is like LA Law and OS/2 is like the Rosanne Bar show." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
deven@rpi.edu (Deven Corzine) (03/24/89)
In article <5149@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes: >Just in case you've never become aware of it... the Programmer's Guide >To the Amiga (which I wrote) dedicates an entire chapter to the use of >the publicly accessible commands of AmigaDOS. As for the C: directory >commands, the Amiga Companion, available now from Amiga World, covers >the commands and their options -- what the AmigaDOS (Users) Manual >shoulda been. The second edition changes have been sent to the editors >and they oughta be announcing second edition general availability >(including dealers) RSN :-) Second edition will prolly carry a >slightly higher price tag because of a major expansion to fully >describe the 1.3 command templates and new options, replacing entirely >any references to 1.2 in the process. I am indeed aware of your book, though I have not ever actually seen it. I have heard praise from many concerning it, however. I have a different Sybex book, "Amiga Programmer's Handbook" by Eugene P. Mortimore. I haven't used it much yet, but it does loot to supplement the RKM's nicely... It fills some gaps. I'm not too worried about the C: commands and the AmigaDOS User's Manual... I'm far more interested in the programming aspect. I'll probably get your book when I have the chance... >(often "experienced" users cease reading or browsing Amiga World, so >they might not become aware of certain things only advertised therein). >Wanted to let you know about other possible sources of info. Mmm. Thanks. I haven't read AmigaWorld much recently more because of lack of money to even buy magazines or ready transportation to bookstores where I can get away with hanging around reading their magazines without buying them... :-) One of these days... Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
pds@quintus.UUCP (Peter Schachte) (03/25/89)
[ Note: I wrote this a week ago, but our posting SW was screwed up, so I'm posting it now, somewhat edited. It still seems like a good idea to me. ] In article <10260015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: [ about using wildcards in a copy command ] >In Unix, it would be a detail of the shell, not the program. > >Unix commands do not have consistent option specifications, but they ARE >consistent, as the user sees them, when it comes to wildcards. This, of >course, is because most of them don't deal with wildcards at all, because >they know the shell is there to do it for them. This is true. But having the shell do wildcard expansion is a double-edged sword. In AmigaDOS, you can type 2> zoo x foo README *.doc *.man whereas under unix, you must write % zoo x foo README '*.doc' '*.man' It has been suggested that shared library routines be written that enumerate files matching a given pattern. Peter da Silva pointed out recently that if you do this, then programs that launch other programs don't have a convenient way to pass arguments that might contain wildcard characters. This is particularly serious because it is likely that hackers will patch in their own wildcard-matching code, so programs can't really guess what the wildcards ARE. I'd like to propose an alternative approach that solves this problem, and has a few other nice properties, too. First, the wildcard matching routines should be written and included in a library (exec?), and the other routines I describe below should use them through the library base, so that people CAN patch in their own wildcard matching code. Additionally, the shared library should supply standard routines called InitArguments(), NextFileArgument() and NextNonfileArgument(). They would be used like: main(argc, argv) int argc; char **argv; { char *arg; InitArguments(argc, argv); while ((arg=NextFileArgument()) { ... do stuff with arg ... Here are the nice properties of this approach: 1. It solves the wildcard problem. The system does the wildcard expansion for you. And it doesn't do it if you call NextNonfileArgument(). 2. It is an interface that can be used for both CLI and Workbench. I think it is very important that this be achieved, however it is done. Of course, this doesn't do anything for the harder problem: a common interface for launching CLI and WB applications. 3. It actually allows programs to be controlled by other programs, given a few more library routines to spawn such a program and feed it arguments (which would solve the hard problem mentioned in #2). The controlling program could feed the controlled program its arguments one at a time, as it determines them. It's not as sophisticated as AREXX, but it's free: the controlled program doesn't have to do anything special to be controlled. Say the program in question is a compiler. It is written to compile many source files, and your editor spawns it and feeds it the name of your source file every time you ask it to. And the compiler complies by compiling. The controller can tell the task is completed when the controlled program asks for the next argument. (We have to be really careful here, since the controlled program may be collecting all the arguments, waiting for the last one before it does anything. There should be a way for a program to specify that it is doing this. Still, many programs do fully process one argument before moving on to the next.) 4. It allows arbitrarily many arguments to be passed. In unix, there is a limit on the number of characters in a command AFTER FILENAME EXPANSION. This approach doesn't have that flaw. This is a very rough sketch. I could be more specific if anyone is interested. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
deven@pawl.rpi.edu (Deven Corzine) (03/25/89)
In article <6391@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >I'm pleased you have accepted the challenge you've been leading up >to. (no, not the 20 minute CLI, the Unix style interface) It was my intention all along. And I'm not one to pass up a challenge if it suits me not to. :-) [nice 'n' arbitrary that way... :-)] >I look foward to seeing what you come up with. I certainly >do agree that flame discussions about wildcards is wasted, >which is why I *finally*, after what seemed like hundreds of >messages of argument, posted something which I hope will >end the thread. what something be that? [maybe I'll see it] >By the way, whenever you find yourself commenting on the grammer >and/or spelling of a poster who disagrees with you (especially >those little ones that are caused by quick typing :-) you should >realize that your posting just aquired a negative informational >content, and you should take out your handy editor and remove >the offending lines so the momentary lapse into cheap shots >does not go beyond your own terminal. Why, though I was tempted >to respond in kind, you will find no trace of it here. Well, I figured, while I'm being nitpickety and obnoxious, I might as well go the whole route. :-) Usually, I just ignore it or take editorial liscense and fix typos when quoting. (Along with margins, often, for legibility...) >>discussion remains before I begin serious coding. It is difficult to >>write reliable code when the manuals are sketchy and ambiguous. I am >>clearing up the ambiguities now. Then, we shall see. >and .tech is the place for that discussion; I've even anwered your >questions a couple times. I think we both agree that the place >for the endless flame about #? vs * is nil: .tech certainly is the place, and that is why I've posted there. And yes, you've made some points. Randell has been an enormous help in clarifying issues. Flame wars about #? vs. * to /dev/null. :-) However, I STILL think C-A should implement * as an option... (can base it on context) >So get to work :-) I am, I am. :-) Soon. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (03/29/89)
In article <976@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >... the wildcard matching routines should be written and included in >a library .... the shared library should supply >standard routines called InitArguments(), NextFileArgument() and >NextNonfileArgument(). .... The idea is a good one, but the interface could be cleaner. Instead of being a \new/ set of routines, it should be an extension to the standard getopt() routines -- they are already used to scan the argument list, and it would be simple to define an additional set of routines that work with them. It might even be possible to cause the default invocation (that is, not using the extra semantics) to automagically expand any wildcards, although that would be tricky and potentially hazardous..... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
pds@quintus.UUCP (Peter Schachte) (04/05/89)
In article <1189@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: >In article <976@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >>... the wildcard matching routines should be written and included in >>a library .... the shared library should supply >>standard routines called InitArguments(), NextFileArgument() and >>NextNonfileArgument(). .... >The idea is a good one, but the interface could be cleaner. Instead of >being a \new/ set of routines, it should be an extension to the standard >getopt() routines This was my first thought. It still seems like a good idea overall, but it has fatal 2 drawbacks: it puts constraints on argument ordering and option style, and it alters the flow of the program. There are two ways you may want to write your main(): find all the switches first, handle them, and then handle all filename args. Or you may want to just step through the args as they come, deciding whether they are switches or filenames, and handling them. The second approach fits much better with what I'm trying to accomplish here, since it allows arguments to be passed as a stream. For example, you'd want a compiler to take multiple file names, resetting its state between them, so that your editor could fire it up over and over. main() might look like: { char *arg; reset_switches; for (;;) { if (!(arg = NextArg(...))) exit; if (*arg == '-') { handle_switch(++arg); } else { compile_file(arg); reset_switches; } } } I don't think this approach would work with getopt(). I realize that I'm reinventing the wheel, but a different wheel. I don't see how this could fit in with getopt(). But I could be all wet: I must admit I've never actually USED getopt(). -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds