iTerm2 Shell Integrations affect STDOUT of piped sub-shells

OS X Version:   10.10.3
iTerm2 Version: Build 2.9.20150505-nightly

The shell integration for BASH seem to have a weird effect on sub-shells. Some control characters get printed even if the output is not a TTY, e.g. piped to another command. This obviously can cause very strange effects on the receiving commands...

Full repro steps.

# begin with no iterm2_shell_integration loaded...
# e.g. via: bash --norc
bash-3.2$ true | wc -c
       0
bash-3.2$ (true) | wc -c
       0
# all good so far...
# now load the shell integration
bash-3.2$ source ~/.iterm2_shell_integration.bash
bash-3.2$ true | wc -c
       0
bash-3.2$ (true) | wc -c
       8
bash-3.2$ (true) | less -R
133;C^G
(END)

A possible fix for the issue would be to ensure STDOUT is a TTY in preexec_invoke_exec.

--- a/Users/leppich/.iterm2_shell_integration.bash.orig
+++ b/Users/leppich/.iterm2_shell_integration.bash
@@ -94,6 +94,13 @@ if ( [ x"$TERM" != xscreen ] ); then
   # environment to attempt to detect if the current command is being invoked
   # interactively, and invoke 'preexec' if so.
   function preexec_invoke_exec () {
+      if [ ! -t 1 ]
+      then
+          # We're in a piped subshell (STDOUT is not a TTY) like
+          #   (echo -n A; sleep 1; echo -n B) | wc -c
+          # ...which should return "2".
+          return
+      fi
       if [[ -n "$COMP_LINE" ]]
       then
           # We're in the middle of a completer.  This obviously can't be

Added PR https://github.com/gnachman/iterm2-website/pull/9

See comments on PR

Milestone changed to Ship 3.0

Status changed to closed

mentioned in issue #4210 (closed)