On Wed, Apr 11, 2012 at 3:31 PM, Bret Johnson <bretj...@juno.com> wrote:
>> But no, it would almost never use '/' because that is the Directory
>> Separator (or whatever you want to call it). Also, '\' is the quote
>> character for the shell, hence "My\ File\ Name.txt". Also, I think
>> *nix (or at least Linux) can use any character for filenames except
>> NUL, i.e. "..." is a valid filename (eek!).
> That was basically my point. *nix has conventions/standards that it uses, and
> so does DOS, and they are not the same. Trying to make one "look like" the
> especially with so much history and "freedom" allowed by DOS, just won't
Actually, it can work fine.
On my old XT clone under DOS 3.3 and later DOS 5.0, I ran the MKS
Toolkit. The Toolkit was a collection of Unix utilities implemented
for DOS, and included pretty much all of the Unix commands that made
sense in a single-user, single-tasking environment, including complete
implementations of the vi editor and the Korn shell. (The only thing
the Korn shell lacked was asynchronous sub-processes, since DOS
couldn't do that.
The Toolkit offered several installation options. In fullest Unix
compatibility mode, it replaced COMMAND.COM with INIT.EXE as the boot
shell in CONFIG.SYS. When you booted, drivers would load, and then
INIT ran and printed a Login: prompt. Enter a userid and optional
password, and INIT called LOGIN, which checked the ID against a Unix
compatible /etc/passwd file, and if it got a match, changed to
whatever was specified as that ID's home directory, and ran whatever
was specified as that ID's shell.
I used that to customize my DOS environment, with IDs that ran
specific shells. One put me into the MKS Korn shell and a Unix like
environment. Another ran vanilla COMMAND.COM. A third ran 4DOS. A
fourth ran DesqView. When I was logged into the Korn shell, you would
have to dig to discover you *weren't* running under Unix.
When you exited whatever shell you were logged into, INIT was
respawned and Login: was printed. You could switch environments
Up through MS-DOS 3.3, MS provided a function that would let you query
what the option delimiter character was, and set it to something else.
MKS provided the SWITCH program to do that for you. If you used
something other than / as the option delimiter char, you could use \
*or* / in PATHs. DOS didn't care. Some DOS *apps* cared and choked
on it, so I wrote Korn shell alias wrappers to reset the option
delimiter char to / before running them, and set it back to - when
MS-DOS 5.0 *removed* the function that would let you *change* the
option delimiter, but *kept* the one that let you query what is was.
(Don't ask *me* why...) Fortunately, the Toolkit continued to work,
or I would have reverted to DOS 3.3.
I continued to use the Toolkit with Windows 3.X. Under Windows,
Program Manager was your shell, but you could replace it with
something else by changing the appropriate line in SYSTEM.INI. An
assortment of something elses existed, and I used the Toolkit to
create userids that diddled the SYSTEM.INI file to specify the
alternate shell I wanted to use, then ran Windows.
It took some fiddling, but it worked well and was fun to implement.
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
Freedos-user mailing list