higgin@cbmvax.UUCP (Paul Higginbottom MKT) (02/16/89)
In article <DEVEN.89Feb14055924@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes:
$I still find some definite problems with the AmigaDOS method of file
$system structuring. I find "." and ".." far easier to use
$effectively, even if they are more to type. "" as current directory
$is obnoxious, if you ask me.
As someone else mentioned; it's mainly a question of what you're used to.
It's a fairly easy translation:
UNIX AmigaDOS
.. /
. ""
/ :
My only problem with "" and : is that they're shifted characters which is
harder to type (for me).
$There is no easy equivilent for "./file" under AmigaDOS...
This is surely rather unimportant as the current directory is usually
searched FIRST anyway.
$I don't understand at all the objection to Unix wildcards.
Neither do I, except I find "." files obnoxious, i.e., "*" doesn't
match them so to clean out a directory with some files which start with
. you have to do "rm * .*" (don't you?).
$Next time, please get your facts straight before flaming as fine an
$operating system as Unix is. Or hold your flames.
Settle down (do I smell religion?).
Paul.jwright@atanasoff.cs.iastate.edu (Jim Wright) (02/17/89)
In article <5985@cbmvax.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom MKT) writes: }In article <DEVEN.89Feb14055924@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes: }$I still find some definite problems with the AmigaDOS method of file }$system structuring. I find "." and ".." far easier to use }$effectively, even if they are more to type. "" as current directory }$is obnoxious, if you ask me. Me too. }As someone else mentioned; it's mainly a question of what you're used to. So why should the Amiga be the only one different? Yes, it is an easy translation, but can't you think of a few more important bits of information to stash away in your long-term memory? I'd think that using a convention which already exists, and which people are accustomed to, is a good marketing strategy. (Sorry :-) }$There is no easy equivilent for "./file" under AmigaDOS... } }This is surely rather unimportant as the current directory is usually }searched FIRST anyway. From the WShell manual: The full search heirarchy followed by WShell is * The Previous Command * Resident Commands * Built-in Commands * REXX-Language Macro Programs * An Implicit Directory --> * The Current directory * The Local Path Directories * The Global Path Directories. I won't argue the use of the word "usually". Shall we agree that there are many situations where having an equivalent for "./file" is important? }$I don't understand at all the objection to Unix wildcards. } }Neither do I, except I find "." files obnoxious, i.e., "*" doesn't }match them so to clean out a directory with some files which start with }. you have to do "rm * .*" (don't you?). If you want to delete the directory, go down one level and type "rm -r dirname". This will take care of "*", ".*", and subdirectories too. Nasty sort of a command. :-)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/19/89)
[much discussion about Unix vs. Amiga wildcards] In <805@atanasoff.cs.iastate.edu>, jwright@atanasoff.cs.iastate.edu (Jim Wright) writes: >So why should the Amiga be the only one different? Yes, it is an easy >translation, but can't you think of a few more important bits of information >to stash away in your long-term memory? I'd think that using a convention >which already exists, and which people are accustomed to, is a good >marketing strategy. (Sorry :-) This can be a good idea. However, should this thinking have taken place during the design phase of Amigados, we might have been saddled with an even more popular convention, that used by MsDos. Imagine that, and count your blessings. >From the WShell manual: > The full search heirarchy followed by WShell is > * The Previous Command > * Resident Commands > * Built-in Commands > * REXX-Language Macro Programs > * An Implicit Directory > --> * The Current directory > * The Local Path Directories > * The Global Path Directories. >I won't argue the use of the word "usually". Shall we agree that there >are many situations where having an equivalent for "./file" is important? Shall we agree that shells are not necessarily Amigados in their conventions? There is nothing to stop a shell from having any convention, whether it be Amigados, Unix, MsDos, or even <shudder> IBM's JCL. It has been pointed out to me via mail that the resident commands are searched first. To this I answer that obviously the resident facility was added without consideration of the fundamental Amigados convention of searching the current directory first. I work on Unix during the day, and the Amiga at all other times, and find no inherent superiority in either one, save for minor conveniences in each. They are just different is all, and if you don't like the way one or the other does something, well, that's what shells and script files are for. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
deven@pawl.rpi.edu (Deven Corzine) (02/20/89)
In article <5985@cbmvax.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom MKT) writes: >In article <DEVEN.89Feb14055924@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes: >$I still find some definite problems with the AmigaDOS method of file >$system structuring. I find "." and ".." far easier to use >$effectively, even if they are more to type. "" as current directory >$is obnoxious, if you ask me. > >As someone else mentioned; it's mainly a question of what you're used to. >It's a fairly easy translation: > > UNIX AmigaDOS > .. / > > . "" > > / : > >My only problem with "" and : is that they're shifted characters which is >harder to type (for me). First off, . to "" is NOT such a simple translation, because shells won't usually pass the quotes without quoting THEM. I see : vs. / for root as more of a preference issue, but I prefer /. I don't like / for the parent directory. It's just weird. But that's preference, as well. Matt Dillon argues that "/" is much easier to type for parent directory. That may be, but going back more than one directory is fairly uncommon in my experience, and I'd rather use "../file" than "/file" to refer to a file in the parent directory. It is clearer and less prone to error. (Accidental keybounce on the /, etc...) >$There is no easy equivilent for "./file" under AmigaDOS... > >This is surely rather unimportant as the current directory is usually >searched FIRST anyway. Unimportant, hell. *Maybe* I don't WANT to have the current directory searched first. Did you ever consider that? The AmigaDOS path is hardcoded to search the current directory first, and C: last. Yes, various shells will do their own path searching for you, but they are usually overlaid on a CLI or AmigaShell, and often use the AmigaDOS path if the internal path fails. And yes, you could specify "" for the current directory in the path specification, but you never know for sure where quotes will and won't be stripped and by what rules. "." is never simply dropped into never-never land as "" can easily be. Also, for the record, you CAN use "" under Unix to refer to the current directory. If you really want to. >$I don't understand at all the objection to Unix wildcards. > >Neither do I, except I find "." files obnoxious, i.e., "*" doesn't >match them so to clean out a directory with some files which start with >. you have to do "rm * .*" (don't you?). Under Unix, "*" normally does not match files which begin with a "." by convention. It's a special case. ("dot" files are considered "invisible" files) So the Unix shells normally don't match dot files unless specifically requested to by ".*" or some such. It's a safety mechanism to protect you from accidentally deleting files you may not want to. Again, Unix is designed such that you can easily replace the shell, which is not so trivial a task on the Amiga. Also, the fact that most Amiga shells run under a CLI is a horrible kludge in my book. >$Next time, please get your facts straight before flaming as fine an >$operating system as Unix is. Or hold your flames. > >Settle down (do I smell religion?). Oh, only a little religion. It's mostly this "Unix couldn't match *.REL so it sucks" sort of crap that bugs me. It is just such a gross misrepresentation that it disgusts me. > Paul. 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.
higgin@cbmvax.UUCP (Paul Higginbottom MKT) (02/22/89)
In article <DEVEN.89Feb19210907@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes:
$First off, . to "" is NOT such a simple translation, because shells
$won't usually pass the quotes without quoting THEM.
AmigaDOS shell does pass them.
$I see : vs. / for $root as more of a preference issue, but I prefer /.
^^^
Fine. Subjective Opionion (S.O)
$I don't like / for the parent directory. It's just weird. But that's preference,
^^^
$I'd rather use "../file" than "/file" $to refer to a file in the parent directory.
S.O
$It is clearer and less prone to error. (Accidental keybounce on the /, etc...)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
S.O. UNIX is MORE characters which would seem to make IT more prone to error.
I can see no reason why ../file is clearer than /file. It is clearer to one who
is more used for the former.
As for key bounce - it's been a while since I heard that as a reason to change
a DOS.
$Again, Unix is designed such that you can easily replace the
$shell, which is not so trivial a task on the Amiga.
But it has been done and many people are happy with the results.
$Also, the fact that most Amiga shells run under a CLI is a horrible kludge in my
$book.
UNIX has been around a bit longer than AmigaDOS :-) Also, HOW big is UNIX?
I guess I really shouldn't have replied... <more gasoline>. FYI I am a big UNIX
fan as well as an Amiga fan obviously, but having used so many different
"standards" and user interfaces over the years, I just kind of roll with the
differences. AmigaDOS, DOS, VMS, Ultrix, EMACS, vi, EDT, ed (--you choke--), etc.
Paul.jesup@cbmvax.UUCP (Randell Jesup) (02/23/89)
In article <DEVEN.89Feb19210907@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes: >I don't like / >for the parent directory. It's just weird. But that's preference, as >well. Matt Dillon argues that "/" is much easier to type for parent >directory. That may be, but going back more than one directory is >fairly uncommon in my experience, and I'd rather use "../file" than "/file" >to refer to a file in the parent directory. It is clearer and less >prone to error. (Accidental keybounce on the /, etc...) I often have to look and count ../'s to figure out how many levels I've gone up (I often need multiple ../'s). Personal preference, what you were raised on. > >$There is no easy equivilent for "./file" under AmigaDOS... > > > >This is surely rather unimportant as the current directory is usually > >searched FIRST anyway. > >Unimportant, hell. *Maybe* I don't WANT to have the current directory >searched first. Unix: ./file AmigaDos: file Easy equivalent. Concerning wildcards, the amiga wildcards are fairly versatile: '#', '?' and (...|...|...) can be very useful (yes, I know about {..,...}). I agree * is more convenient than #?, but the use of * as an escape is a holdover from the BCPL/TriPos heritage of AmigaDos (like \ is a holdover in unix shells from C). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
deven@pawl.rpi.edu (Deven Corzine) (02/23/89)
In article <6051@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: In article <DEVEN.89Feb19210907@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes: >I don't like / >for the parent directory. It's just weird. But that's preference, as >well. Matt Dillon argues that "/" is much easier to type for parent >directory. That may be, but going back more than one directory is >fairly uncommon in my experience, and I'd rather use "../file" than "/file" >to refer to a file in the parent directory. It is clearer and less >prone to error. (Accidental keybounce on the /, etc...) I often have to look and count ../'s to figure out how many levels I've gone up (I often need multiple ../'s). Personal preference, what you were raised on. True, it's mostly a matter of preference, but "." and ".." _seem_ more consistent, somehow. Regardless, seeing as how it's a matter of preference, and the is by no means a clear concensus, both styles ought to be supported. People seem about evenly split between Unix and AmigaDOS style conventions. Therefore, support both. No big problem. (Have an environment variable or equivalent to define which to use.) > >$There is no easy equivilent for "./file" under AmigaDOS... > > > >This is surely rather unimportant as the current directory is usually > >searched FIRST anyway. > >Unimportant, hell. *Maybe* I don't WANT to have the current directory >searched first. Unix: ./file AmigaDos: file Easy equivalent. Ghod. In one ear and out the other. You have missed the point entirely, just like everyone else saying "just use 'file' instead of './file' - they're the same!" They *NOT* equivalent!!! They are similar, and in many situations they are equivalent, but NOT in all situations. The most important example, which I have pointed out 3 or 4 times already, is in the case of path and resident list searching. In THAT case, "file" and "./file" are NOT equivalent. "file" is a basename. "./file" is a pathname. ONLY basenames should EVER be searched for in paths or resident lists. If you type "./ls" at a command prompt, what that says is "run THIS 'ls' program." No shell should ignore that very specific request by saying, "No, no. You want to run THIS one. See, it's resident - it's faster, so you MUST want to run this one!" Merely because a program has the same name as one which is resident does NOT mean they must be the same program. Such logic is absolutely inane. It might be a newer version, a test version, or a different program altogether. If the user specifically says "THIS "file" and no other" by using "./file", no shell or program should second-guess the user and ignore it. If, on the other hand, the user merely says "run 'ls'" by typing "ls", then the shell is quite within its rights to give precedence to a resident version rather than one in the current directory, as the request is ambiguous, and more likely than not, the resident one is the one the user desires to be run. If it is not, the user can explicitly override it with "./ls". Similarly, if the user says "c:dir", the shell should never run a "dir" in the resident list, OR a "dir" in the current directory. "c:dir" is very specific, and searching elsewhere should not be done. (In any of the above, replace "shell" with "CLI" if it suits you to do so. Or "AmigaShell". It applies equally.) THAT is why "./file" is NOT equivalent to "file". Unix AmigaDOS ---- -------- file file ./file -- "" "" . -- .. / / : There are NOT equivalents for all of them. There is no equivalent for "./file" - "file" is an equivalent for "file" (duh) but not for "./file". Similarly, "" is a equivalent for "", NOT for ".". There is no equivalent for ".". You can use "" for current directory in Unix. And it is perfectly equivalent to "" under AmigaDOS. But people use "." instead of "" under Unix because it is one less character to type, and it is more predictable. AmigaDOS's "" is NOT equivalent to Unix's ".", no matter how you might try to make it appear to be so. Essentially the concept of "." as current directory is completely unsupported under AmigaDOS at present. The concept of ".." is supported; merely the form differs. Concerning wildcards, the amiga wildcards are fairly versatile: '#', '?' and (...|...|...) can be very useful (yes, I know about {..,...}). I agree * is more convenient than #?, but the use of * as an escape is a holdover from the BCPL/TriPos heritage of AmigaDos (like \ is a holdover in unix shells from C). I don't argue that the AmigaDOS wildcards, WHEN SUPPORTED, are fairly versatile. They certainly are. But, #? as a "match-everything" wildcard is atrocious and entirely counter-intuitive. Sure, it's understandable given "# is for any number, and ? is for any character, so #? is for any number of any characters..." But it is NOT something that an AmigaDOS novice would EVER be likely to guess. It took me about a month to find out that #? was the brain-damaged wildcard, instead of a simple and obvious "*". I was an AmigaDOS novice, but by NO means a computer novice. I had used many other systems before, and had much experience with other operating systems, and regexp usage elsewhere. At the very least, SOME character - ANY character - should have been provided as a single-character equivalent for #?. It would not have been difficult to program, and would simplify things for people. "*" is by far the best choice, but using "&" or "@" or "~" or SOMETHING would be better than nothing. But, it's a bit late now. *sigh* (By the way, I spent hours searching the manuals that came with the A500 - they talked too much about the Workbench interface, and far too little about the CLI. There was no reference in ANY index to the wildcards available, and was mentioned ONCE in an obscure place, as I recall.) -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup (the From: line is wrong. mailing address is shadow@pawl.rpi.edu, not deven@pawl.rpi.edu.) -- ------- 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.
peter@sugar.uu.net (Peter da Silva) (02/23/89)
In article <6041@cbmvax.UUCP>, higgin@cbmvax.UUCP (Paul Higginbottom MKT) writes: > $Again, Unix is designed such that you can easily replace the > $shell, which is not so trivial a task on the Amiga. > But it has been done and many people are happy with the results. No, it hasn't. They ALL still depend on the CLI. I'm gonna have to write WBShell one of these days... -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
jesup@cbmvax.UUCP (Randell Jesup) (02/25/89)
In article <DEVEN.89Feb22210628@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >In article <6051@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > I often have to look and count ../'s to figure out how many > levels I've gone up (I often need multiple ../'s). Personal preference, > what you were raised on. > >True, it's mostly a matter of preference, but "." and ".." _seem_ more >consistent, somehow. Regardless, seeing as how it's a matter of >preference, and the is by no means a clear concensus, both styles >ought to be supported. People seem about evenly split between Unix >and AmigaDOS style conventions. Therefore, support both. No big >problem. (Have an environment variable or equivalent to define which >to use.) If it were just the shell, that could easily be done. The problem is that pathnames are dealt with directly by the handlers, which are not so easy to change, and if you did allow configuration, you'd end up with no end of problems where a program had pathnames one way and the system was configured the other. _If_ you can reliably tell which arguements/etc typed to a shell are pathnames, you could do translation. However, the programs would still report amigados-style pathnames, presenting lots of chances for confusion. This discussion is fairly useless. It is simply not practical to make major changes to the pathname syntax of an OS after it's been in the field, unless you're ready and willing to break everyone. (Sorry) Extensions to the syntax are possible at times, while breaking far fewer programs. So, how about suggesting ways to get the features you want, without breaking every program under the sun? A far more useful discussion, I think. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup