Well, I'm confused about maxBuffer now. Even when it triggers shell.error() on pre-v10, exec() still seems to work despite exceeding the buffer...

> s.exec('echo 0123456789', { maxBuffer: 6 }) // How can this have correct output??
0123456789
{ [String: '0123456789\n']
  stdout: '0123456789\n',
  stderr: '',
  code: 0,
  cat: [Function: bound ],
  exec: [Function: bound ],
  grep: [Function: bound ],
  head: [Function: bound ],
  sed: [Function: bound ],
  sort: [Function: bound ],
  tail: [Function: bound ],
  to: [Function: bound ],
  toEnd: [Function: bound ],
  uniq: [Function: bound ] }

Maybe maxBuffer behavior changed during the exec() refactors around v0.8, and we got lucky by not breaking the test? I'll take a look.

Woops, got a bit eager with the approve button.

I did some investigating, and it turns out that in v10, using child_process.exec and piping the child process' stdout to the parent process' stdout will always work, regardless of the value of maxBuffer. maxBuffer only applies to the data saved in the buffer.

If maxBuffer is exceeded, the callback to child_process.exec will be called with this error: RangeError [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]: stdout maxBuffer length exceeded. But the data will still go to stdout.

If maxBuffer is exceeded, the callback to child_process.exec will be called with this error: RangeError [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]: stdout maxBuffer length exceeded. But the data will still go to stdout.

Ack. It sounds like we need to rewrite the test, and to also modify exec() to expect that error and surface that information to the user.

Blocked by #915

Close in favor of #921