Improve the terminal integration to preserve the current container for new terminals

rugk commented 5 years ago

I basically want to not do https://github.com/debarshiray/toolbox/issues/135 /https://github.com/debarshiray/toolbox/pull/199.

When I Ctrl+Shift+T (open a new tab) when I am in a toolbox in Fedora Silverblue, the new terminal also is in that toolbox?

So:

Can I disable this "feature"? How?
(If not) Can I at least somehow exit the toolbox in a new tab then without closing that tab? I.e. if I am in that toollbox in a new tab and enter exit, it actually closes this tab. Can I somehow get out of this without closing this tab?

original question from here: https://ask.fedoraproject.org/t/can-i-disable-automatic-toolbox-entering-when-new-terminal-tab-is-opened-in-gnome-terminal/2412?u=rugk Also basically requested here and @basvdlei also seems to ask for a way to disable that behaviour in https://github.com/debarshiray/toolbox/issues/135#issuecomment-508447430 if I understand correctly.

shaman007 commented 5 years ago

+1, very annoying by default.

cgwalters commented 5 years ago

I also think this is trying to solve an important problem in the wrong way. Personally I use custom gnome-terminal profiles, including one for my toolbox that gives me the tab behavior, without affecting the main Terminal app.

mildred commented 5 years ago

I quite like opening the toolbox automatically on a new tab, especially when not running the default toolbox. There is one thing though, when all tabs in a terminal are running a toolbox, we can only open a new window on the host.

You can probably disable the feature yourself in your dotfiles if you run inside the toolbox :

printf "\033]777;container;pop;;\033\\"

from https://github.com/debarshiray/toolbox/pull/199/files

Did not test that though

TheFrozenFire commented 5 years ago

:+1:, but to the second question of how to exit a toolbox. When you want to run system-level commands (e.g. rpm-ostree), there's no clear way to get out of toolbox.

shaman007 commented 5 years ago

@TheFrozenFire Ctrl+D?

TheFrozenFire commented 5 years ago

@shaman007 That's too obvious and simple for me. Are you sure you don't have a dbus command for that? (/s)

Thanks. :)

bkhl commented 4 years ago

I quite like opening the toolbox automatically on a new tab, especially when not running the default toolbox. There is one thing though, when all tabs in a terminal are running a toolbox, we can only open a new window on the host.

You can probably disable the feature yourself in your dotfiles if you run inside the toolbox :
printf "\033]777;container;pop;;\033\\"
from https://github.com/debarshiray/toolbox/pull/199/files

Did not test that though

I tested this and can confirm it works. In your container, you can put that command in a shell startup file, something like this:

bkhl@toolbox:~$ cat /etc/profile.d/~99start.sh 
printf "\033]777;container;pop;;\033\\"

jordanpwalsh commented 4 years ago

@bkhl This is working for me as well, but can someone explain exactly why?

bkhl commented 4 years ago

When toolbox is starting, it's pushing a value to this "stack", which is available to the Terminal when opening a new window.

It think it would be nicer though to be able to disable this feature entirely in toolbox.

EduCampi commented 3 years ago

I ended up installing tmux just to avoid this.

Maybe it could be a new command toolbox exit ? It would kinda fit, as we have already a toolbox enter

EDIT: Just noticed #578 suggested the same command, sorry for the spam

rugk commented 3 years ago

Oh yeah, maybe this should be closed as a dupe of https://github.com/containers/toolbox/issues/578?

maweki commented 3 years ago

Oh yeah, maybe this should be closed as a dupe of https://github.com/containers/toolbox/issues/578?

Or the other way around, as this issue is older and more discussed.

laolux commented 2 years ago

@TheFrozenFire Ctrl+D?

Does not work for me, closes the entire terminal window/tab. And when I open a new window/tab, then I am automatically trapped inside the toolbox. 🙁

EDIT: Ctrl+D logs me out of the toolbox in the original toolbox window (the one opened explicitly by toolbox enter), but that is often the one I want to keep running. When I open a new window, then it is automatically inside the toolbox and Ctrl+D will close the entire window. How can I leave the toolbox in a new window?

FilBot3 commented 2 years ago

I quite like opening the toolbox automatically on a new tab, especially when not running the default toolbox. There is one thing though, when all tabs in a terminal are running a toolbox, we can only open a new window on the host. You can probably disable the feature yourself in your dotfiles if you run inside the toolbox :
printf "\033]777;container;pop;;\033\\"
from https://github.com/debarshiray/toolbox/pull/199/files Did not test that though
I tested this and can confirm it works. In your container, you can put that command in a shell startup file, something like this:
bkhl@toolbox:~$ cat /etc/profile.d/~99start.sh 
printf "\033]777;container;pop;;\033\\"

Can confirm. I put the printf statement into a shell script and ran it. Then I pressed CTRL+SHIFT+t to launch a new terminal tab and it was outside of toolbox. So, yes it's annoying I have to do that, but it is nice to have when I want to reduce the number of windows I have open. So I have it as a shell script and run it before opening a new terminal.

