X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.0 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_PD,TW_RX
X-Spam-Check-By: sourceware.org
Message-Id: <1322125203.5768.140661003042341@webmail.messagingengine.com>
From: "Ronald Fischer" <ynnor AT mm DOT st>
To: "Dave Kilroy" <kilroyd AT googlemail DOT com>
Cc: cygwin AT cygwin DOT com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
References: <1321987312 DOT 4604 DOT ezmlm AT cygwin DOT com> <1322035933 DOT 21972 DOT 140661002574293 AT webmail DOT messagingengine DOT com> <4ECD5818 DOT 4040809 AT gmail DOT com>
Subject: Re: chere, mksh and pdksh
In-Reply-To: <4ECD5818.4040809@gmail.com>
Date: Thu, 24 Nov 2011 10:00:03 +0100
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Wednesday, November 23, 2011 8:31 PM, "Dave Kilroy"
<kilroyd AT googlemail DOT com> 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 <ronaldf AT eml DOT cc>
+  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