Mail Archives: djgpp/1997/06/13/12:20:33
>On Fri, 6 Jun 1997, Peter J. Farley III wrote:
>
>> Why can't DJGPP implement sufficient tasking to just support shell
>> pipes and redirection, which only involve standard I/O, and
>> synchronous subshells for () and `` operations? IOW, there would be
>> no need to support message passing, named pipes, etc. (the hard
>> stuff). Asynchronous process support would not be needed, since most
>> shell scripts don't need or use it. At the very least, this would
>> make *building* unix-based software more standard in the DJGPP
>> environment, IMHO.
>
>Sorry, I've read your clarifications to Chris Croughton, but I still
>fail to understand what functionality is in your opinion missing in
>DJGPP as it is. Are you talking about making pipes and `command`
>expansion work in a way other than temporary files? If so, why is
>this so important? Point your $TMPDIR to a RAM drive and viola! you
>get memory moves instead of disk I/O! I think the amount of hacking
>that you'll need to implement true pipes is enormous, and the benefits
>are minimal if you aren't going to support true multi-processing
>(i.e., the programs will still run serially). Making such pipes work
>only for DJGPP programs (as opposed for any DOS program spawned by a
>DJGPP program) might be easier, but I'm not sure it is worthwhile,
>although I do agree it is an interesting project...
I guess you have me there, Eli. What I was trying to get to, I think,
was at least simulated tasking support, with the idea that other unix
ports that *require* some kind of fork() facility would both compile
and execute, *thinking* they had a "real" fork(), even if they did
not, and would work, after a fashion, so long as the "real" fork()
facilities (message passing, named pipes, etc. -- the "hard" stuff)
weren't actually used. Perl.5 comes to mind, I guess, as an example
of something that really wants fork() to work, but doesn't necessarily
use it all the time, though it can.
I guess you're right, though. In for a penny, in for a pound, as it
is said. It probably isn't worth the effort to go half-way.
>The way DJGPP works now, you need to set SHELL=%DJDIR%/bin/sh.exe, and
>you then miraculously get support for all these features when you call
>`system' (it will just call Bash to do everything). What disadvantages
>do you see here that require additional functionality? It is good
>enough IMHO to allow building Unix-based software; I'm using the DJGPP
>tools for almost a year to build all the GNU packages on a plain DOS
>machine.
The disadvantages I was trying to overcome were, I guess, the ones
that make things like perl hard to implement fully under DJGPP. But
those are the "hard" ones, tasking and real pipes and such. Ditto for
language environments like Icon or Ada, where tasking support is
assumed.
Then again, I'm very new to DJGPP, and not very qualified yet to say
what can and cannot be done with what we have already. Or even
knowledge of all that *is* available so far.
>Please also note that the *syntax* for pipes and command expansion is
>implemented in Bash anyway, the kernel or the C library on Unix don't
>know anything about | and `` being special. If you want libc.a to
>support this syntax, you will have to add a parser for it to
>`system'. Apart of the syntax, the ``-style command expansion can be
>implemented in DJGPP right now, by using the `popen' function. Only
>true pipes cannot be supported easily.
Understood. And I agree, after thinking about your comments for a
while as well as perusing the libc source. I was not suggesting that
libc support this syntax, by the way. Only that the fork() routine be
implemented with enough fidelity to create the *appearance* of
tasking, with mods as needed to the i/o routines in libc to support
stdin/stdout/stderr piping via memory-buffered transfers, specifically
to support Bash and other shell implementations that *do* know that
syntax.
I have been getting more intimate with a really complex shell script,
the perl5.003 "Configure" script. In debugging and learning this
script, I also saw usage like 'exec 4>&1' and its inverse 'exec 1>&4"
to save and restore the value of the stdout fd around a "silent" area
of the script, where an 'exec 1>/dev/null' swallows excess output when
desired. When I understood what this code was doing, I realized that
it probably wouldn't be enough to just support stdin/stdout/stderr
either, but that more complete i/o support would be needed anyway.
All in all, I would have to say my suggestion does not make much sense
after all. But then, that's why I put it out, to see whether there
were things I missed or did not understand clearly, both of which have
proved to be true.
Thanks for the lessons, I sincerely appreciate them!
----------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org)
- Raw text -