On Fri, Jan 31, 2020 at 11:38:04PM +0000, Bernd Edlinger wrote: > On 1/31/20 11:54 PM, Segher Boessenkool wrote: > > about most, which caused me to open PR93168, is TERM=screen (which is > > what tmux uses), so at least exclude that one? And doing all this > > Definitely, if the situation with tmux is like xfce4-terminal (reportedly > the 0.8 version switched to a fixed VTE, which makes the URLs invisible, > but the URL feature request is pending sine 2017, with no activity > whatsoever), > then detecting that and disabling the URLs until they finally implement > the URLs is straight forward. I can add that to my patch if you confirm, > the right detection logic:
The situation is that it is a terminal multiplexer; you can connect any terminal to it, and swap those out, etc. You might have one that has support for the url thing at one time, but when you look at that session from a different machine (from your phone, say), not anymore (or the other way around). You can also connect multiple actual terminals at the same time. In short, even *if* you could detect whether the terminal supports this url thing (and you cannot), you cannot detect whether it will support it two seconds from now, and even if the url thing you already displayed will misbehave *in the future*! > >From > >https://unix.stackexchange.com/questions/10689/how-can-i-tell-if-im-in-a-tmux-session-from-a-bash-script > I read the safest way to find out if you are in a tmux session, is > to look for TERM=screen and TMUX is set. Yes, but the same considerations are true for all screen-like programs. I happen to like tmux best, some people swear by old-fashioned screen, and there are other alternatives too I think. > Is that the case for your environment? It's true on at least six machines I tested just now, but all of those are pretty similar anyway, so that doesn't say much. > Note that it is well possible that this environment values are > not preserved in a ssh session, but nobody is perfect. The session you are looking at is not the ssh session; it will keep running even if no actual terminal is connected, that's pretty much the point of running it, in many cases :-) > >> Since I have seen much garbage from the URLs in the xfce4-terminal 0.6.3 > >> admittedly an old Ubuntu installation, but still in LTS status, > >> and no attempt from the xfc4-terminal to _ever_ implement URLs, > > > > This is true for *most* terminal emulators. > > Sadly, I would not do this if there is a chance that someone looses a > working feature, so I was told that a more aggressive approach would > "be straight harmful to the current state of things > (i.e. hyperlinks at least not causing any problem, plus working > out of the box wherever supported, for the vast majority of people)" > https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#gistcomment-3160953 I have seen not a *single* terminal emulator where this works 100% correctly. I have seen many where it screws up display spectacularly (or sound even :-/ ) > So I would try to detect known terminals which are so buggy that they > print garbage instead of silently ignoring the URL escapes AND > which may or may not have fixed the visual glitches but have not plan > to implement URLs at all. That is not buggy at all. It is a bug to output the wrong escape codes, instead. > > I have nothing against this feature, I just wish it wouldn't annoy me > > on pretty much every system I use. None of which use "TERM=dumb", but > > none of which use "TERM=fancy-pants-term-v42" either. (Did anyone ever > > use "dumb", anyway?) > > The dumb thing was old code, I only took the freedom to document it ;-) I know :-) I mean, does anyone have "TERM=dumb" in the environment? "TERM=ansi", sure, and I've used "TERM=vt220" many times, too, but I've never seen "TERM=dumb" used. Segher
