On Fri, Feb 22, 2013 at 11:53:21AM -0300, Thiago Padilha wrote: > On Fri, Feb 22, 2013 at 10:30 AM, Nicholas Marriott > <nicholas.marri...@gmail.com> wrote: > > For the first of these you can already use the tmux global environment > > or use user options which were added very recently you only need to > > worry about the second. > > > Nice to know about user options. Even so, I think it still misses the > atomic 'get if exists, if not set and return', adding a optional > [default] argument to the showenv/show-option would solve the problem
Two new flags to set-option, one to "show value" and the other to say "only set if doesn't exist", would be fine. > > > I do not see compelling uses that can't be solved with existing shell or > > Unix features, can you give us some examples? > > > I have came across one use case: when you start a program in a new > tmux pane/window from a script, but need to wait until the program is > fully started before continuing execution. Here is a simple example: > https://github.com/tarruda/dot-files/blob/master/.zsh/tmux.d/vi.zsh#L35-L55 > . In this case, I achieved the semaphore effect by using a named pipe > and having the newly spawned process send data through it when ready, > but having a simple tmux command for that would made the job easier > and the code cleaner. I'm not sure your case is particularly related to tmux, it could be any sort of script really. However, it has been mooted before having a command to wait for a pane to exit/close or some other event. That would be quite useful and definitely is related. And once we have Thomas' hooks code, a general-purpose wait/signal command might be the best way of achieving this - because you could then add a hook to a pane to signal when it has exited. However, he will need to confirm that this will work, at least in principle even if the code isn't there yet. If it would work, then a command like you suggested where you can do: tmux wait-for abcdef # wait on signal abcdef tmux wait-for -S abcdef # wake all waiting on signal abcdef Would make your script easier and also solve the case where you want to wait, for example, for a tmux pane to close. So in summary, if you want to write it, do it and it will almost certainly be used :-). I would suggest you work on the set-option changes first though. > It would not have been so simple if multiple processes needed to > wait(or one process waiting for many). Unlike a shell, tmux cannot > pipe its subprocesses stdio with each other. > > Probably there are other use cases/workflow scripts that could benefit > from a simple synchronization mechanism(I've only started scripting > tmux for a month). I'm sure other people would find other uses for if > those features were available. > > > tmux is not a programming language or a shell so features need to fit > > with it's purpose :-). > > > Tmux already has some features not directly related to managing > terminal windows, that enabled the development of nice tools(one > example is the vim slimux plugin). > > I'm sure there are shell script hacks for almost any use case, but > since one of tmux goals is to be automated by shell scripts, why not > provide tools to make the job easier? > > The main UNIX philosophy is 'do one thing, and do it well', and since > tmux job is to integrate applications(thats my opinion on what tmux > role is), synchronization/shared memory mechanisms are well within its > realm. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
