On Wednesday, November 23, 2011 8:31 PM, "Dave Kilroy" <kilr...@googlemail.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 <rona...@eml.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
