Mail Archives: opendos/1997/04/25/14:08:25
On Fri, 25 Apr 1997 11:22:19 -0400 (EDT) "Mike A. Harris"
<mharris AT blackwidow DOT saultc DOT on DOT ca> writes:
>
>A computer with 4DOS, is not an ordinary setup.
It's common enough to be accounted
for sensibly imho.
>To use 4DOS as
>your primary shell, you have to put it in a SHELL= line.
Yup.
>In
>order for OD to function, it must change that line to point to
>COMMAND.COM (for hopefully obvious reasons of a failsafe
>install).
It didn't do that Mike, it left
the SHELL= line alone -- that's
what caused the "corrupt or
missing command interpreter"
error message. If it had changed
the SHELL= line I would have
gotten a normal OD COMMAND.COM
prompt and possibly some other
errors on 4DOS-specific stuff in
AUTOEXEC.BAT.
>Since 4DOS (or any other shell, including even a
>previous COMMAND.COM) is present on the SHELL line, it is renamed
>to prevent problems with OD's COMMAND.COM.
What possible "problems" could
such an idiotic idea "prevent?"
If the SHELL= line ends in a
complete and valid pathname,
the only problem I foresee
involves secondary shells and
the COMSPEC variable, not a
previously used shell with an
entirely different name and
directory location.
>This isn't the best,
>or most innovative solution, but it does work.
No it doesn't, it causes
annoying problems if your
current shell isn't
COMMAND.COM.
>If you understand
>the hows and whys of the way the installer works it isn't hard to
>see that it isn't random behaviour.
Nobody said it was random, just
badly designed and/or coded.
>It works exactly the way
>that they intended it to - albeit this is not very intuitively.
>
It works very badly, imho
you are far too kind.
Perhaps that is the way
"they intended it to," but in
that case their intentions
weren't thought out very well
at all.
>> >I'm almost positive that a future version of OD will prevent this
>> >sort of "brain damage" from happening.
>> >
>> Yes, if Caldera is aware of
>> the installer's rude behavior
>> I'm sure correcting it is
>> something short of rocket
>> science -- the way CONFIG.SYS
>> is analyzed needs to be a tad
>> more sophisticated, should be
>> no big deal to fix.
>
>Or even simpler, put OD's COMMAND.COM into the directory that OD
>is installed into, and then put SHELL=C:\OD\COMMAND.COM in there.
Not as good, but at least
there'd be an error-free
boot-up.
>This way it doesn't at ALL interfere with ANY alternate shells
>and no coding effort is needed in the installer. I have allways
>wondered why MSDOS, and other DOS's installed the command
>interpreter in the root directory as well as in their respective
>"\DOS" directories. It doesn't make any sense. I always remove
>the root copy and point shell to the installed directory. You'd
>think that most installations would be doing this as common
>sense.
>
I agree, if SHELL= has a
full and valid pathname, the
extra copy of COMMAND.COM is
superfluous, especially if
the F5-on-bootup feature
includes a default path of
C:\DOS\. Perhaps the extra
copy is to make sure there's
there's a valid command
interpreter in the event of
a screw-up when using the
F8-on-bootup line-by-line
feature, where there's a
chance of accidently skipping
the SHELL= line in CONFIG.SYS.
>> >Or, just rename it as I described above.
>> >
>> Sure, if you've figured out
>> what and where the renamed
>> and hidden file is. I've
>> found no evidence of such
>> on the XT, have yet to scan
>> the 486. :-)
>
>Well, that is what it does if you care to look. Yes, it was an
>annoyance, but the files are intact still nonetheless.
>
I looked, and either you're
wrong or there is more than
one installer glitch.
>> >Or acquiring the COMMAND.COM source code and coding 4DOS features
>> >into it yourself. I would suspect that by the time that OpenDOS
>> >7.1 or 8.0 or whatever comes out that COMMAND.COM will not only
>> >be compiled on a FREE compiler, but also may compile on ANY
>> >compiler, and also will probably double or triple in size.
>> >(executable size, not resident size).
>> >
>> Building up COMMAND.COM into
>> something resembling a free
>> 4DOS would be quite a project,
>> but a reasonable 4DOS subset
>> could be implemented without
>> too much trouble imho -- sort
>> of like the ZCPR series of
>> command processor replacements
>> for CP/M 2.2, which were no
>> bigger than the original DRI
>> CCP but much less annoying to
>> use.
>
>Well, the source code for COMMAND.COM is now available, as are
>the sources for various UNIX shells (bash, tcsh, pdksh, etc) so
>the functionality is there, cloning 4DOS shouldn't be too
>difficult to those with free time to spare.
>
Yup, free time is the main
issue, most folks want to
get paid for that much work,
even if it's mostly cobbling
together borrowed code.
>> >No, I think the problem is no big deal, a lack of foresight on
>> >the installer's part. No corruption. I even suspected
>> >corruption at first, but when I figured it out, I ice cream coned
>> >myself in the forehead. :o)
>> >
>> Right back atcha, Mike,
>> thanks for detailing the
>> renegade installer's
>> alleged quirk(s).
>
>Yep, now we can put another couple requests on the wishlist.
>
>- Non braindamaged installer for OD.
I think Caldera ought to do
this. Right now the installer
handles some things very well
(e.g. it politely allows you
to keep QEMM as you memory
manager) and other things
with notable incompetence
(the one or more shell-related
glitches).
>- People willing to clone 4DOS into COMMAND.COM
>
I think people with lots of
leisure time and/or little
need for sleep ought to
tackle this.
>TTYL
>
bcnu -- Bruce
- Raw text -