Le jeudi 14 janvier 2021, 00:00:39 UTC Simon McVittie a écrit : > On Wed, 13 Jan 2021 at 22:49:27 +0000, Bastien Roucariès wrote: > > gnome-terminal -e sleep 60 > > The upstream-provided gnome-terminal executable does not claim to be an > implementation of the x-terminal-emulator alternative. It has its own > command-line interface, which uses GNU-style long-option parsing (unlike > xterm). If we patched it to provide the x-terminal-emulator interface, > that modification would make it incompatible with upstream gnome-terminal, > and with other packages that know how the gnome-terminal interface works. > > The Debian-specific script /usr/bin/gnome-terminal.wrapper is what gets > registered as an implementation of x-terminal-emulator if you have the > gnome-terminal package installed. Its command-line interface is almost > a subset of xterm's (it does additionally support --help, which xterm > does not). > > If you want gnome-terminal behaviour, run gnome-terminal and pass > gnome-terminal arguments to it; if you want generic x-terminal-emulator > behaviour, run x-terminal-emulator and pass x-terminal-emulator > arguments to it. They are not the same, and programs can only rely on > x-terminal-emulator behaviour if what they run is the x-terminal-emulator > alternative. If they run a specific terminal directly, then they'll get > that specific terminal's behaviour, whatever that might be. I agree with you here but documentation should be better here: - document that -e should be the last option - document that the list of argument after should not be quoted (and it is saner for a implentation point of view) - document that x-terminal-emulator should wait - -t documentation is clear - document that additional option may be accepted I believe also that package provinding x-terminal-emulator should Provides: x-terminal-emulator (=1.0). It will ease transition if we add incompatible changes to the spec, and that we should modify one wrapper in order to be spec compliant. > > Moreover some packages noticed that x-terminal-emulator does not wait by > > default > > I'm not sure whether waiting for the executed command to exit is > actually part of the specification for x-terminal-emulator, but > /usr/bin/gnome-terminal.wrapper passes --wait to gnome-terminal, so that > it will behave like xterm in this respect. > > Other implementations might not. Yes and it is a problem. I plan to improve sensible-editor. If you set sensible-editor in desktop and you set editor as nano it will try to open an terminal. Parent application will wait until closing. So wait is here needed Link2 have the same problem, terminal should wait. It is implemented by current application, so consensus is here but it should be documented. Moreover if you could not want to wait we could always run it is background subshell. > > > I plan to create a sensible-x-terminal-emulator and thus I need to > > document; * the -e behavior, that should behave like xterm and do not > > need to use quotes > > https://www.debian.org/doc/debian-policy/ch-customized-programs.html#package > s-providing-a-terminal-emulator describes what you can rely on from an > implementation of the > x-terminal-emulator alternative. Anything not written there cannot be > relied on. > > Policy promises that "x-terminal-emulator -e sleep 60" does what you think > it does. I found the wording not clear. It should be improved here. When policy is clearer I plan to create a man page of x-terminal-emulator and I will put it in sensible-utils, so I need a really clear documentation. I really found that x-terminal-emulator manpages be a copy of gnome-terminal is a bug: - gnome-terminal is not x-terminal-emulator - at least it should redirect to gnome-terminal.wrapper manpage - better wlll be a manpage common to all x-terminal-emulator that document only the policy compliant options. Other options are implementation detail > Policy does not say anything either way on what > "x-terminal-emulator -e 'sleep 60'" will do. It happens to work with xterm > and with /usr/bin/gnome-terminal.wrapper, but that is not guaranteed. Yes I know, and BTW I found this behavior a least error prone, but it may be acceptable. Thanks Bastien > > smcv
Attachment:
signature.asc
Description: This is a digitally signed message part.