Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!harvard!caip!cbmvax!randy From: randy@cbmvax.cbm.UUCP (Randy Weiner) Newsgroups: net.micro.amiga Subject: Re: cd bug Message-ID: <275@cbmvax.cbmvax.cbm.UUCP> Date: Wed, 21-May-86 12:53:03 EDT Article-I.D.: cbmvax.275 Posted: Wed May 21 12:53:03 1986 Date-Received: Sat, 24-May-86 01:21:34 EDT References: <13147@ucla-cs.ARPA> <331@ulowell.UUCP> <13863@ucla-cs.ARPA> Reply-To: randy@cbmvax.UUCP (Randy Weiner) Distribution: net Organization: Commodore Technology, West Chester, PA Lines: 161 Keywords: ...long... 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 <> uucp: {ihnp4|seismo|caip}!cbmvax!randy arpa: cbmvax!randy@seismo (or) randy@cbmvax.UUCP@{seismo | harvard} TEL: 215-431-9180