Subject: Re: chere, mksh and pdksh
From: "Ronald Fischer" <[email-masked]>
To: "Dave Kilroy" <[email-masked]>
Cc: [email-masked]
Date: Thu, 24 Nov 2011 10:00:03 +0100
List-Id: <cygwin.cygwin.com>

On Wednesday, November 23, 2011 8:31 PM, "Dave Kilroy"
<[email-masked]> wrote:
> On 23/11/2011 08:12, Ronald Fischer wrote:
> > Is there a technical reason, why chere needs to know a predefined set of
> > "keys" for the shell to install?
> 
> If I recall, this was to make it simple to locate any entry chere may 
> have created.

I thought so. This would go well to allow a path in addition to a key.

> > For instance, would it not be
> > sufficient to pass the path to the shell? In this case, new shells can
> > be installed without the need to update chere.
> 
> I think it would have to be a munged path. I suspect '/' would not be 
> valid in a key name. 

Yes, but I don't think this would be a real problem in practice.

> New shells would depend on the shell conforming to 
> some minimal requirements. If I recall, the existing shells do login 
> shells slightly different.

They do the login differently, but this is not something chere needs to
worry. Any shell could be invoked by just calling the path (this works
from command line).

Of course one might argue that the user would want more control on how
the shell should be invoked. For instance, I want to choose whether the
shell should act as a login shell or as a non-login shell, or whether
the -x should be set on invocation. Note that these are features not
supported by the current chere, but when we think about expanding the
concept, it makes sense thinking about this too.

In fact, this could be achieved easily too, in two ways:

Either chere allows for a path to the shell AND arguments, which means
that the arguments need to be munged in as well; or chere insists in
only getting a path to a shell. In the latter case, the user could
supply a "cover script" (say, in bash), which just does an exec to the
shell he wants to, supplying the necessary parameters.

> > Also, if I can use the
> > path to the shell as a "key", I could (by using appropriate symlinks)
> > have several "chere" entries for the same shell (for instance, mintty
> > with ksh AND rxvt with ksh).
> 
> My feeling is that most people have a prefered terminal, but may need to 
> use different shells.

The terminals behave in different ways, for example how they react on
ANSI escape sequences, so it's handy to be able to run a shell in
different terminals.

> To do what you want, my feeling is that it's easier use what chere does 
> as an example. You can even script it with something like:
> 
> chere -ip -t mintty -s ksh | sed -e "s/cygwin_ksh/mintty_ksh/g" > a.sh
> chere -ip -t rxvt -s ksh | sed -e "s/cygwin_ksh/rxvt_ksh/g" > b.sh
> ./a.sh
> ./b.sh

This is indeed a feasible solution! Good point!

Ronald
-- 
Ronald Fischer <[email-masked]>
+  If a packet hits a pocket on a socket on a port, 
+  and the bus is interrupted and the interrupt's not caught,
+  then the socket packet pocket has an error to report.
+		(cited after Peter van der Linden)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple