3 ms·

tmux is similar to screen. I can keep opening hotkeys to open new windows to run commands in, but then I have to remember to go back to those windows to look at

tmux is similar to screen. I can keep opening hotkeys to open new windows to run commands in, but then I have to remember to go back to those windows to look at the results of those commands, etc. It doesn't really help me "maximise my processor usage" I find.

eli 15y ago
I believe iTerm2 on OS X hooks into tmux somehow to alert you when something has happened in one of your windows. I assume there's a way to make that happen on other platforms too.
- karlshea 15y ago
  Unfortunately last time I checked it was only for a branch of tmux. They are trying to get it into mainline but I don't think that has happened yet.
sliverstorm 15y ago
So what you are saying is you want a more powerful version of regular shell background capabilities? You don't want output to interrupt your interactive session, but you don't want to have to remember to visit the output later. Do I have this right?
- CJefferson 15y ago
  I think so. I might not know what I want until I have it, or don't have it :) I just went through the following steps recently: 1) Put more things in the background with '&' - but if they have a lot of output they make your terminal usuable. 2) I could ' >t 2&>1 & ' , but then I have to remember to check t when the process finishes, and end up with lots of tiny files everywhere. 3) I could just send output to /dev/null , but then maybe I care what it was if the process fails.
  - sliverstorm 15y ago
    Perhaps you could alias a function that pipes like tee, and checks for errors. Like this: alias myfunc "errorchecker >& /dev/null" [command] | myfunc What it does with those errors is up to you, though your main options are "print them" (in which case, just don't redirect stderr), "log them for fetching" (and write a little command to access & manage the failure reports), or "email them to yourself". I guess basically what I'm getting at is, look at distributed processing backends such as LSF or GRD for inspiration.
  - natep 15y ago
    Sounds like #2 could work if you had some sort of desktop notification system. Then you could write a small script that runs your command line with stdout and stderr redirected to temp file(s), and then alerts you when the process is done, and what the temp filenames are. You could check on your running jobs with 'ps -C scriptname' Or maybe opens them in $EDITOR...like this (I can't get it to work when $* has a pipe in it, unfortunately) #!/bin/bash out1=`tempfile -d $HOME/logs` out2=`tempfile -d $HOME/logs` $* >$out1 2>$out2 $EDITOR $out1 $out2 # Replace this with call to notification app and/or logic based on $?/size of $out2
keeperofdakeys 15y ago
Tmux and screen have modes that allow you to 'watch' a window for activity, and alert you to this. They can even watch for inactivity, and warn you when something finishes. You can also use "echo ^v^g" (where ^ is ctrl) to summon a bell, tmux and screen can be configured to alert you to such a bell.

eli 15y ago

I believe iTerm2 on OS X hooks into tmux somehow to alert you when something has happened in one of your windows. I assume there's a way to make that happen on other platforms too.

karlshea 15y ago
Unfortunately last time I checked it was only for a branch of tmux. They are trying to get it into mainline but I don't think that has happened yet.

sliverstorm 15y ago

So what you are saying is you want a more powerful version of regular shell background capabilities? You don't want output to interrupt your interactive session, but you don't want to have to remember to visit the output later. Do I have this right?

CJefferson 15y ago
I think so. I might not know what I want until I have it, or don't have it :) I just went through the following steps recently: 1) Put more things in the background with '&' - but if they have a lot of output they make your terminal usuable. 2) I could ' >t 2&>1 & ' , but then I have to remember to check t when the process finishes, and end up with lots of tiny files everywhere. 3) I could just send output to /dev/null , but then maybe I care what it was if the process fails.
- sliverstorm 15y ago
  Perhaps you could alias a function that pipes like tee, and checks for errors. Like this: alias myfunc "errorchecker >& /dev/null" [command] | myfunc What it does with those errors is up to you, though your main options are "print them" (in which case, just don't redirect stderr), "log them for fetching" (and write a little command to access & manage the failure reports), or "email them to yourself". I guess basically what I'm getting at is, look at distributed processing backends such as LSF or GRD for inspiration.
- natep 15y ago
  Sounds like #2 could work if you had some sort of desktop notification system. Then you could write a small script that runs your command line with stdout and stderr redirected to temp file(s), and then alerts you when the process is done, and what the temp filenames are. You could check on your running jobs with 'ps -C scriptname' Or maybe opens them in $EDITOR...like this (I can't get it to work when $* has a pipe in it, unfortunately) #!/bin/bash out1=`tempfile -d $HOME/logs` out2=`tempfile -d $HOME/logs` $* >$out1 2>$out2 $EDITOR $out1 $out2 # Replace this with call to notification app and/or logic based on $?/size of $out2

keeperofdakeys 15y ago

Tmux and screen have modes that allow you to 'watch' a window for activity, and alert you to this. They can even watch for inactivity, and warn you when something finishes. You can also use "echo ^v^g" (where ^ is ctrl) to summon a bell, tmux and screen can be configured to alert you to such a bell.