RE: OT: possible project/research project

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Randall R Schulz [mailto:rrschulz@cris.com] 
> Sent: Wednesday, March 20, 2002 12:15 PM

> 
> Robert,
> 
> This idea isn't really new. 

I don't recall claiming it as 'new' .. just an idea.  :} (ok, pedant
mode off).

> The problem is that you're creating a huge project that 
> creates no new 
> functionality and that has horrendous maintainence issues, as you say.

Yah. That's the crux. I've no interest in creating such a project.
 
> The library conversion idea is kind of a throwback to 
> pre-Unix days or to 
> systems like VMS (if I recall and understand it properly). In 
> these systems 
> there were "blessed" commands understood by the command 
> interpreter and 
> endowed with a more direct means of invocation. Other 
> commands required 
> full sub-process creation.

Well we still have that basic separate - bash's builtin's for example.
If it's not builtin, it needs a sub process. 
 
> I trust it's your intent that the user will see no obvious 
> differences in 
> invoking these programs, but you may find full transparency harder to 
> achieve than you expect. Will the full range of shell 
> features be available 
> to these specially integrated commands? 

That is the design goal, should such a project be attempted by me.

> Will you be able to 
> pipe into and 
> out of them? 

Yes.

> Will they work within parentheses? 

Yes.

> In 
> procedures? 

Yes.

> Will you 
> allow all shell features (pipes, say) are applied to 
> arbitrary combinations 
> of conventional and integrated commands?

Yes.

Before you think I've got plans to big for my boots, consider that if we
leverage an existing shell, all those feature work out-of-process now.
proxying each feature into a library-capable equivalent one at a time
would allow a serious fallback mechanism for any functionality gaps.

> In your example of a `backquote command` (which I prefer to 
> invoke via $( ... ) using BASH) 

Not being a shell afficiondo, I'm happy to be educated: what is the key
difference between `...` and $(...)?

> you'd be exposed to any unintended 
> side-effects within 
> the backquote command. Side-effects like file descriptor alterations, 
> changes in signal dispositions, receipt of signals or 
> exceptions (expected 
> or the result of a programming error).

Well that's the point of the 'push_context' pseudo command, to save all
that information, and then restore it. It may need some 'OS'
co-operation to fully achieve that - ie stdin being kept intact
(although I imagine that the librarised commands would be given a
virtual stdin, as they are sub process's after all) -  but we have the
source so....
 
> The beauty of the fork/exec model with entirely separated 
> programs _is_ 
> their self-containedness and the complete independence and 
> isolation each 
> of the programs gets from each other and from the program(s) 
> that invoke 
> them. 

The fork()/exec() model bites. Sorry, but it does. fork() based servers
for instance run into the galloping herd - and scale very badly. The
other use for fork -the fork/exec combination is better achieved with
spawn() which is designed to do just that one job well. It also happens
to work very well on cygwin, and I see no reason to change that. So
spawned apps will remain completely separated and independent.

> It is also nice in that it is a very simple programming 
> model for commands, both built-in and end-user-supplied, that run 
> within it.

I don't see how this idea detracts from that. Do you think that the
presence of a librarised 'ls' command (for instance) will prevent the
user adding perl to their system? Or replacing ls? Either scenario is
abhorrent to me.

> It is probably less platform-specific than a scheme that demands use
of 
> dynamically-linked / shared libraries.

Ermm, I guarantee I'll be using libtool if I do this... 
 
> The Unix shell and process model may be somewhat costly of computing 
> resources (but only marginally so), especially as I said without 
> copy-on-write behavior in the fork call, but that rather 
> modest down-side is more than made up for by independence, modularity,
and 
> open-endedness of 
> the scheme.

I grant that independence, modularity and open-endedness are wonderful
things. Can you please describe how what I have suggested prevents any
one of the above? The whole point of a librarised approach is to make
the shell modular. That also grants open-endedness for free. As for
independence, if none of the libraries are available, then the whole
thing would run as a normal shell, with no in-process behaviour. 
 
> I can't see how all the work your idea implies just for the 
> sake of some incremental performance improvements is going to be
worthwhile.

Well that's arguable :}. If it takes 100 mythical man-months to create
this beast and libraries the top 20 shell tools.... how many users can
use this, and how much time do they save? Lets say they save 5 mythical
man-minutes per month per user. Well we have ??? thousand users, so I
think it'd pay forward it's time investment quick smart.

> By the way, which shell will you do this for? BASH, TCSH, 
> Ash? More than one?

I'd guess at ash, as that's the smallest shell we have, but if it's
easier with bash, then I see no reason not to - as this would be a
/bin/sh replacement - if the benefits were to be realised.
 
> Please feel free to prove me wrong, of course.

Well, I've got to complete my review before I decide what I think of the
idea. Until then its just an idea. Also I don't feel the urge to 'prove
something' on this :}.

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/