Problems with good scripts failing (exit code: 127)

@powellbc I haven't heard of npm before, so I looked it up (https://docs.npmjs.com/getting-started/what-is-npm)
It looks like a custom binary or something to work with javascript. So the question that comes to mind for me is, does it exist on the Mac the script is trying to run on? When we see 'command not found' in script error output, it usually means exactly what its saying. The shell can't locate the command you're calling. I think in this case including the full path to npm may resolve the issue. Remember, using shortened forms of calling binaries, like cp, jamf, awk, etc usually work OK, but in some cases you need to use full paths - /bin/cp, /usr/local/bin/jamf, /usr/bin/awk, etc.
If you can pull it up on the Mac in question with which npm, then use the full path that the command returns in your script and see if that helps fix it.

@mm2270 As soon as I saw this email come in I was looking at where it was running from. I ended up trying the wrong path but the "which" command got the correct one. The script is now working correctly. Thanks!

Are people still seeing this issue? I am on some of mine with the simple script we use to pull the logged in username.

#!/bin/sh

/usr/local/bin/jamf recon -endUsername $3

Works fine on most - running as an actual script. On maybe 8% though, we get:

/usr/local/bin/jamf: No such file or directory
Error running script: return code was 127.

When I get that, it's universally on devices that are super-old... e.g., running 10.6.8 or before. On those devices, the jamf binary still lives at /usr/sbin/jamf.

You could create a symlink to the old binary in the new location on those old devices. While this is not the best idea in the world, these versions of the OS are unsupported by Apple and according to our policy unsupported by us (at least that's what we tell ourselves).

sudo ln -s /usr/sbin/jamf /usr/local/bin/jamf

But the Error 127... I never did figure out what the root of that was. It wasn't the script. It wasn't the device. It just seemed to be a busted script/package on the DP. TestA would fail. TestB would succeed. TestA and TestB were exactly the same.

Thanks @yellow. I don't care about those old Macs either and we have the same "don't support" thing here LOL.
I'm pretty sure that the failures were not on those old Macs only though, and like you, the fail/success seemed to make no sense...

You could run this to see where scripts are running. It will output into the system.log file

#!/bin/bash

logger -t "com.jamf.test" $0

exit 0

It's happening again on a script that had previously worked. Grr...