`.errno` field of errors from `child_process.execSync` is in string form instead of numeric.

[daurnimator]

• Version: v7.9.0
• Platform: Linux daurn-m73 4.10.11-1-ARCH #1 SMP PREEMPT Tue Apr 18 08:39:42 CEST 2017 x86_64 GNU/Linux
• Subsystem: child_process

The .errno field of errors from child_process.execSync is in string form instead of numeric.

$ node -e 'try{require("child_process").execSync("foo", {shell: "doesnt_exit"})}catch(e){console.log(e.errno)}'
ENOENT

In this example I expect the numeric value -2 (as it is (correctly) is for other operations such as open:
try{require("fs").openSync("doesnt_exist", "r")}catch(e){console.log(e.errno)}).

[daurnimator]

Possibly related to #6665

[vsemozhetbyt]

cc @bnoordhuis, @cjihrig

[cjihrig]

This comes from the use of util._errnoException(). Maybe that function shouldn't attach the same value for both code and errno, but it looks like it has been that way for 4 years now.

[jasnell]

FWIW, this will be changing in an upcoming semver-major as part of the conversion over to internal/errors

[daurnimator]

FWIW, this will be changing in an upcoming semver-major as part of the conversion over to internal/errors

great. is there milestone or related issue/PR for that?

[joyeecheung]

@daurnimator Tracking issue for the ongoing internal/errors work is in #11273

(The issue in the OP is still present in v8.0.0..)

[daurnimator]

#11273 is now closed, but the issue remains. (tested with 9.5.0)

[bnoordhuis]

Changing the type is a semver-major change so node 10 would be soonest you'd see that change, and assuming it doesn't cause breakage in the ecosystem.

[joyeecheung]

I left a few TODOs in internal/errors.js

node/lib/internal/errors.js

Line 432 in 80ac941

// TODO(joyeecheung): errno is supposed to err, like in uvException

node/lib/internal/errors.js

Line 467 in 80ac941

// TODO(joyeecheung): errno is supposed to err, like in uvException

node/lib/internal/errors.js

Line 503 in 80ac941

// TODO(joyeecheung): errno is supposed to be err, like in uvException

I would not oppose to try to have them fixed before v10 and see if there are any serious breakage...@jasnell what do you think?

[daurnimator]

Could this be added to the v10 milestone? https://github.com/nodejs/node/milestone/26

[daurnimator]

Issue remains in v11.11.0

[gireeshpunathil]

@daurnimator - this is fixed through #28140 and is available is v13.0.0. Can you pls check at your end and revert?

#node -e 'try{require("fs").openSync("doesnt_exist", "r")}catch(e){console.log(e.errno)}'
-2
#node -v
v13.0.1
#