GNOME Bugzilla – Bug 332148
Support for GNU screen
Last modified: 2021-06-10 16:28:05 UTC
GNOME already supports using Secure Shell servers for storage, so it would be consequent to add support for Secure Shell to GNOME Terminal. Once we are on it, we also could teach to attacht to screen sessions. Have a look at the screenshots for getting an idea. Btw, what do you think about adding those stock icons shown in the mockups to GNOME Terminal? The list of Secure Shell servers could be retreived by scanning ~/.ssh/confing for "Host" entries. The list of Screen sessions could be retreived by scanning /var/run/screen or by parsing the output of "screen -ls".
Created attachment 59914 [details] New "Open Terminal" menu. "Open Tab" would look similiar.
Created attachment 59915 [details] "Connect to Remote Host"
Created attachment 59916 [details] "Attach to Screen Session" If I look at it again "Attach to Screen" should be renamed into "Attach to Screen Session".
Neat stuff. I personally never use the profiles feature. All I use all the time is the default profile. But it would be nice to create profiles automatically for each host in ~/.ssh/config...
I've been thinking about this since someone requested something similar in another bug report, and I think I'd rather integrate that with Nautilus.
@Guilherme: Nautilus is responsible for pushing arround files. Terminal is responsible for pushing arround shell commands. If I connect to some remote host via the "ssh" shell command, I do that for penerating some poor computer with shell commands - so in my opinion Terminal is the application which has to offer this functionality. Also I'd like to claim, that the *average* user for Nautilus' network environment is quite scared by the UNIX shell. So for the same reasons which caused the "Open Terminal" command being removed from Nautilus' context menu I'd prefer to not reintroduce even more scary remote terminals into Nautilus' network environment. Nevertheless it would be some useful addition for the "Open Terminal" extension to provide access to Terminal's automatically generated secure shell profiles.
Have you ever seen that thing in your panel, Places->Connect to server? You can use SSH connections that way, and that's the kind of integration I meant. No need to duplicate machine information, if it can be shared by nautilus and gnome-terminal.
To be true: I don't use the GNOME Panel. It has some nice features, but there is no way to make it look like I want, so I am not willing to accept the massive memory overhead it causes by serving as bloated container for memory huging applets. Well, but if the suggestion functionality is not useful for GNOME, just let's close this feature request. I can live with creating those profiles manually.
What part of the "let's implement this in a way that it gracefully integrates with the rest of the environment" did you not understand?
Ok, Guilherme. Pardon for flaming against Panel - this are my personal issues. Guess I realized now which direction you want to go. Let me sumarize: 1) It is nice, that OpenSSH has a favorites list, but using that list would be bad as we already maintain a list of favorite computers. This list of favorite computers is accessable via Nautilus' network environment. 2) So if Terminal wants to provide a list of profiles for remote computers, it should use Nautilus' computer list instead of parsing the configuration files of OpenSSH. I have to agree we you, you are right: Instead of parsing ~/.ssh/config, I should figure out, how Nautilus maintains its list of remote computers and hook into that mechanism. Once that works, I might try to teach Nautilus to merge the information from OpenSSH's configuration files. So if we agree on that, I'll start working on that feature. Well, and pardon again for flaming.
Yeah, you got it perfectly right =) That's what I intend to work on as soon as I have time (although I would love it if someone would work on that before, as my free time chunks have been quite unforeseeable).
Erm, after looking arround I could not find such infrastructure in GNOME: - SD/DNS aka. Zeroconf is not as powerfull as ~/.ssh/config, as you 1) have to control the remote hosts DNS and 2) have to be willing to publish your service to the world - scanning Nautilus' bookmarks for potental login hosts is far more cumbersome, than parsing ~/.ssh/config in my opinion Is there something I have not seen yet?
I've even pointed you to it before. See /desktop/gnome/connected_servers on gconf.
/desktop/gnome/connected_servers - don't have such a key, and I am running gnome-vfs-2.13.91 plus nautilus-2.13.91. Well, but finally realized that my Zeroconf problem just was a problem in GNOME-VFS (Bug 332634). So with the attached stuff it is possible to find and publish secure shell servers.
Created attachment 60163 [details] Hackish script for publishing secure shell servers found in OpenSSH configuration
Created attachment 60164 [details] Find secure shell servers via GNOME-VFS and DNS-SD
Created attachment 60220 [details] Pretty secure shell service publisher Updated the publisher script to directly use Avahi's DBUS API. Works nicely. Big question: Where to publish this script? Should I try to get it into Avahi, or does it belong into gnome-vfs or gnome-control-center? Advice needed... ;-) The license header claims GNU GPL 2.0 right now, but if it should be decided to bundle the script with a library released under GNU LGPL 2.1 (or later), it is fine to relicense under LGPL 2.1 (or later).
Created attachment 60222 [details] Publish proper TXT record. Forgot that Python tuples must have at least two elements.
Python tuples don't have to have at least two members. (x,) is a tuple with one member.
...strange, non-obvious syntax. :-)
I have attached a patch and screenshots in bug 313480 that adds a connect to server dialog. I planned to update against latest CVS and clean it up in a couple of weeks for the next release cycle (I didn't bother with it this cycle since there was no maintainer until fairly late in the game :). I gave some thought to integration with /desktop/gnome/connected_servers and decided not to not add servers there since (if I remember correctly): * there are protocols that Nautilus (gnome-vfs) can't handle (Telnet is the only one currently added but there are others... do we care?) that are interesting for terminals. * encoding etc can't be stored in /desktop/gnome/connected_servers (I guess these can be stored in gnome-terminals gconf space and the URI be fetched from /desktop/gnome/connected_servers...) * gnome-vfs uses sftp (right?), this mean that there can be SSH servers that are interesting for a terminal but not for Nautilus... Pretty please correct me if I'm wrong on any of these, it was a couple of months since I payed some thought to them. :) Guilherme, I would appreciate some feedback on the patch in bug 313480... perhaps more importantly, I would like to know if it's worth my time at all. ;)
Oh, I noticed there's just mockups in this bug. Perhaps it should be marked as a duplicate of bug 313480 then?
@martin: As Behdad indicated there is some interest in getting this feature. Question is: Should it be designed that invasive, as your patch is. I admit, that the profile list could become quite overloaded, when adding hosts detected via DNS-SD. Specially in computer pools of universities and such. So your dialog driven approach might make more sense, then my menu driven approach. Maybe we should work on breaking your patch into smaller pieces, for getting the feature in? It's my experience, that it is very hard (and waste of time) getting undiscussed, large and invasive patches into GNOME, but if you take the time and make small steps, patching GNOME works...
Let's discuss patches in the bugs they are attached to. :) Bug 313480 comment #18
Still have to give it a little more thought, because even though there might be problems with the Nautilus integration, completely duplicating this infrastructure doesn't sound like a very wise thing to do. We've been in feature freeze for quite some time now anyway, so no reason to hurry =)
Without mDNS module in nssswitch.conf ssh fails to resolve .local names, therefore we depend on bug 332759.
@Guilherme: Regarding hurry: Yes, no need to hurry, enhancement targets GNOME 2.15/16. Regarding code duplication: Guess since we have an DNS-SD API in GNOME-VFS the preferred method for detecting services without a builtin discovery service is using that DNS-SD API. So there really is no code duplication, when using DNS-SD for detecting secure shell (or *shrug* telnet) servers. If you compare the code found in the find-ssh.c attachment with any possible library API we could invent or even with analysing the content of "network:///", you'll see that using DNS-SD is the most sane way for detecting login services in our neighbourhood. Bookmarks for services which cannot automatically announce themself in one of the DNS-SD browse domains, the configuration files of Avahi or something like the attached Python script could be used, to announce them as pseudo local services in the mDNS browse domain (.local).
*** Bug 334976 has been marked as a duplicate of this bug. ***
I have some bigger ideas about integration with screen. Connecting to screen sessions is the first step. Next is to have an option to run all terminals inside screen automatically. It's a bit trickey to get it right, ie., have the g-t scrollbar working for example... It may be rewarding though, for example we can then easily add a search box using screen's search capabilities (bug 78963). But I agree that it may not be feasible.
*** Bug 149652 has been marked as a duplicate of this bug. ***
Retitling, letting bug 313480 be the "SSH support" bug.
What is the status of this bug ? I saw http://monia.wordpress.com/2006/08/31/integrating-gnome-terminal-and-screen/ , but it doesn't do much of what is described on http://live.gnome.org/GnomeTerminal/ScreenIntegration ... I'd really like to have all my gnome-terminal sessions handled by screen. Monia's approach doesn't fulfil my wishes. Basically, the problem with this approach is that you rely on the user to know in advance he will need to use screen. I can't count the number of times I ran something in gnome-terminal and then, when leaving, realize that I should have put it in a screen session so that I can continue working on it remotely. But at that very moment, it's already too late.
(In reply to comment #32) > What is the status of this bug ? > I saw > http://monia.wordpress.com/2006/08/31/integrating-gnome-terminal-and-screen/ , > but it doesn't do much of what is described on > http://live.gnome.org/GnomeTerminal/ScreenIntegration ... > > I'd really like to have all my gnome-terminal sessions handled by screen. > Monia's approach doesn't fulfil my wishes. Basically, the problem with this > approach is that you rely on the user to know in advance he will need to use > screen. I can't count the number of times I ran something in gnome-terminal and > then, when leaving, realize that I should have put it in a screen session so > that I can continue working on it remotely. But at that very moment, it's > already too late. This is a work in progress. When we are there, we will switch to starting inside screen all the time...
Another ping as to the status? Are these patches ready to into CVS (at least the vte and gnome-terminal ones) Also, those patches should be transferred here to bugzilla so they don't get lost if the blog goes away or otherwise disappears and so they can be kept up to date with CVS.
Also is Monia Cc'ed to this bug? If not, she should be. As the original developer of the patches it would be good so that she can remain aware of the status of this feature within GNOME.
Any progress reports?
*** Bug 473331 has been marked as a duplicate of this bug. ***
*** Bug 477443 has been marked as a duplicate of this bug. ***
See http://bugs.kde.org/show_bug.cgi?id=58868 for the equivalent KDE (konsole) bug. Persuading the screen developers to make a library would be neat :-)
What is the status on this? anyone still working actively on it?
(In reply to comment #40) > What is the status on this? anyone still working actively on it? No.
I guess there is still no new content. However I hope this will eventually be picked up again. It is still probably my most anticipated feature for the gnome-terminal.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/3380.