Using popen leaves the server vulnerable to "freezing up" if the user configures a long-running command for copy-pipe (or dead locking if the command uses a tmux command (e.g. to make a query)).
A copy-pipe command may need certain environment variables (e.g. xclip uses DISPLAY). With popen, the command will inherit its environment from the server's actual environment (not even the configurable global environment), so it could be missing important variables. Although using the global environment would at least make it possible to adjust the values that the command inherits, it might be better to use the active session's environment. This would keep the user from having to update (e.g.) the global DISPLAY since the session's DISPLAY is usually automatically updated when attaching. Using a job instead of popen should help fix these lockup and environment issues. I have prototyped some changes that do the following: * add a session argument to job_run, if non-NULL its environment is added atop the global environment, it is also passed to server_fill_environ * pass the session to copy_window_copy_pipe, which passes it to job_run * in job_run, * use the session environment, and pass it to server_fill_environ * dup the socket to stdin (along with stdout; instead of /dev/null) * supply a write callback for job->event * in this new write callback * if the output buffer is empty, shutdown the writing half of the socket * in window_copy_copy_pipe, start a job and bufferevent_write into its event to supply data on the command's stdin In most situations, the writing half of the socket will simply be shutdown the next time the event loop runs (which fixes a potential client-hanging problem with an unlikely command like "tmux run 'cat /dev/stdout'"). In the case of copy-pipe, it has its data fully prepared and stuffs it into the outbound buffer before the event loop has a chance to run again, so shutting down the writing half will be deferred until the outbound buffer has been drained. This is not sufficient for long running, full duplex jobs, but it is enough to let us send one chunk of preprepared data to the job. Also something that may be related: I noticed that the cmd_q commit added "out" and "outdone" fields to struct job, but they do not appear to be used anywhere. Was this maybe the early bits of some more fully formed support for full duplex jobs? -- Chris ------------------------------------------------------------------------------ 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_mar _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users