Node version (or tell us if you're using electron or some other framework):

10.19.0

ShellJS version (the most recent version/Github branch you see the bug on):

0.8.4

Operating system:

MacOS (Catalina) 10.15.4

Description of the bug:

I tried running this command git diff branch_1 branch2 --quiet --exit-code -- directory If differences are found, it returns exit code 1 otherwise 0 You can read the error code by executing echo $?

That's not happening with shellJS. The code value is always 0 even if git diff originally returns 1

Example ShellJS command to reproduce the error:

const exitCode = shellJS.exec(`git diff ${targetBranch} ${gitCommitORTag} --quiet --exit-code -- ${directory}`).code

Please include shelljs commands, including how you're trying to read the error code.

@nfischer I have added this snippets to the main comment also.

const exitCode= shellJS.exec(`git diff ${targetBranch} ${gitCommitORTag} --quiet --exit-code -- ${directory}`).code

Works fine on my Mac OS system, same shelljs and node version. I don't see why ShellJS would mess up the exit code unless something really unexpected is going on. Are you sure your git repo is actually dirty, and not that it just has unindexed files?

var s = require('shelljs');
var ret = s.exec('git diff --exit-code --quiet');

console.log(ret.code); // outputs 0 or 1, as expected for my git repo state

So this issue happened due to my stupidity that I executed the program in a different directory. But the issue still persists, I moved to node spawn, and surprisingly, output for shelljs and node spawn is different. I'm still in dark about this one.

What's the difference in the output? Can you post code?

I'm running into this problem with cp.

Repro Steps

Prep:

> touch test.txt
> mkdir destDir
> touch destDir/test.txt

Script:

import shelljs from 'shelljs';

shelljs.config.fatal = true;
shelljs.config.verbose = true;

const result = cp('-n', 'test.txt', 'destDir/');

const { code, stdout, stderr } = result;
console.log({ code, stdout, stderr, error: shelljs.error() });

Run the script:

> npx ts-node -T -r tsconfig-paths/register ./testScript.ts

(In this simple repro example, obviously tsconfig-paths is not needed. However, I'm using it in my real code, so I'm mentioning it here on the off-chance that there's some buggy interaction with it.)

Expected

cp -n test.txt destDir/
{ code: 1, stdout: 'destDir/test.txt not overwritten', stderr: null, error: true }

(I get the expected result if I run cp -n test.txt destDir/ manually at the command-line myself.)

Actual

cp -n test.txt destDir/
{ code: 0, stdout: '', stderr: null, error: null }

Versions

• shelljs: v0.8.5
• node: v19.9.0
• npm: v9.6.3

Expected

cp -n test.txt destDir/
{ code: 1, stdout: 'destDir/test.txt not overwritten', stderr: null, error: true }

(I get the expected result if I run cp -n test.txt destDir/ manually at the command-line myself.)

As far as I know, what you wrote should not be the expected behavior for cp. On my Ubuntu Linux machine, running cp -n test.txt destDir/ in the shell will exit with status 0 (success). I tried this in bash shell and zsh shell (although the shell shouldn't really affect this). So I think ShellJS is doing the right thing because the behavior is the same as in my shell.

@cdavie-artium what OS did you try out that command on? Maybe MacOS or Windows behave differently?

@cdavie-artium what OS did you try out that command on? Maybe MacOS or Windows behave differently?

@nfischer I just re-ran my repro steps to double-check, and yep, I definitely get an exit code of 1. System info:

• MacOS Ventura 13.6 (M2)
• GNU bash 5.2.15
• iTerm2 3.4.20

All of the following variations return an exit code of 1 for me:

• /bin/cp -n test.txt destDir/
• /opt/homebrew/opt/coreutils/bin/gcp -n test.txt destDir/
• /opt/homebrew/bin/bash -c 'cp -n test.txt destDir/'
• /bin/bash -c 'cp -n test.txt destDir/'

This StackOverflow question & its answers say that cp -n does indeed behave differently depending on which flavor of cp you have.

Generally, the ShellJS project tries to follow the GNU coreutils behavior (i.e., Linux). In this specific case, it's intended behavior for cp('-n', ...) to return a status of 0.

I think macOS ships with a BSD variant of cp(). That's why it behaves differently from Linux.

I'm going to close this since I haven't heard back from @souravdasslg and we've figured out what was causing @cdavie-artium's issue.