Re: sensible-x-terminal and x-terminal-emulator
Hi,
From: Anthony Towns <aj@azure.humbug.org.au>
Subject: Re: sensible-x-terminal and x-terminal-emulator
Date: Sat, 22 Jul 2000 09:35:45 +1000
> Well, there'll be a couple of problems with this. One is that the policy
> for sensible-xtermemu will be different to the existing policy for
> sensible-editor and sensible-pager: those programs are meant to *not*
> be called, direct support for $EDITOR and $PAGER is what's required,
> and sensible-{editor,pager} is just a fallback.
Umm. That't true... A software which cannot support $EDITOR and $PAGER
can call sensible-{editor,pager}. However, sensible-{editor,pager}
never diverts any concrete editors nor pagers. Rather, sensible-
{editor,pager} falls back to 'editor' and 'pager'.
>> and be integrated into 'debianutils'
> xfree86-common would make more sense, I suspect.
It also works.
However, one minor problem. The upstream source code of
'xfree86-common' comes from XFree86. Thus, sensible-x-terminal-emulator
will be supplied as a _patch_ in the Debian source package,
unless sensible-x-terminal-emulator would be integrated into
upstream XFree86.
Ok, I can ignore this minor problem, though I don't know how
the maintainer of XFree86 packages thinks.
> Yes. The way sensible-{editor,pager} avoid this is by making those
> programs so completely boring they're not worth pointing an alternative
> link at them. sensible-xtermemu is somewhat more interesting: it'll
> select the "right" xtermemu based on LANG as well as choosing one you
> select explicitly, or falling back.
Debian Policy does not prohibit to call sensible-{editor,pager} directly.
If it were, then sensible-{editor,pager} would be needless.
> It's probably not too difficult to avoid the infinite loop,
> though. Umm. Hmm. Attached. If you just use the check() function within
> exec2(), you should be able to avoid any accidental infinite loops.
Sorry, I am rewriting sensible-x-terminal-emulator in Perl since
it will need many string operations to support configuration file
to avoid hard-coding of table of locales and terminal emulators.
String operations can be written much easier and smaller in Perl.
Ok, your function can easily be rewritten in Perl.
I understand I can avoid infinite loop.
(1) sensible-x-terminal-emulator checks /usr/bin/x-terminal-emulator.
(2) if it is a link to /usr/bin/xterm (diverted s-x-t-e), call
xterm.orig.
(3) Otherwise call /usr/bin/x-terminal-emulator.
However, the following problems remain:
At first, as Malcolm Parsons says,
> Any package that starts an x terminal emulator by calling xterm directly
> is not packaged properly, and a bug should be filed.
Secondly,
> > Until Debian Policy is modified, you can use this package as following:
> > (1) copy example files of configuration
> > (/usr/share/doc/sensible-xtermemu/examples/*) into
> > /etc/X11/sensible-x-terminal-emulator/*.
> > (2) rewrite some programs or configuration file which calls X terminal
> > emulator to call /usr/bin/sensible-x-terminal-emulator. For
> > example, /etc/menu-methods/menu.h has 'xterm'.
> With xterm diverted, you don't really have to do either of these. This
> seems like a win.
Divert will omit (2). (1) is not omitted. Or, should I supply a
sample configuration files already installed in /etc/ directory?
[This increases the forth problem I write later...]
At third, users will be surprized if typing 'xterm' invokes kterm.
At last, sensible-x-terminlal-emulator will never divert xterm when
it will be included in debianutils or xfree86-common and written in
the Debian Policy. (Do you agree this?) If it supplies diversion
for test now, when it will cease to supply diversion?
---
Tomohiro KUBOTA <kubota@debian.or.jp>
http://surfchem0.riken.go.jp/~kubota/
Reply to: