On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
> But why the batch file in the first place? It truly makes no sense: it
> pollutes the namespace equally, and can just cause problems (e.g. in the
> case of more than 9 arguments.) Not to mention slowing down a make.
Here's the thing: I, as a user, store lots of useful software on my PC.
Many of these programs are so useful that I like to have them available
immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
To achieve this, I know of four ways. Each comes with some limitations.
Method 1: Store every program in its own directory, and add each
directory to the %PATH%. Problem: obviously the environment will get very
bloated, very fast. Besides, some programs come with add-on tools that I
do not want to be available from within my path.
Method 2: Trim out the programs from everything besides a single exe, and
put them all in a single directory declared in my %PATH%. But this poses
two problems that I cannot live with: first, not every program can be
trimmed out to a single executable file (data files, config files, etc),
and second - almost all programs come with their respective README files
and other valuable documentation that I really want to keep within the
vicinity of the executable (ie. in the same directory).
Method 3: Store each tool in its own directory, and place a COPY of its
executable inside a directory in the %PATH%. Well, this is just messy -
upgrading the program needs to think about replacing the executable each
time in both places, and it's simply a waste of disk space.
Method 4: Keep each program in its own directory with all its original
files, and only store *.bat "links" in a single directory somewhere in
the PATH. This mitigates the troubles of methods 1 and 2, at the cost,
unfortunately, of *.bat's own limitations (max 9 args and '=' processing
weirdness).
The method 4 is what I started doing back in the nineties, and as of
today I still didn't find a better (or let's say, less worse) way. That's
a lifetime project it would seem.
The method 4 is also something that I implemented last year inside FDNPKG
(the FreeDOS package manager), but since I discovered recently how oddly
the '=' character is processed in %1-like arguments (there's a separate
thread about that on freedos-devel), I will have to figure out some
improved method... first thought pointed to computing some COM loader
relying on INT21,4Bh but that's far less trivial than the current batch
method, and hobby time is scarce.
Mateusz
--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
