You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
JSCPD v.3.4.5 crashes when the main CLI argument is a symlink: jscpd link1.py
john@my-mac:/tmp/testProject$ jscpd link1.py
Error: ENOTDIR: not a directory, scandir '/private/tmp/testProject/link1.py'
at Object.readdirSync (fs.js:854:3)
at readdir (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.scandir/out/providers/sync.js:39:31)
at Object.read (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.scandir/out/providers/sync.js:12:12)
at SyncReader.scandirSync [as _scandir] (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.scandir/out/index.js:18:17)
at SyncReader._handleDirectory (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.walk/out/readers/sync.js:28:34)
at SyncReader._handleQueue (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.walk/out/readers/sync.js:23:18)
at SyncReader.read (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.walk/out/readers/sync.js:15:14)
at SyncProvider.read (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.walk/out/providers/sync.js:11:29)
at ReaderSync.walkSync [as _walkSync] (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/@nodelib/fs.walk/out/index.js:20:21)
at ReaderSync.dynamic (/Users/john/.xxxxx-tools/node-v12.13.0/lib/node_modules/jscpd/node_modules/fast-glob/out/readers/sync.js:13:21) {
errno: -20,
syscall: 'scandir',
code: 'ENOTDIR',
path: '/private/tmp/testProject/link1.py'
}
We discovered this error when using JSCPD through the SuperLinter https://github.com/github/super-linter and linting our codebase with Github Actions. In particular, the SuperLinter calls jscpdfor each file eligible to linting individually. (SuperLinter code, line 291), and when such file is a symlink, it explodes.
To Reproduce
Steps to reproduce the behavior: mkdir /tmp/testProject cd /tmp/testProject printf 'Hello\n%.0s' {1..50} > file1.py ln -s file1.py link1.py jscpd link1.py
Adding --noSymlinks doesn't help.
However it works you run jscpd /tmp/testProject/. And --noSymlinks behaves as expected.
Expected behavior
Shouldn't crash. If --noSymlinks is given, should do nothing, otherwise should follow the symlink and check the target.
Desktop
OS: MacOS
OS Version: 12.4
NodeJS Version: 12.13.0
jscpd version: 3.4.5
This also happens in the SuperLinter Docker image which is Linux based (Alpine, I think).
The text was updated successfully, but these errors were encountered:
Describe the bug
JSCPD v.3.4.5 crashes when the main CLI argument is a symlink:
jscpd link1.py
We discovered this error when using JSCPD through the SuperLinter https://github.com/github/super-linter and linting our codebase with Github Actions. In particular, the SuperLinter calls
jscpd
for each file eligible to linting individually. (SuperLinter code, line 291), and when such file is a symlink, it explodes.To Reproduce
Steps to reproduce the behavior:
mkdir /tmp/testProject
cd /tmp/testProject
printf 'Hello\n%.0s' {1..50} > file1.py
ln -s file1.py link1.py
jscpd link1.py
Adding
--noSymlinks
doesn't help.However it works you run
jscpd /tmp/testProject/
. And--noSymlinks
behaves as expected.Expected behavior
Shouldn't crash. If
--noSymlinks
is given, should do nothing, otherwise should follow the symlink and check the target.Desktop
This also happens in the SuperLinter Docker image which is Linux based (Alpine, I think).
The text was updated successfully, but these errors were encountered: