delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/06/07/16:03:56

From: pjfarley AT dorsai DOT org (Peter J. Farley III)
To: crough45 AT amc DOT de, djgpp AT delorie DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Why not fork() etc. specific for for shell usage?
Date: Sat, 07 Jun 1997 15:50:28 GMT
Message-ID: <33997edc.2486009@news.dorsai.org>
References: <339787eb DOT 2387875 AT news DOT dorsai DOT org>

Chris Croughton <crough45 AT amc DOT de> wrote:

>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?
>
>Let me see if I'm understanding your thought, by rephrasing:
>
>The proposal seems to be to implement things like the backquote
>operation when the DJGPP-compiled program is parsing its command 
>line?  You don't really need fork() for that at all.

No, Chris.  I'm only proposing that backquote and piping support be
added sufficient to let shells like Bash implement these things.  IOW,
I would *not* expect the support to include COMMAND.COM support for
programs we write to use piping and redirection, just that if we are
operating under Bash that piping and backquoting, etc., operated as
"real" tasks, albeit *synchronous* tasks.

This would be in place of the current implementation that supports
pipes with files.  I'm also thinking that a trap of some sort in the
standard I/O routines could (possibly) detect that a "piped" file was
being written to or read from, and let that result in the appropriate
task switch.  Then there might not be as "hard" an implementation as
the more general one.  I'm thinking that semaphore support might be
needed, but not necessarily message-passing (though I could easily be
wrong about that; as I said at first, I may not realize how deep these
waters really are...<g>).

>If that's the case then I can see a couple of reasons against it:
>
>1) Size.  Adding things to the parameter parsing code increases 
>the size of the executable (therefore the loading time as well 
>as disk space).  We already have a number of people complaining 
>about the size (and granted most of them haven't bothered to do 
>-s when compiling, but they're still there).
>
>2) Some DOS shells (notably 4DOS) already do their own things
>with shell characters like backquotes which are not compatible.
>Of course, this objection is only true for programs run from the
>command line as opposed to from (say) bash scripts or makefiles.

Exactly.  I'm only talking about the latter, and not the former.

>Otherwise, if neither of those is an important factor, I'd say
>that your suggestion is good.  It's something I thought of and 
>rejected for the above reasons, but I'm willing to be convinced 
>that they're not relevant.
>
>Of course, you then have to get someone to code it and maintain
>it.  Any volunteers to see if it's feasible?

<G> I guess I was, sort of.  I obviously need to educate myself
enormously in the intracacies of the DJGPP implementation, but I was
thinking of doing that anyway.  I just thought I'd propose a "simpler"
solution to those here with more knowledge and experience than I have
to see if the thing *could* fly.

>If I've misunderstood your intent, please forgive me and try 
>again.

That's what I'm doing here.  Please let me know if I've clarified
myself or just added to the confusion.


----------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019