Background subshells may finalize session

[davefx]

After loading bash-preexec.sh, if I launch, for example: $ ( ls ) & most of the times, bash exits (not always).

[rcaloras]

@davefx thanks for reporting. Just recognizing this now as a result of some issues with bashhub that's using bash-preexec. Believe the changes made to support subshells in 0.3.0 cause this. You can use 0.2.3 if you don't mind losing subshell support.

[rcaloras]

@davefx Could you also post the version of bash you're using?

echo "$BASH_VERSION"

[rcaloras]

Believe this is impacting bash versions > 4.2.46

[davefx]

I've reproduced this problem with bash 4.3.42(1) and 4.3.30(1).

As some other tips: If I execute something after the background process, bash doesn't finish . $ (ls)& echo Hello

[rcaloras]

Was able to boil this down to a simple code block to recreate. Still not sure the best way to handle this

# Causes login shells to logout
# Look like bash versions > 4.2.46
set -o functrace > /dev/null 2>&1
no_op() { :;}
trap 'no_op' DEBUG;
# Any command in a subshell and background
( pwd ) & 

[rcaloras]

@davefx was this occurring on a box you were ssh'd into? I can't recreate this locally regardless of the version. I can only recreate when ssh'd onto a box.

[davefx]

No. This happens also locally in X terminals in my Ubuntu 16.04 system with bash 4.3.46(1)-release.

[rcaloras]

Looks like this got mentioned to some folks on the GNU mailing list. Looking into this as a bug in bash. http://lists.gnu.org/archive/html/bug-bash/2016-09/msg00006.html

[adggit]

When the DEBUG trap is set with functrace on, it causes other problems too. E.g., certain command groups piped to a pager program will get stopped (via SIGTTOU/SIGTTIN when the pager accesses the tty):

set -o functrace
trap ':' DEBUG

# The following gets stopped:
{ date; who | sort; } | more

[1]+  Stopped                 { date; who | sort; } | more

# But this works fine:
{ who | sort; date; } | more

In general (with functrace on and the DEBUG trap set) a group of command pipelines in the form below will get stopped:

    $ { cmd_a; cmd_b | cmd_c; cmd_d; } | pager_prog

    [1]+  Stopped                  { cmd_a; cmd_b | cmd_c; cmd_d; } | pager_prog

This happens if the first command of the group (cmd_a) is not a bash builtin AND a pipeline occurs later in the group (cmd_b | cmd_c).

(Puzzlingly, the issue does not arise if in the command group either the first command (cmd_a) is a bash builtin or if none of the later commands contains a pipe.)

[adggit]

Just for reference, I originally reported this as bash bug [1] without realizing that I actually had functrace/DEBUG on, but when the bash maintainers could not reproduce it, I traced it to my preexec setup and eventually on to functrace/DEBUG [2].

[1] http://lists.gnu.org/archive/html/bug-bash/2016-09/msg00127.html [2] http://lists.gnu.org/archive/html/bug-bash/2016-10/msg00000.html

[rcaloras]

@adggit thanks for posting for reference! This issue is a real pain.

The good news is, preexec can now be implemented with $PS0 in bash 4.4. I'd love to add version detection to bash-preexec and install hooks to $PS0 if you're using the latest versions of Bash. Mentioned originally in https://github.com/rcaloras/bash-preexec/issues/28 Would love a PR from someone on this.