Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!excelan!crdgw1!sixhub!davidsen From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr) Newsgroups: comp.sys.ibm.pc Subject: Re: DOS's Hidden UN*X-like Behavior Message-ID: <341@sixhub.UUCP> Date: 28 Dec 89 20:12:09 GMT References: <1989Dec23.024131.6399@eng.umd.edu> <243@sixhub.UUCP> Reply-To: davidsen@sixhub.UUCP (bill davidsen) Distribution: usa Organization: *IX Public Access UNIX, Schenectady NY Lines: 27 In article 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