Guake: Send argument to tmux shell

[rafee]

I tried to use tmux as shell for guake, but I couldn't get it to work with 256 colors. It works nice with tmux -2, but I can't see any way of passing argument to shell in guake. I already tried setting, set -g default-terminal "screen-256color" in .tmux.conf, but that didn't work. It can be an issue with Tmux or anything else.
My system specification

Fedora 20, 64 bit
guake from rpmfusion

[gsemet]

don't see how this is related to guake. Closing it

[fx-kirin]

I'd love if it has an option to pass "-2" argument to tmux. It will be the only way to avoid tmux's 256 color problem and passing parameters to a interpreter will help many other problems.

For my hack, I made a script /usr/bin/tmux2 contains like below.

#!/bin/bash
tmux -2

and changed /etc/shells to add /usr/bin/tmux2.

[jep-dev]

And that's how it happens - you and everyone else have to change system-wide configurations because a userland application feels safe omitting a cheap but ubiquitous feature. The fact that you can just add your arbitrary script to /etc/shells and get past this limitation is proof that (a) it's an essentially effortless change, (b) the constraint is artificial, and (c) users who are met with this kind of response are driven to give their systems some home surgery, which means no one can reasonably assume users' configuration files are any more reliable than the command they could add to their emulators' configurations. There's even an option to provide a custom script to execute, but no option to associate it with restarting the shell, it just runs once when you start the application! Seriously, look at Tilda, look at Yakuake, take your pick. I seriously mean no offense, because I appreciate the features like the Dbus bridge and it would be hard to convince me this was beyond you. Whether it's beyond you or below you, I mean, we're on Github. In any case, I can say that this is not a Tmux issue for certain - if you only call binaries by name, you're giving up parameters, prepended env/variable assignments, I/O redirection, and I'm sure that's not all.

As a workaround in case I pull a DenverCoder9, you may be able to watch the startup script directly or an associated canary/sentry file and relaunch/reattach it, especially if we're talking about Tmux/Screen/etc. - I would consider this inelegant, and fragile compared to editing /etc/shells, but it would at least insulate the fragility some. I don't even set my user default shell to my shell of choice - I can screw up my rcfiles and bounce back without losing so much as a session. Of course you should get comfortable with your own system maintenance, but it should never be necessary to get from point A to point B in userland.

[gsemet]

feel free to hack the code and submit a pull request

[jep-dev]

Will do. I'd be happy to contribute, I was mostly reacting to the dismissal. (I believe your comment initially said to contact the Tmux devs? The '-2' is a boolean switch and flipping it would just transfer the problem to others. Besides, it has its own parallel to Guake's '-e' and it's pretty important if you have any interest in decoupling the shell's and emulator's lifespans.) Was your intention to PR back through Kneirinck or continue to maintain it independently? I didn't see that this thread was a couple of years old already or that you weren't involved in the master, and each hop back to the master is another 1200 commits to integrate.

[gsemet]

I am not a tmux user myself, so i never encountered this issue myself. This thread is 4 years old and we are still fixing issues after the transition to gtk3. But feel free to take the time to understand how to fix it properly and prepare a pull request to Guake, I'll be happy to review and integrate it

[jep-dev]

Last thread I was watching - I added a workaround (Guake invokes script that signals Guake to run the given command verbatim, as requested) but the OP's solution suited my needs much better, since it controls Guake's per-shell command without affecting any other programs or requiring root:

gconftool --type string --set /apps/guake/general/default_shell \
    /home/naftuli/.local/bin/tmux-thndr.sh

@rafee, does/would this work for you? The script is just a wrapper for your Tmux invocation, unless you want it to do more (test for recoverable sessions, start with splits, etc.) I've verified that it works without root on the upstream version (0.8.4). My script is simply

#!/bin/bash
tmux -2

By default, the key /apps/... corresponds to $HOME/.gconf/apps/... (and read-only fallback candidates in /etc). Gconftool is the CLI into this structure. Have fun!

[gsemet]

Maybe you can add a script name /usr/bin/tmux-2 that only launch tmux with the right arguments

[jep-dev]

My /usr/bin/ is root-owned, isn't yours? Changing the name means you could put it anywhere you want - if it's not in /etc/shells you're in the same situation, you have to be root. The gconf solution (or at least editing the file gconftool and Guake are editing) is really the "right" way unless/until this gets enough support.

I own my system and I have no problem signing in and making changes. It's just separation of concerns for me. User files and executables go in user directories. Clone the user and make any changes you feel like without any concern of breaking the other. Back up the user and the system independently. I installed with a separately-mounted /home, and since then I reinstalled and had everything back precisely the way I had it before within 2-3 hours. Imagine what this would be like for an actual sysadmin managing a couple of dozen workhorse servers and maybe a hundred or more employees connecting remotely and so on. Either this application is strictly meant for solo hobbyists, or a professional dev needs to get upper management to approve his custom shell script as a replacement for a system-wide binary from the official package maintainers just to change a single parameter, right?

[gsemet]

I don’t really understand what you mean regarding gconf, guake 0.8 and 3.0 store their settings using dconf and not gconf.
Anyway, I hope you found a way to run your command :)

[jep-dev]

I'm using Guake 0.8.4-1, and as far as I can tell, Gconf settings were still being honored by Gsettings, so Dconf was updated and Guake pulled them from there. (They looked like front ends to the same repository because they were quietly synchronized, and nothing clued me in that gconf was obsolete or I would have looked into migrating what I could in advance.) I moved .gconf/apps/guake and Guake started with all the same preferences, including the shell set by gconftool. I can change a parameter from dconf-editor and see the timestamp on the file change, but Guake doesn't read or write to that file, and that's after closing it and forcing dconf to update (flush the cache, I assume.) That means... Guake isn't using gconf, dconf, or the cache, it's just using it's own transcendental config to remember the shell I gave it - a 'shell in the ghost'. Thanks though. :)

--Oh, and all of that is my problem or a problem for another thread, I was just trying to finish what I started and find the CLI equivalent to what I posted earlier. The path is the same under dconf-editor, but I recommend anyone doing this to double-check their startup script, Guake is still going to run it in your new shell even if they have the same path, and muxers, session managers, etc. don't typically like to be nested.

[jep-dev]

Could you elaborate on "guake 0.8 and 3.0 store their settings using dconf and not gconf"? It looks like gconf variables are still watched/loaded 20 times in gsettings.py and written about 40 times in prefs.py. I haven't read enough to know the bigger picture, but I'm gconf-free now, and Guake is synced with dconf, so I'm trying to do a bit of a postmortem from the old .gconf and dconf dump. Before the last batch of changes, running Guake would recreate .gconf to store its preferences, and after, it would just add them to dconf - seems worth tracking down.

[gsemet]

I use the dconf api, but depending on the system maybe it exposes in gconf as well. I was’t aware of this behavior