Bash – An alias for a command to kill stopped jobs

If you are using bash, you can set the IGNOREEOF shell variable to a number that specifies how many consecutive EOF chars the shell should ignore before treating the EOF as an exit signal. Check the man page for specifics.

However, that triggers before the "there are stopped jobs" message triggers, so you still have the same problem - you get that message, and one more ^D exits the shell.

An alternative is to put the number of shell jobs into your prompt if that number is greater than zero.

For example, an excerpt from my .bashrc:

PROMPT_COMMAND=prompt_command
prompt_command() {
    job_count=$(jobs | wc -l)
    if [ $job_count -gt 0 ] ; then
        prompt_job="[$job_count] "
    else
        prompt_job=""
    fi
}
PS1="...\${prompt_job}..."

After this the shell may look like ...[1] ...

That puts a job count in your prompt if it is greater than zero. This makes it easy to see when you have incomplete jobs and works well (for me) as a visual reminder that jobs are still running.

The problem is that your alias definition (the one of iseRemoveSetup) is in a subshell:

alias analyzer='setupise;'`iseAddToRemoveCall "analyzer"`

For iseAddToRemoveCall "analyzer" a subshell is started and the alias definition affects only this subshell which is gone as soon as this line is done.

This could be solved by changing

alias analyzer='setupise;'`iseAddToRemoveCall "analyzer"`

to

alias analyzer='setupise;$(iseAddToRemoveCall analyzer)'

and replacing echo "iseRemoveSetup;$1" (in iseAddToRemoveCall) with echo "unalias $1;$1". Thus the unalias would become part of the alias expansion and would be executed in the correct shell.

alternative

All this seems quite strange to me. Wouldn't it make more sense to start a subshell (type bash), run the setup, run the commands, and leave the subshell (^D) when finished?

additional remarks

man 1 bash:

The first word of the replacement text is tested for aliases, but a word that is identical to an alias being expanded is not expanded a second time. This means that one may alias ls to ls -F, for instance, and bash does not try to recursively expand the replacement text.

So you don't need unalias p1 in your alias definition before you call pi from it.

It may be better to use an (associative) array with the commands you want to unalias and just work with the array.

This is important, too, because you do exactly what you ought not to do:

Bash always reads at least one complete line of input before executing any of the commands on that line. Aliases are expanded when a command is read, not when it is executed. Therefore, an alias definition appearing on the same line as another command does not take effect until the next line of input is read. The commands following the alias definition on that line are not affected by the new alias. This behavior is also an issue when functions are executed. Aliases are expanded when a function definition is read, not when the function is executed, because a function definition is itself a compound command. As a consequence, aliases defined in a function are not available until after that function is executed. To be safe, always put alias definitions on a separate line, and do not use alias in compound commands.