linco@eng.umd.edu (Sam Lin) (12/23/89)
I have been experimenting with trying to make DOS 3.1 more UN*X-like, because it is a real pain switching between UN*X and DOS between my Sun and my PC. Recently, I got a hold of PICNIX3 from grape.ecs.clarkson.edu, and playing with the SWITCHAR command has yielded some interesting discoveries. When I use "SWITCHAR -" change the DOS switch character to '-', as one would expect, the command dir /w becomes dir -w. However, I discovered that the path separator also gets transformed from the brain-damaged '\' to the UN*X '/'!! Thus, if there is a directory called c:\tmp, typing dir c:/tmp works just as well as dir c:\tmp. Even more interesting, '/' now must be used as the path separator in the invokation of programs. '\' no longer works! Thus to invoke the program \util\emacs.exe, I have to type: /util/emacs. Typing \util\emacs results in "EXEC failure." Usually use the "prompt [$p]" command to make my DOS prompt display the current directory. Strangely, even though DOS now recognizes '/' as the path separator, it still uses the '\' in displaying the prompt. For instance, if I am in the directory \kermit on drive c, I get the prompt: [C:\KERMIT] However, if I invoke a new copy of COMMAND.COM by typing /command my prompt looks like this: [C:/KERMIT] But if I cd into a sub-subdirectory by typing, say cd /wp/word my prompt looks like: [C:/wp\word] Anyway, here are my questions: 1. Why does DOS get confused, and mix the '/' and '\' path separators? Does anybody know of any patches to COMMAND.COM which can correct this? 2. Is there any way to make the DOS prompt display the '/' path separator without starting a new copy of COMMAND.COM? 3. Does COMMAND.COM have any undocumented command-line switches that control this UN*X-like behavior? ---------------------------------------------------------------------- Sam C. Lin | /// Internet: linco@eng.umd.edu | /// ----------------------------- /// /// ///|| /// /////// //////// /// /// /// ||/// /// /// /// /// /// /// |/// /////// //////// /// ////////// -----------------------------------------------------------------------
rickc@agora.UUCP (Rick Coates) (12/23/89)
In article <1989Dec23.024131.6399@eng.umd.edu> linco@eng.umd.edu (Sam Lin) writes: >I have been experimenting with trying to make DOS 3.1 more UN*X-like, because >it is a real pain switching between UN*X and DOS between my Sun and my PC. >Recently, I got a hold of PICNIX3 from grape.ecs.clarkson.edu, and playing >with the SWITCHAR command has yielded some interesting discoveries. > ... I have no answers for MSDOS's behavior (I'm glad I'm not responsible for THAT code!), but can give you some more problems with using the switchar bit. A number of applications simply will not run with the switchar set to '-' (Norton utilities and SuperCalc, to name two). This is highly annoying. Also, if you use 'system()' call in Microsoft C, the spawned job dies with an 'Invalid path specification' message. Due to this (and the already mentioned problems) I have pulled switchar - off my DOS system. Sigh. Maybe 1990 will be the year I can get Unix running at home! PS - sorry to all about the post about SIMTEL20 - I now see they have a UUCP mail server - thanks, Keith!! Rick Coates Consulting H/W - S/W engineer (Graphics - Sun - Unix - ASIC design - imbedded systems) ...!tektronix!tessi!agora!rickc
ee5391aa@hydra.unm.edu (Duke McMullan n5gax) (12/25/89)
In article <1989Dec23.024131.6399@eng.umd.edu> linco@eng.umd.edu (Sam Lin) writes: >I have been experimenting with trying to make DOS 3.1 more UN*X-like, because >it is a real pain switching between UN*X and DOS between my Sun and my PC. >Recently, I got a hold of PICNIX3 from grape.ecs.clarkson.edu, and playing >with the SWITCHAR command has yielded some interesting discoveries. (balance deleted for brevity of length of this very message, and to eliminate duplication and redundancy.... Look up a critter called 4dos. I got mine off of 128.252.135.4 (D.B.A. wuarchive.wustl.edu) which seems to have just about all the messdos stuff carried by SIMTEL20 and, at least from this site, is a good bit faster over internet. Check the /mirrors/msdos directory, and glance at /usenet/comp. binaries.ibm.pc. 4dos is a replacement for command.com which: Ahem. Supports aliases, history, UN?X expansion of '*', improved editing of command lines, a variety of new "internal" commands, and a variety of improvements on the regular commands. I can't speak from experience yet; this acct. is going away in a few more days, and I'm busy pumping loads of PD software and sharware over this system while I still can. 2400 bps is slower than internet at its worst. After that's over, I'll reconfigure with 4dos & see if I like it. Then, I'll probably "byte" the bullet, and send in the shareware registration fee. Yeah, that's right, actually SEND IN a registration fee. Considering what's going on in Eastern Europe, I don't think too many people will notice. d "You should never threaten a man you are not going to fight, and if war is your intention, it is best to get on with it." -- F.J. Lovret Duke McMullan n5gax nss13429r phon505-255-4642 ee5391aa@hydra.unm.edu
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/26/89)
In article <1989Dec23.024131.6399@eng.umd.edu> linco@eng.umd.edu (Sam Lin) writes: | However, I discovered that the path separator also gets transformed from the | brain-damaged '\' to the UN*X '/'!! Well, not really. If you look at the DOS manual, you will see that the pathname separator is allowed to be / or \, and has been since DOS 2.0! The whole non-sense about the switch character is in COMMAND.COM and other applications. When COMMAND.COM stops looking for the / as an "option inducer" the / goes through and is (as always) treated as a path level separator. This is why you can use / in the #include (unless the compiler deliberately breaks them). Someone decided to go with the DEC / options instead of the - UNIX options. I believe this is because QDOS (the original MS-DOS V0.0) was based on CP/M, which was based on RSTS or some similar PDP-xx operating system interface. The CP/M copy program is called PIP, after the Peripherial Interchange Program. At any rate, that's why it works, it's not that anything in DOS changes, just that the command processor lets the / through. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
fredex@cg-atla.UUCP (Fred Smith) (12/26/89)
In article <1762@agora.UUCP> rickc@.UUCP (Rick Coates) writes: > A number of applications simply will not run with the >switchar set to '-' (Norton utilities and SuperCalc, to name two). This >is highly annoying. Also, if you use 'system()' call in Microsoft C, >the spawned job dies with an 'Invalid path specification' message. I believe that system() in MSC 5.1 works just fine with the switch character set to '-' (for example), as long as you use the correct switch character in the '/c' switch, i.e., '-c', or '?c' or '#c" or whatever the switch character is set to. Fred
liberato@drivax.UUCP (Jimmy Liberato) (12/28/89)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: >In article <1989Dec23.024131.6399@eng.umd.edu> linco@eng.umd.edu (Sam Lin) writes: >| However, I discovered that the path separator also gets transformed from the >| brain-damaged '\' to the UN*X '/'!! > Well, not really. If you look at the DOS manual, you will see that the >pathname separator is allowed to be / or \, and has been since DOS 2.0! >... This is true to an extent. There used to be a "built-in" feature of DOS that allowed you to have a "Switchar = -" entry in your config.sys which then forced the default switch character "/" to become a path separator (the "\" could then also be used indifferently as a path separator). This feature went away around 3.0 to be replaced by various swchar.exe hacks which provide the same function. It does appear that Microsoft no longer approves of the UN*X option (or at least wishes it would go away). Most people's surprise at "discovering" this feature reveals the suppression. Sam's final question about DOS getting "confused" I thought interesting. Do you have any thoughts on what might be happening? -- Jimmy Liberato ...!amdahl!drivax!liberato "Truly great madness can not be achieved without significant intelligence." -Henrik Tikkanen
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/29/89)
In article <LKXB00G@drivax.UUCP> liberato@drivax.UUCP (Jimmy Liberato) writes: | This is true to an extent. There used to be a "built-in" feature of DOS | that allowed you to have a "Switchar = -" entry in your config.sys which | then forced the default switch character "/" to become a path separator | (the "\" could then also be used indifferently as a path separator). I think there's confusion between the COMMAND.COM level and the DOS call interface level here. At the DOS call level, int 21, either / or \ are ALWAYS acceptable as path separators, without regard to the switchar setting. The switchar setting is used by COMMAND.COM to determine what is an option. The call to read dir or open file and return handle, or cd, are always allowed to use either character for path separation. | Sam's final question about DOS getting "confused" I thought interesting. Do you | have any thoughts on what might be happening? Again, it is COMMAND.COM which is getting confused. There is obviously some code there to attempt to use a new character, and if switchar is NOT / to display that between path levels. It also seems not to be well debugged. As far as I can tell DOS calls do not use the option indecer (switchar) for anything, it's purely a CLI issue. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon