Just a sample of the Echomail archive
[ << oldest | < older | list | newer > | newest >> ]
| Message 175 |
| Ben Collver to All |
| Running GNU on DOS with DJGPP part 3 |
| 18 Feb 24 11:39:08 |
TZUTC: -0600
MSGID: 177.fido_dos@1:124/5016 2a37776d
PID: Synchronet 3.20a-Linux master/862753d6c Feb 16 2024 GCC 11.4.0
TID: SBBSecho 3.20-Linux master/862753d6c Feb 16 2024 GCC 11.4.0
BBSID: EOTLBBS
CHRS: ASCII 1
NOTE: SlyEdit 1.88d (2024-02-16) (ICE style)
The second is that DOS paths may include an optional drive name such
as C: and... the drive name has the colon character int. While Unix
uses the colon character to separate multiple components of the
search PATH, DOS could not do that: it had to pick a different
character, and it picked the semicolon. Take a look:
C:\>path
PATH=Z:\;C:\DEVEL\BIN;C:\DEVEL\DJGPP\BIN;C:\DEVEL\TC\BIN
The problem here is that many Unix applications, particularly shell
scripts like configure--especially configure--read the value of the
PATH variable and split it at colon separators or append to it by
adding a colon. But if we do these textual manipulations on a
DOS-style PATH like the one shown above... we'll get the wrong
behavior because of the drive names--and Unix programs don't know
they have to split on the semicolon instead and we cannot be expected
to fix them all.
The way DJGPP deals with this is by faking the /dev/ device tree.
While DJGPP provides implementations of things like /dev/null, it
also exposes DOS drives via their corresponding /dev/[a-z]/ virtual
directory. So, if you wanted to run applications that parse or modify
the PATH, you could rewrite the above as this:
PATH=/dev/z:/dev/c/devel/bin:/dev/c/devel/djgpp/bin:/dev/c/devel/tc/bin
This would allow any application reading the PATH to continue to
work. But note that this value doesn't seem to leave the realm of the
current process, which is interesting:
D:\>path
PATH=Z:\;C:\DEVEL\BIN;C:\DJGPP\BIN;C:\DEVEL\TC\BIN
D:\>
D:\>bash
bash-4.2$ echo $PATH
z:/;c:/devel/bin;c:/djgpp/bin;c:/devel/tc/bin
bash-4.2$ env | grep ^PATH=
PATH=z:/;c:/devel/bin;c:/djgpp/bin;c:/devel/tc/bin
bash-4.2$
bash-4.2$ PATH=/dev/c/djgpp/bin
bash-4.2$
bash-4.2$ echo $PATH
/dev/c/djgpp/bin
bash-4.2$ env | grep ^PATH=
PATH=c:\djgpp\bin
bash-4.2$
The picture above shows how bash sees a DOS-style PATH after it
starts. Manually setting it to a Unix path keeps the Unix path in the
current process (as shown by the built-in echo calls), but when we
spawn a different one (env is a separate executable), the value is
reset. This makes sense because, if we are running a regular DOS
program from within a DJGPP one, we want to export a DOS-compatible
environment. Which means the Unix variants probably only stick within
shell scripts. You can also see how this works by peeking at
dosexec.c again.
But wait a minute... did I just show you bash?! On DOS? Oh yes, yes I
did...
# Trying it out yourself
It's time to get our hands dirty, try this out, and reminisce the old
days! Or, actually, not so old. You should know that DJGPP is still
available in this day and age and that it is quite up to date with
GCC 12.3--released less than a year ago.
First off, start by installing DOSBox. You can use the standard
DOSBox version, but it's probably better to go the DOSBox-X route so
that you can get Long File Name (LFN) support by setting the ver=7.1
configuration option. Otherwise, beware that running Bash later on
will create .bash_history under C:\ but the file will be named .BAS
due to some odd truncation, and this will later confuse Bash on a
second start and assume that .BAS is actually .bash_login.
|
[ << oldest | < older | list | newer > | newest >> ]