This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: chere, mksh and pdksh
- From: Dave Kilroy <kilroyd at googlemail dot com>
- To: Ronald Fischer <ynnor at mm dot st>
- Cc: cygwin at cygwin dot com
- Date: Wed, 23 Nov 2011 20:31:20 +0000
- Subject: Re: chere, mksh and pdksh
- References: <1321987312.4604.ezmlm@cygwin.com> <1322035933.21972.140661002574293@webmail.messagingengine.com>
On 23/11/2011 08:12, Ronald Fischer wrote:
It's been a while since I last refreshed the package, so I'll have a
look and see if I can get something done ASAP.
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.
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. New shells would depend on the shell conforming to
some minimal requirements. If I recall, the existing shells do login
shells slightly different.
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.
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
Dave.
--
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