ptalbert commented 1 year ago

I really do not like this "feature" and having to preemptively add something to each toolbox's profile is a terrible way to make users opt-out of it.

When support for this was hacked into gnome-terminal it should have provided a simple check-box option to turn it off.

laolux commented 1 year ago

@ptalbert If you are really upset about it, you might consider switching to distrobox. It provides very similar functionality to toolbox (well, allows more different distros) and when you open a new terminal window/tab from within a distrobox instance, it will open the terminal window/tab on the host, but inside the same directory that you are currently in. If the directory does not exist on your host system (e.g. /etc/emacs) or you don't have permissions to open it, then the new window/tab will be opened in your home directory. Very handy if you ask me.

ptoal commented 11 months ago

I keep bumping into this issue repeatedly. While I appreciate that some may find it handy to have an automatic toolbox session on new windows, it becomes very cumbersome when all your windows are within a toolbox, and you need to run a few commands outside the toolbox. Two suggestions:

This automatic toolbox behaviour should be a very clear option that can be enabled / disabled in preferences / profile.
It should be possible to bind a key (eg: CTRL-Shift-M) to "Open new terminal without Toolbox".

This is just a really frustrating problem sometimes, and I really don't think that it should be default enabled, because it's non-intuitive.

debarshiray commented 10 months ago

I realized that I never commented on this issue.

First things first. While there are clearly many who find it annoying that Fedora's GNOME Terminal and VTE forks preserve the current Toolbx container, there are several (albeit less vocal) who also want it. Here's someone who wants this on Arch Linux. Ultimately, this was implemented in response to a feature request. I have myself found it useful to not have to repeatedly type toolbox enter in the middle of intense hacking sessions.

Similarly, there are just as many who love GNOME Terminal's profiles as those who don't want those in the default terminal emulation application. Given that our final goal, at least for Fedora Silverblue, is to get to a point where the Toolbx shell can be the default shell, it's tricky to design this fundamentally around profiles.

Thirdly, Toolbx only notifies the terminal emulator about the current container. It's on the terminal emulator to honour that or not. So, one workaround is to switch to a different terminal app on Fedora other than GNOME Terminal.

I can't believe I just suggested to not use the Fedora defaults. :P

Another option, as @bkhl showed, is to put this in your ~/.bash_profile or ~/.bashrc to disable this feature persistently:

[ -f /run/.toolboxenv ] && printf "\033]777;container;pop;;\033\\"

As things stand today, we cannot offer a user-visible setting in Fedora's forked GNOME Terminal to disable this feature because we will need a separate translation infrastructure for that single string associated with the setting. And it won't get into upstream GNOME Terminal until this idea has been standardized, or at least widely accepted, in the terminal emulation community. And that's difficult because things tend to move slow in the terminal emulation world, and things like OSTree and Toolbx are too bleeding edge in comparison.

One way to move forward is to use a terminal app like Prompt, not GNOME Terminal, that's designed for a container-oriented desktop and is a lot more excited to offer features like this.

Like I said before, it's almost trivial for the terminal emulator to have separate ways of opening a new terminal with or without preserving the current container. Doing that with GNOME Terminal will only require more forking with the added restriction of not introducing new user-visible strings. That's not fun.

Another option is to provide shims for well-known binaries, which can only run on the host, inside the Toolbx containers, and finally, possibly a way to request a host shell from inside the container.

ptoal commented 9 months ago

Appreciate you adding some context, @debarshiray .

The big UX failure with this issue isn't that the feature isn't useful. I do appreciate the ability to spawn a new terminal, and still be in the toolbox. Very handy. The failure is that if you're deep into 10 toolbox sessions, there's no easy way to spin up a single new non-toolbox terminal when the need arises. Which it did often enough, for me, that it became really annoying. You either have to spin up a whole new terminal app, or exit all your terminals, so you can spin up one outside the container.

Unfortunately, for me, the entire toolbox approach ended up being too cumbersome for my workflow so I abandoned Silverblue entirely, for now. I don't think I'm ready for an immutable OS.

