Re: tmux not respecting disabled control flow
On 2013–05–24 Chris Johnsen wrote: That renaming behavior (based on the actual command string, not the process that is running) sounds like what oh-my-zsh does. You could probably modify omz_termsupport_preexec in lib/termsupport.zsh to ignore your stty prefix (similar to the way it strips off sudo/ssh/rake and their options from the start of the command string before using the rest as the basis of the new name). I don't use oh-my-zsh, however I copied this function and added stty to the list of ignored strings and it works. Thanks for the tip Marco -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
Sounds like it doesn't work for noninteractive shells, probably need to put the stty somewhere that your shell always reads even if noninteractive. Surely vim should be turning off flow control itself though? On Tue, May 14, 2013 at 04:28:01PM +0200, Marco wrote: Hi, I already asked this question on stackexchange??, but I got no response. Here's my problem: In my shell I have flow control disabled using stty -ixon. This works perfectly in the shell and when I launch tmux and start programs within tmux. However, when starting a new session from the command line and directly launching a command, the flow control setting is not respected and ctrl-s freezes the terminal. This works: tmux new-session -s foo vim This does not respect the stty flow control setting: tmux new-session -s foo vim How can I disable flow control even in the latter case? Regards Marco ?? http://unix.stackexchange.com/q/75711/12779 -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
Nicholas Marriott wrote: Sounds like it doesn't work for noninteractive shells, probably need to put the stty somewhere that your shell always reads even if noninteractive. Surely vim should be turning off flow control itself though? I think that turning flow control off is the only reasonable thing for a full-screen application such as vim. Vim isn't the only one that doesn't do it though. From the top of my head neither do mutt, cmus and wyrd. I'm sure there are lot of other ones that don't do it either. Regards, Frank -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
Marco wrote: On 2013–05–14 Nicholas Marriott wrote: Surely vim should be turning off flow control itself though? As Frank already pointed out, it happens with all applications. To be fair, there are applications that do the right thing. The terminal version of emacs for example. You could create a wrapper script like this: [snip] #!/bin/sh stty -ixon exec $@ [snap] And then make tmux spawn programs like this: wrapper mutt -f ~/Mail/Inbox Regards, Frank -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
On 2013–05–14 Frank Terbeck wrote: On 2013–05–14 Nicholas Marriott wrote: Surely vim should be turning off flow control itself though? As Frank already pointed out, it happens with all applications. To be fair, there are applications that do the right thing. The terminal version of emacs for example. I just tried the most important terminal application I regularly use and they all behave the same, even system tools like htop, iftop, etc. You could create a wrapper script like this: [snip] That's a workaround I will use until I find a solution. Thanks for that. Why is this happening in the first place? If the stty setting is active in the current shell why is it deactivated in it's child? What would be the best place to fix this, tmux or the shell? I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Marco -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
On 2013–05–14 Marco wrote: What would be the best place to fix this, tmux or the shell? Sorry, stupid question. It would have to be fixed in *all* shells, since it's not just one, which would probably be the same hassle as fixing all programs. I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Is there anything that can be done from within tmux? Marco -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
Marco wrote: On 2013–05–14 Marco wrote: [...] I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Is there anything that can be done from within tmux? I suppose having an option for new-window and new-session and/or a server setting that sets the default state of the flowcontrol in the terminals tmux provides, wouldn't be a completely ridiculous thing to ask for. But I know about nothing of tmux's internals to quickly whip up a patch for that. Regards, Frank -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
On 14 May 2013 21:24, Frank Terbeck f...@bewatermyfriend.org wrote: Marco wrote: On 2013–05–14 Marco wrote: [...] I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Is there anything that can be done from within tmux? I suppose having an option for new-window and new-session and/or a server setting that sets the default state of the flowcontrol in the terminals tmux provides, wouldn't be a completely ridiculous thing to ask for. But I know about nothing of tmux's internals to quickly whip up a patch for that. I'm not so sure this is a good idea. You'd end up with having to duplicate much of stty's functionality here. Chalk another one up for hook support perhaps. Thomas Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
Thomas Adam wrote: On 14 May 2013 21:24, Frank Terbeck f...@bewatermyfriend.org wrote: [...] I suppose having an option for new-window and new-session and/or a server setting that sets the default state of the flowcontrol in the terminals tmux provides, wouldn't be a completely ridiculous thing to ask for. But I know about nothing of tmux's internals to quickly whip up a patch for that. I'm not so sure this is a good idea. You'd end up with having to duplicate much of stty's functionality here. Chalk another one up for hook support perhaps. Ha! Indeed. :-) Regards, Frank -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
IXON could be pulled from the client termios like t_cc, look at window.c:780. I'm not sure about doing this because there isn't a termios available for already attached sessions or for clients where stdin is not a tty. We could fix that but it'd still vary depending where you create the window from (different terminals, or command prompt, or config file). This is something we have typically tried to avoid in the past. We probably need to review where the various bits that make up the environment for a new window come from in each case. On Tue, May 14, 2013 at 10:22:53PM +0200, Frank Terbeck wrote: Marco wrote: On 2013???05???14 Marco wrote: [...] I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Is there anything that can be done from within tmux? I suppose having an option for new-window and new-session and/or a server setting that sets the default state of the flowcontrol in the terminals tmux provides, wouldn't be a completely ridiculous thing to ask for. But I know about nothing of tmux's internals to quickly whip up a patch for that. Regards, Frank -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
Actually I wonder if it should instead be saved at server start - like the initial global environment. The trouble is that if you start tmux with a messed up termios you are then SOL until you restart entirely. We know the system default termios will be sane. On Tue, May 14, 2013 at 11:22:04PM +0100, Nicholas Marriott wrote: IXON could be pulled from the client termios like t_cc, look at window.c:780. I'm not sure about doing this because there isn't a termios available for already attached sessions or for clients where stdin is not a tty. We could fix that but it'd still vary depending where you create the window from (different terminals, or command prompt, or config file). This is something we have typically tried to avoid in the past. We probably need to review where the various bits that make up the environment for a new window come from in each case. On Tue, May 14, 2013 at 10:22:53PM +0200, Frank Terbeck wrote: Marco wrote: On 2013???05???14 Marco wrote: [...] I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Is there anything that can be done from within tmux? I suppose having an option for new-window and new-session and/or a server setting that sets the default state of the flowcontrol in the terminals tmux provides, wouldn't be a completely ridiculous thing to ask for. But I know about nothing of tmux's internals to quickly whip up a patch for that. Regards, Frank -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
On 2013–05–14 Frank Terbeck wrote: You could create a wrapper script like this: [snip] #!/bin/sh stty -ixon exec $@ [snap] I found another workaround which does not require changing the scripts that launch tmux. Commands in the file ~/.zshenv seems to work regardless of the type of shell (login, interactive, etc.). # ~/.zshenv stty -ixon Obviously this is a ZSH feature. I don't know if a universal solution exists which works also in POSIX shell. Marco -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
There are a number of places you can create a new window in tmux and the difficulty is that several of these don't have an obvious parent or have a choice of parents. We have typically chosen - with a few exceptions - to try and make tmux create all windows with the same environment no matter how they are started. This means things are mostly consistent. We might change this but it'll need some thought. The problem for you is that tmux is starting all your shells with the same termios and you are promptly changing it in some shell startup file. But when you run a command directly your shell, which I guess is probably bash, decides it is noninteractive and doesn't run your startup files. You will have the same problem if you do, for example, xterm -e vim. The easiest solution is to run stty -ixon; vim or you could look at BASH_ENV which is apparently also evaluated for noninteractive shells. You'll need to make sure BASH_ENV ends up in the tmux global environment (either it's in your environment at server start or you set it explicitly with tmux setenv -g). On Tue, May 14, 2013 at 07:34:35PM +0200, Marco wrote: On 2013???05???14 Frank Terbeck wrote: On 2013???05???14 Nicholas Marriott wrote: Surely vim should be turning off flow control itself though? As Frank already pointed out, it happens with all applications. To be fair, there are applications that do the right thing. The terminal version of emacs for example. I just tried the most important terminal application I regularly use and they all behave the same, even system tools like htop, iftop, etc. You could create a wrapper script like this: [snip] That's a workaround I will use until I find a solution. Thanks for that. Why is this happening in the first place? If the stty setting is active in the current shell why is it deactivated in it's child? What would be the best place to fix this, tmux or the shell? I know you think the programs are at fault, but apparently it's common practice to make applications respect the stty setting, regardless if it makes sense or not. It's just not practical to file a bug report against so many applications. Marco -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux not respecting disabled control flow
On 2013–05–14 Nicholas Marriott wrote: We have typically chosen - with a few exceptions - to try and make tmux create all windows with the same environment no matter how they are started. This means things are mostly consistent. I don't have much knowledge about terminals internals, so bear with me if this is a foolish idea. What about using the environment that tmux was started in, instead of a clean one? The problem for you is that tmux is starting all your shells with the same termios and you are promptly changing it in some shell startup file. But when you run a command directly your shell, which I guess is probably bash, decides it is noninteractive and doesn't run your startup files. That explains it. BTW: I use different shells on different systems, mostly bash and zsh. You will have the same problem if you do, for example, xterm -e vim. Indeed. However, I never noticed that. The easiest solution is to run stty -ixon; vim I'd call it “workaround”. I would have to prepend almost every program call in all scripts with “stty”, that's not really elegant and it's duplicated code. or you could look at BASH_ENV which is apparently also evaluated for noninteractive shells. You'll need to make sure BASH_ENV ends up in the tmux global environment (either it's in your environment at server start or you set it explicitly with tmux setenv -g). This works, for ZSH ~/.zshenv can be used, see my other post. Thanks for your comprehensive answer. Marco -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
