cc1@ucla-cs.UUCP (05/10/86)
There is a bug with cd that makes me wonder just how well directories work. cd df1: cd dir1 # now in sub directory # switch disks, put 1 in 0, 0 in 1 cd / # this should put you in df0: instead, it puts you in df1: Incidently, the current directory of the initial cli task is 'RDF0:', that is, whatever disk happens to be in drive 0 at the time, not sys: What I would like to see: The ability to specify 'RDF0:' (or similar) to mean 'Disk in there when you look' in other things as well. So, you could assign c: rdf0:c or assign c: path rdf0:c rdf1: and use whatever drives are on at the time. By the way, can 1.2 use 5" drives, or is that still only for the emulator? Final request: GET RID OF THE FIXED # OF FILES! This is the biggest problem I have with AmigaDos. Because of fixed # of files, filename expansion is useless. WORSE, if I wind up with 2 files, then because of the 'hidden to options' that 1/2 the commands have I wind up destroying something. PLEASE, get rid of all those 'TO' options. ADD the concept of a standard error output. And PARSE the input line to see what files you have. The setup for argc/argv can't be much more than your current arg passer, can it? Michael Gersten "There is nothing wrong with either the Mac or the Amiga that 4 meg can't fix" -- Views expressed here may not be those of the Computer Club, UCLA, or anyone.
page@ulowell.UUCP (Bob Page) (05/13/86)
In article <13147@ucla-cs.ARPA> Michael Gersten writes: >cd df1: >cd dir1 # now in sub directory ># switch disks, put 1 in 0, 0 in 1 >cd / # this should put you in df0: Huh? Doesn't cd / mean 'go up one level?' That would put you in df1:dir1 - dir1 = df1: >instead, it puts you in df1: Good! > >Incidently, the current directory of the initial cli task is 'RDF0:', >that is, whatever disk happens to be in drive 0 at the time, not >sys: The current directory of the initial CLI task is INITIALLY df0:, since the CLI can't assume you have any other devices. Well, and for other practical reasons. >What I would like to see: >The ability to specify 'RDF0:' (or similar) to mean 'Disk in there when >you look' in other things as well. So, you could >assign c: rdf0:c NO! This would create a lot of headaches with hashing and cacheing! Disk names are better than device names. Think generics. Also (and more importantly today, with the current CLI), the ASSIGN structure needs disk names, not device names. Try to ASSIGN to a non-existant disk. You can't, because ASSIGN asks the disk handler process to check & make sure it's there. >or >assign c: path rdf0:c rdf1: The PATH you want is coming, but you don't use ASSIGN. >and use whatever drives are on at the time. This defeats the purpose of MOUNTing disks! What if you slapped out your VAX's Eagle and put in another, with radically different files on it? Keep in mind ADOS isn't a fancy program loader, like many of the other micro 'operating systems' in use. >By the way, can 1.2 use 5" drives, or is that still only for the emulator? >Because of fixed # >of files, filename expansion is useless. You'd be better off complaining about Lattice C's arbitrary restriction of 32 arguments on a command line! > WORSE, if I wind up with 2 >files, then because of the 'hidden to options' that 1/2 the commands have >I wind up destroying something. >PLEASE, get rid of all those 'TO' options. Sounds like a job for a more unified command line syntax. Any takers? >ADD the concept of a standard error output. Wow. Sounds like a lot of work... and your asking the people who didn't even write the DOS. >And PARSE the input line to see what files you have. What does that mean? ..Bob -- UUCP: wanginst!ulowell!page Bob Page ARPA: page@ulowell.CSNET U of Lowell CS Dept VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA
vanam@pttesac.UUCP (Marnix van Ammers) (05/15/86)
In article <13147@ucla-cs.ARPA> occ4mgk@oac.ucla.edu, cc1@ucla-cs.UUCP (Michael Gersten) writes: >There is a bug with cd that makes me wonder just how well directories work. > >cd df1: >cd dir1 # now in sub directory ># switch disks, put 1 in 0, 0 in 1 >cd / # this should put you in df0: I don't know about the rest of the stuff you complained about, but the "cd /" puts you into the next higher directory. If you read the manual (Amiga Dos Manual I think), the '/' is not the same as in unix. It does not mean the root directory but the parent directory. In other words Amiga's '/' is equivalent to Unix's '..' . Marnix A. van Ammers
cc1@ucla-cs.ARPA (UCLA Computer Club) (05/21/86)
This requires a reply |> me | Bob Page In article <331@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: |In article <13147@ucla-cs.ARPA> Michael Gersten writes: |>cd df1: |>cd dir1 # now in sub directory |># switch disks, put 1 in 0, 0 in 1 |>cd / # this should put you in df0: | |Huh? Doesn't cd / mean 'go up one level?' That would put you in |df1:dir1 - dir1 = df1: | |>instead, it puts you in df1: | |Good! | Not good. I SWITCHED DISKS. Every reference except '/' refers to the disk now in drive 0. By the way, saying 'cd' prints the wrong directory in this case. |> |>Incidently, the current directory of the initial cli task is 'RDF0:', |>that is, whatever disk happens to be in drive 0 at the time, not |>sys: | |The current directory of the initial CLI task is INITIALLY df0:, since |the CLI can't assume you have any other devices. Well, and for other |practical reasons. | NOT df0:, it IS rdf0:. If you switch disks, it happily changes directory to the root of the new disk that you just put in. In other words, it has NO current directory. |>What I would like to see: |>The ability to specify 'RDF0:' (or similar) to mean 'Disk in there when |>you look' in other things as well. So, you could |>assign c: rdf0:c | |NO! This would create a lot of headaches with hashing and cacheing! |Disk names are better than device names. Think generics. Also (and |more importantly today, with the current CLI), the ASSIGN structure |needs disk names, not device names. Try to ASSIGN to a non-existant |disk. You can't, because ASSIGN asks the disk handler process to |check & make sure it's there. | And why can't you assign to a non-online drive? That would be grate--put them all in my startup-sequence. Remember, RDF0: is in there already, look at the startup-cli |>or |>assign c: path rdf0:c rdf1: | |The PATH you want is coming, but you don't use ASSIGN. | |>and use whatever drives are on at the time. | |This defeats the purpose of MOUNTing disks! What if you slapped out |your VAX's Eagle and put in another, with radically different files on it? |Keep in mind ADOS isn't a fancy program loader, like many of the other |micro 'operating systems' in use. | I still don't understand this. |>By the way, can 1.2 use 5" drives, or is that still only for the emulator? | |>Because of fixed # |>of files, filename expansion is useless. | |You'd be better off complaining about Lattice C's arbitrary restriction |of 32 arguments on a command line! | I wasn't aware of that. Uggh. But 32 is better than 2. |> WORSE, if I wind up with 2 |>files, then because of the 'hidden to options' that 1/2 the commands have |>I wind up destroying something. |>PLEASE, get rid of all those 'TO' options. | |Sounds like a job for a more unified command line syntax. Any takers? | Give me a copy of the source and I'll do it. |>ADD the concept of a standard error output. | |Wow. Sounds like a lot of work... and your asking the people who didn't |even write the DOS. | I'll help. |>And PARSE the input line to see what files you have. | |What does that mean? It means: Don't assume that the you only have one source file, or that the second file is the output. In otherwords, A. I should be able to delete an arbitrary # of files B. I should be able to type an arbitrary # of files into a destination C. I should be able to copy an arbitrary # into a directory etc. Look at UNiX. | | |..Bob |-- |UUCP: wanginst!ulowell!page Bob Page |ARPA: page@ulowell.CSNET U of Lowell CS Dept |VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA Michael Gersten ihnp4!ucla-cs!cc1 -- Views expressed here may not be those of the Computer Club, UCLA, or anyone.
randy@cbmvax.cbm.UUCP (Randy Weiner) (05/21/86)
In article <13863@ucla-cs.ARPA> occ4mgk@oac.ucla.edu, cc1@ucla-cs.UUCP (Michael Gersten) writes: >This requires a reply >In article <331@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >|In article <13147@ucla-cs.ARPA> Michael Gersten writes: >|>cd df1: >|>cd dir1 # now in sub directory >|># switch disks, put 1 in 0, 0 in 1 >|>cd / # this should put you in df0: In V1.2 this series of commands will put you in df0: In fact, if you remove the disk altogether, the system requests that you replace it. This works using either device names or volume names. >| >|Huh? Doesn't cd / mean 'go up one level?' That would put you in >|df1:dir1 - dir1 = df1: >|>instead, it puts you in df1: >Not good. I SWITCHED DISKS. Every reference except '/' refers to the disk >now in drive 0. In UNIX, it is not so easy to swap disks in and out (-:. CD and its use (in a strict sense) depend on a UNIX file environment, which AmigaDos is not. These inconsistencies were corrected in V1.2 and CD works as expected. >By the way, saying 'cd' prints the wrong directory in this case. > >|> >|>Incidently, the current directory of the initial cli task is 'RDF0:', >|>that is, whatever disk happens to be in drive 0 at the time, not >|>sys: >| >|The current directory of the initial CLI task is INITIALLY df0:, since >|the CLI can't assume you have any other devices. Well, and for other >|practical reasons. >| > Come on, the intial task has to start somewhere. It seems trivial to argue this point. You can change to any other directory. If you invoke a newcli, this becomes the new current directory. >NOT df0:, it IS rdf0:. If you switch disks, it happily changes directory >to the root of the new disk that you just put in. In other words, it >has NO current directory. > In V1.2, CD converts a drive spec (dfn:) to a volume name. If you move the disk to another drive, the system will still find it. And, if the current working directory is assigned to that volume, it remains on that volume. >|>What I would like to see: >|>The ability to specify 'RDF0:' (or similar) to mean 'Disk in there when >|>you look' in other things as well. So, you could >|>assign c: rdf0:c >| I don't understand what you are trying to accomplish?? >And why can't you assign to a non-online drive? That would be grate--put >them all in my startup-sequence. Remember, RDF0: is in there already, look >at the startup-cli > yes, the RDF0: is there, but so is the disk when the ASSIGN is executed. Instead of in startup-sequence, just create another batch file that performs the needed assignments. you can EXECUTE this as needed. I know, this is extra work and it would be nice if startup would handle it -- but it doesn't! >|>By the way, can 1.2 use 5" drives, or is that still only for the emulator? >| V1.2 will allow one to read and write Amiga files to the 5-1/4" drive. And, because these drives do not detect when a disk is removed/ inserted, a new DOS command, DISKCHANGE, has been added so you can alert the system. >|>Because of fixed # >|>of files, filename expansion is useless. >| I am missing something, what does this limit refer to?? > >|> WORSE, if I wind up with 2 >|>files, then because of the 'hidden to options' that 1/2 the commands have >|>I wind up destroying something. >|>PLEASE, get rid of all those 'TO' options. If a TO option is 'hidden', then it is an optional keyword. I have no control over changes to DOS. My guess is that this is something that will not go away. >| >|Sounds like a job for a more unified command line syntax. Any takers? >| I think the command line syntax is already unified. Almost every command that requires a source and destination file accept the FROM and TO keywords. This is not to say that this is the best implementation of a CLI, though. > >Give me a copy of the source and I'll do it. > The source for DOS is in BCPL -- do you have a BCPL compiler handy. I am not aware of any Amiga-native product. > >|>ADD the concept of a standard error output. >| Look at the startup file in RKM, volume 1, section 4 -- Workbench. It shows new startup that defines STDERR (to be stdout), but one can change this from within a program (not exactly portable). The problem with this is in trying to make STDERR usable from the Workbench environment. In this case, what would you define as the standard error output? Note, the Lattice startup always opens a default window (unless activated from a CLI) so there is always a place for standard OUT/ERR to go. But, a programmer can disable this (compile with the -dTiny option). In this case the user must provide an outlet for STDOUT/ERR or the system may crash. >| > >|>And PARSE the input line to see what files you have. >| One solution here is to install an input handler ahead of the DOS input handler. Then you can parse the line and pass along whatever. > >It means: Don't assume that the you only have one source file, or that the >second file is the output. In otherwords, This refers to what?? >A. I should be able to delete an arbitrary # of files One possibility is to use DIR OPT I, but not exactly what you want. Wildcard support for delete would be nice with an optional CONFIRM type mode, just in case. >B. I should be able to type an arbitrary # of files into a destination This can be simulated with a script file, just JOIN the files into a ram:temp file, then type this file. >C. I should be able to copy an arbitrary # into a directory This resolves to supporting wildcards in all commands! I wish!!! >Look at UNiX. But AmigaDos is NOT UNIX. ***************************************************************** These views may reflect the opinion of my employer, I don't know because I haven't checked. ***************************************************************** -- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Randy Weiner -- Commodore Business Machines <<Amiga Technical Support>> uucp: {ihnp4|seismo|caip}!cbmvax!randy arpa: cbmvax!randy@seismo (or) randy@cbmvax.UUCP@{seismo | harvard} TEL: 215-431-9180