For me, the decision to switch back to plain Fedora was the frustration of trying to get Ansible Execution Environments (containers) to work with toolbox and vscode. (https://github.com/ansible/vscode-ansible/issues/1020). I got a lot of the way there with https://github.com/owtaylor/toolbox-vscode, but in the end, I just found I was fighting the paradigm too much (flatpak's were another frustration) The benefits I got from Silverblue didn't outweigh the amount of effort it took to get things to work for me. I'm a little disappointed I don't have more time and patience to make this work, because I like the idea.

debarshiray commented 9 months ago

The big UX failure with this issue isn't that the feature isn't useful. I do appreciate the ability to spawn a new terminal, and still be in the toolbox. Very handy. The failure is that if you're deep into 10 toolbox sessions, there's no easy way to spin up a single new non-toolbox terminal when the need arises. Which it did often enough, for me, that it became really annoying. You either have to spin up a whole new terminal app, or exit all your terminals, so you can spin up one outside the container.

Yeah, currently, toolbox enter behaves a lot like bash(1) or zsh(1) in the sense that it starts a nested (for the lack of a better term) shell. The other option is to make it work more like git checkout where the environment would change underneath without any nesting.

The former approach was a lot easier to implement.

I am curious about the exact problem you face when you are deep into 10 toolbox sessions. Would it help if the terminal app gave you the option of spawning a terminal directly on the host? Perhaps through a separate UI element or keyboard shortcut? What if there was a Toolbx command that did the inverse of toolbox enter and got you a host shell?

For me, the decision to switch back to plain Fedora was the frustration of trying to get Ansible Execution Environments (containers) to work with toolbox and vscode. (ansible/vscode-ansible#1020). I got a lot of the way there with https://github.com/owtaylor/toolbox-vscode, but in the end, I just found I was fighting the paradigm too much (flatpak's were another frustration)

Yes, I agree that the next big step in the Toolbx story is to work out a solid story for IDE integration. You already found @owtaylor 's initial work in that direction, but there's more to be done.

You could also use GNOME Builder, which is a container-native IDE, but I understand that it's not always a practical option. :)

cjao commented 9 months ago

The failure is that if you're deep into 10 toolbox sessions, there's no easy way to spin up a single new non-toolbox terminal when the need arises. Which it did often enough, for me, that it became really annoying. You either have to spin up a whole new terminal app, or exit all your terminals, so you can spin up one outside the container.

My crude workaround for this very scenario is to define in my .bashrc:

admin()
{
    if [ -f /run/.toolboxenv ]; then
    host gnome-terminal
    fi
}

monreal commented 9 months ago

FYI the solution for me was moving to the Prompt terminal app last week. Really impressive app with (as far as my use cases go) perfect integration of containers, ssh and sudo.

cben commented 8 months ago

I started using toolbox 0.0.99.5 today on fedora 38 (NOT silverblue, I'm just while following some tuturial that didn't want to mess up my host), and was mystified how toolbox takes over new gnome-terminal tabs — and how to get back a host terminal. Places I thought to look:

Did it create a new gnome-terminal profile? Nope.
Did it edit my gnome-terminal profile with a custom command? Nope.
Did it edit my .bashrc etc? Didn't check them all, but having later found #135 I know the answer is no. I also found out xterm gives me a host terminal, so it can't be at shell level.
Does it perhaps work like cwd-in-new-tab? I happen to know enough to inspect eval $PROMPT_COMMAND | cat -A and I can see ^[\^[]7;file://toolbox/home/beni... printed there — but nothing about a custom runner.
Does it appear elsewhere in gnome-terminal settings? Nope.

It doesn't help BTW that gnome-terminal --help inside my current toolbox gives "command not found" :stuck_out_tongue_closed_eyes:

The thing about Ctrl+D working differently in the original tabs vs. later tabs is particularly confusing. :-1:
The combination of terminal maintaining a stack with workaround printf "\033]777;container;pop;;\033\\" in every new tab is a complex mental model — how come it doesn't underflow the stack if you do multiple pops?! Well, I think it works because the stack is per-tab (each tab runs separate vte interpretting escape sequences). Each new tab then starts with a copy of the stack (or just the top element) so a pop

Important discoverability things toolbox enter should have done:

Document the behavior in manpage and --help!
Have a flag to opt in/out #384.
Print a hint, at start of each tab, how to get a host terminal.

Better mitigation: do use escape sequences, but each new tab should launch a host shell that launches toolbox enter session, so advice to Ctrl+D or exit applies everywhere? Hmm, this might fail the goals of #135 Silverblue of being transparent?

Simpler UX idea: what if toolbox did not affect current terminal, but launched an entirely new window pre-configured to use the toolbox?
I mean, there should obviously also be a mode that enters within current terminal, no window system required or affected. But for purposes of #135, the whole point is to affect a terminal emulator, that has to cooperate too. IMHO silverblue could take care of system-wide defaults, and I think on other systems it should be opt-in e.g. toolbox enter --gnome-terminal could effectively launch:

gnome-terminal --title="fedora-toolbox-38" -- toolbox enter fedora-toolbox-38

Well, that doesn't work — new tabs/windows from that window open the default command :neutral_face:. It would have to either use --profile or some new flag that does inherit the command to new tabs and windows opened from that window.

But the upside, zero escape-sequence magic needed :+1:, just simple command line flags — presumably an easier sell to terminal emulators. And any UNIX user could undestand how it works. It'll be right there in ps :+1:.

Second, your original terminal stays a host terminal (toolbox exits there immediately), so it's clearer how to launch a new host one?

containers / toolbox

Improve the terminal integration to preserve the current container for new terminals #218