[ On Thursday, October 3, 2002 at 00:13:07 (-0400), der Mouse wrote: ]
> Subject: Re: CVS commit: basesrc/bin/ksh
>
> > Well, if you use sub-shells....   :-)
> 
> There are some things that are nigh impossible without using subshells
> to isolate the effects of certain commands to well-defined fragments of
> the script in question.

Yes of course -- in the context I was speaking of though I meant
"interactive sub-shells" :-)

(which would normally be specifically those started from some other
application, such as an editor or mail reader)

And that's also why I equated job control and sub-shells and gave a
windowing system as an equal alternative to both.

> window is, in my experience, flaky enough that I don't use it in any
> situation where I would mind its crashing out from under me (which
> actually doesn't leave much).

I've never been in a situation of having to use it -- and it hasn't
crashed when I've toyed with it.  Numerous improvements have been made
to the version in NetBSD too.

I mentioned it instead of 'screen' because it is available by default on
NetBSD and also because I believe it's inherently more securely designed
and implemented than 'screen', though the only evidence I have for that
is the number of BUGTRAQ postings about security related bugs in each.

> It also does unpleasant things to input, primarily hijacking at least
> one character for its own purposes.

So does 'screen' -- that's a fundamental problem with anything that uses
an in-band control protocol.  Unfortunately both programs steal a very
commonly used control key I use in emacs, and worse each has a different
default command/escape character.  I think the only way to really avoid
this problem is to use a real windowing system with a separate control
input device, such as a mouse.

'window' is missing a fundamental feature too -- the ability to detatch
a session of sessions and then re-attach to it again.  Perhaps that is
where most of the security issues with 'screen' arise, but for me such a
feature is an absolute requirement of any (multi-)session management
tool like this.  The only times I've ever done anything more than toy
with 'screen' are times when accidental session disconnects are both
likely and unacceptable, and of course such a requirement also presumes
the session manager is itself quite robust -- it has to be there when I
finally re-establish my connection, otherwise it serves no purpose
beyond eliminating the need for job control (a now ubiquitous feature :-).

Indeed if all I wanted were an alternative to job control and I didn't
have a "real" windowing system to use then I'd probably choose another
tool I use regularly (constantly? :-) which is itself capable of being a
windowing system too!  :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>