Josip Rodin wrote:
> Hi,
>
> On Sun, 30 Mar 2008 16:26:00 -0700, tony mancill wrote:
>> In the case of clusterssh, it's inappropriate to have it simply launch
>> /usr/bin/x-terminal-emulator because clusterssh has no way of knowing
>> whether /usr/bin/x-terminal-emulator points to a terminal emulator that
>> supports the VT100.allowSendEvents property. A piped dependency may ensure
>> that a terminal emulator exists that works with clusterssh, but doesn't
>> guarantee that the alternatives system has selected it.
>>
>> I'll consider this, but there's something to be said for a package that
>> works out of the box without the user having to edit .csshrc or modify
>> alternatives. rxvt is smaller and has fewer dependencies, so it may be a
>> better default choice.
>
> I never got your original message because the submitters get mail only when
> you send it to them, either directly or via nnn-submit...@bugs alias. Just a
> reminder :)
>
> The code currently does:
>
> $config{terminal} = "xterm";
> $config{terminal} = find_binary( $config{terminal} );
>
> Since an auxiliary function find_binary() is used already, it could easily
> be amended to figure things out. For example, the default value could be a
> special string such as !terminalwithevents!, and a simple handler inside
> the function would intercept that and check for xterm and rxvt in order.
> If it finds neither, it can proceed to fail just as it does now.
Sure, it's not a question of whether it's difficult to code, only one of it
whether there's any point in coding up a patch that isn't likely to be accepted
upstream. find_binary() only tries various path prefixes and is used for for
more than just the terminal. The work-around is quite simple, you only have to
edit .csshrc with your preference of terminal.
In your proposed solution, the code would always select xterm and then rxvt if
both were installed, which may just result in another bug report requesting that
the order be reversed (or that other terminals be added to the list, again with
ordering issues). It just seems arbitrary when users who have a preference of
terminal emulator can easily configure clusterssh to suit their needs, and it
works as packaged for people who don't have a preference, using the same
terminal emulator configured by default by the upstream author.
I'm changing the severity of this to minor (it's arguably wishlist), and will
discuss with the Upstream author once he releases the 4.00 rewrite (should be in
the next few weeks).
Thank you,
Tony
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
