You can use ssh/config's localcommand option to run a command whenever an alias is used. I use
host hostname
user myusername
localcommand xtermcontrol --bg '#abc'
This depends on xtermcontrol and your term being xterm. Presumably there are other apps for other terms.
The only problem with this approach is that it happens when you call ssh. There's nothing to undo the color change. I've done it by wrapping a function around ssh, but that has its drawbacks too.
function ssh() {
FG=$(xtermcontrol --get-fg)
BG=$(xtermcontrol --get-bg)
$(which ssh) "$@"
xtermcontrol --fg="$FG"
xtermcontrol --bg="$BG"
}
A process isn't "killed with SIGHUP" -- at least, not in the strict sense of the word. Rather, when the connection is dropped, the terminal's controlling process (in this case, Bash) is sent a hang-up signal*, which is commonly abbreviated the "HUP signal", or just SIGHUP.
Now, when a process receives a signal, it can handle it any way it wants**. The default for most signals (including HUP) is to exit immediately. However, the program is free to ignore the signal instead, or even to run some kind of signal handler function.
Bash chooses the last option. Its HUP signal handler checks to see if the "huponexit" option is true, and if so, sends SIGHUP to each of its child processes. Only once its finished with that does Bash exit.
Likewise, each child process is free to do whatever it wants when it receives the signal: leave it set to the default (i.e. die immediately), ignore it, or run a signal handler.
Nohup only changes the default action for the child process to "ignore". Once the child process is running, however, it's free change its own response to the signal.
This, I think, is why some programs die even though you ran them with nohup:
- Nohup sets the default action to "ignore".
- The program needs to do some kind of cleanup when it exits, so it installs a SIGHUP handler, incidentally overwriting the "ignore" flag.
- When the SIGHUP arrives, the handler runs, cleaning up the program's data files (or whatever needed to be done) and exits the program.
- The user doesn't know or care about the handler or cleanup, and just sees that the program exited despite nohup.
This is where "disown" comes in. A process that's been disowned by Bash is never sent the HUP signal, regardless of the huponexit option. So even if the program sets up its own signal handler, the signal is never actually sent, so the handler never runs. Note, however, that if the program tries to display some text to a user that's logged out, it will cause an I/O error, which could cause the program to exit anyway.
* And, yes, before you ask, the "hang-up" terminology is left over from UNIX's dialup mainframe days.
** Most signals, anyway. SIGKILL, for instance, always causes the program to terminate immediately, period.
Best Answer
I would suggest setting your $PS1 to relevant information, like hostname, etc. You can check your shell of choice's man page for details.
An example of things you could do to your PS1 in bash
I myself have a test in my ~/.subbash/prompt that sets the prompt's color based on server.*
*see __prompt_command() function
Ways You could change your PS1
There are any number of ways you can customize the PS1, It sound like you want something a little more noticeable, so my examples will be a little more complicated then just adding the
\Hto the PS1. To use any of the following, you could add them to your~/.bashrc(on the remote servers, if not both. I sync the same conf between all my computers)Note: To make these more readable, the following assumes that these vars are declared.
The var could easily be replaced with the contents.
Also, these examples are bash biased, you may have to tweak for other shells.
Root Check
One thing you might like is test the $USER, for if it is root, or maybe a 'production' only account:
This would make the prompt red if you where root.
Host check
You could also test for information about the current machine, and set colors based on that:
This would set the prompt cyan if on my laptop, green for my pi or iOS, etc etc.
If if wasn't listed, it would add the hostname to the prompt.
So if your production servers had something that was easy to test for (like a similar hostname, you could use that)
PROMPT_COMMAND
For the most part the above would work fine without this.
If you start adding things that you would want re-evaluated more often the login (maybe git status of a dir), you could use a PROMPT_COMMAND function to have the PS1 evaluated after each command.
The Above work fine without this.
Note: Sorry if these seem confusing, these are taken from settings I use, and modified to work without the rest of my settings.