Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: AmigaDos vs Unix wildcards/pathnames Message-ID: Date: 20 Mar 89 16:52:05 GMT References: <11241@ut-emx.UUCP> <6306@cbmvax.UUCP> <353@bnr-fos.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven Thomas Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 318 In-reply-to: schow@bnr-public.uucp's message of 19 Mar 89 10:26:57 GMT 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.