Ensure that errors from interop are of type interp.ExitStatus.

[trulede]

When commands from coreutils fail, the error type is not the expected interop.ExitStatus. The handling of those errors, especially in relation to ignore-error, depends on that error type.

Solution presented here first prints the error (otherwise you have no feedback as to why the command fails), and then replaces the err object with a new interop.ExitStatus error. Location is also chosen because logging is available (for the original error).

Output formatting of the error is similar (in format) to the errors from defaul interop.

# Windows
.\task.exe -t .\ISSUES\2466 -v
task: "default" started
task: [default] cp -f foo fuvar/bar
CreateFile \\wsl.localhost\Ubuntu\home\trule\git\task\ISSUES\2466\foo: The system cannot find the file specified.
task: [default] command error ignored: exit status 1
task: "default" finished

# Linux
$ task -t ./ISSUES/2466/ -v
task: "default" started
task: [default] cp -f foo fuvar/bar
cp: cannot stat 'foo': No such file or directory
task: [default] command error ignored: exit status 1
task: "default" finished

Fixes #2466

[andreynering]

Hey @trulede,

I think that having an specific error type in the middleware will work very well and be more reliable. What do you think?

• mvdan/sh#1241

[trulede]

@andreynering the problem I encountered was finding a way to print the cause of the error (its in the err object) so that the user has some indication of the failure.

A specific error type in the middleware would also facilitate that. However that solution is a bit more complex, IIRC you need changes in a few places/interfaces, and task also needs to handle that error object. Its probably the more correct approach. Its possibly a change over 3 repos - its quite a complex integration.