Skip to content

Bug report: npm install fails at exec:fixCryptoApiImports on MacOS when sed is GNU sed #2010

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bartvanandel opened this issue Apr 3, 2025 · 6 comments · May be fixed by #2019
Open

Bug report: npm install fails at exec:fixCryptoApiImports on MacOS when sed is GNU sed #2010

bartvanandel opened this issue Apr 3, 2025 · 6 comments · May be fixed by #2019
Labels

Comments

@bartvanandel
Copy link
Contributor

bartvanandel commented Apr 3, 2025

Describe the bug
Can't run npm i to completion with current master on MacOS. Post-install job "exec:fixCryptoApiImports" fails with a sed error:

sed: can't read : No such file or directory

To Reproduce

I'm on MacOS 15.3.2, on a 2019 Intel MacBook Pro.

edit: and I have setup sed to point to GNU sed.

Installed node and npm using nvm, the problem occurs both with the latest LTS and with node@18 and npm@8 as per the (possibly outdated) install instructions.

Then simply ran npm i.

Output:

$ npm i
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@astronautlabs/[email protected]',
npm WARN EBADENGINE   required: { node: '^14' },
npm WARN EBADENGINE   current: { node: 'v18.20.8', npm: '8.19.4' }
npm WARN EBADENGINE }
npm WARN deprecated [email protected]: This package is no longer supported.
npm WARN deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm WARN deprecated [email protected]: Rimraf versions prior to v4 are no longer supported
npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: Use @natlibfi/loglevel-message-prefix instead
npm WARN deprecated [email protected]: Use @natlibfi/es6-polyfills instead
npm WARN deprecated @babel/[email protected]: 🚨 This package has been deprecated in favor of separate inclusion of a polyfill and regenerator-runtime (when needed). See the @babel/polyfill docs (https://babeljs.io/docs/en/babel-polyfill) for more information.
npm WARN deprecated [email protected]: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm WARN deprecated [email protected]: You can find the new Popper v2 at @popperjs/core, this package is dedicated to the legacy v1
npm WARN deprecated [email protected]: core-js@<3.23.3 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Some versions have web compatibility issues. Please, upgrade your dependencies to the actual version of core-js.
npm WARN deprecated [email protected]: core-js@<3.23.3 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Some versions have web compatibility issues. Please, upgrade your dependencies to the actual version of core-js.

> [email protected] postinstall
> npx grunt exec:fixCryptoApiImports && npx grunt exec:fixSnackbarMarkup && npx grunt exec:fixJimpModule

Running "exec:fixCryptoApiImports" (exec) task
>> sed: can't read : No such file or directory
>> Exited with code: 1.
>> Error executing child process: Error: Process exited with code 1.
Warning: Task "exec:fixCryptoApiImports" failed. Use --force to continue.

Aborted due to warnings.
npm ERR! code 3
npm ERR! path /Users/bart/src/ext/CyberChef
npm ERR! command failed
npm ERR! command sh -c -- npx grunt exec:fixCryptoApiImports && npx grunt exec:fixSnackbarMarkup && npx grunt exec:fixJimpModule

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/bart/.npm/_logs/2025-04-03T10_55_46_184Z-debug-0.log

Expected behaviour

No errors during npm i.

Desktop:

  • OS: MacOS 15.3.2
  • Browser: N/A
  • CyberChef version: 10.19.4 (current master)

Additional context

This seems to be related with the special case for "darwin" in the affected job. If I remove the '' argument to the -i command line parameter to sed, the job completes. Presumably, at some point, MacOS started shipping a more compatible version of sed.

This must be done for the fixSnackbarMarkup and fixJimpModule jobs as well. So basically, the whole special casing can be removed for recent MacOS versions, it seems.

@a3957273
Copy link
Member

a3957273 commented Apr 5, 2025

I'm afraid we don't have a device to test this on. Would you be willing to submit a PR that works for you? :)

@bartvanandel
Copy link
Contributor Author

I'll look into it.

I can test with current MacOS Sequoia 15.4 on a 2018 Mac Mini (Intel Core i5) and on a 2019 MacBook Pro (Intel Core i7), as well as MacOS High Sierra 10.13.6 on a 2012 Mac Mini (also Intel), which went EOL in November 2020, but originates from 2017. That should be back in time far enough.

@bartvanandel
Copy link
Contributor Author

May be fixed by using the non-abbreviated --in-place instead of -i, which requires an argument on BSD and (older versions of) MacOS.

Alternatively, just providing a non-empty option to create a backup file will work for sure, it just leaves some trails behind. If you guys don't mind that, this may be the safest option.

@bartvanandel
Copy link
Contributor Author

May be fixed by using the non-abbreviated --in-place instead of -i, which requires an argument on BSD and (older versions of) MacOS.

Nope, BSD sed doesn't know --in-place, just -i with an argument.

Alternatively, just providing a non-empty option to create a backup file will work for sure, it just leaves some trails behind. If you guys don't mind that, this may be the safest option.

I've gone for a solution that actually checks what sed says itself. FreeBSD and MacOS (which is a BSD derivative) versions of sed will complain about the missing argument, so why not just use that. Tested this on both MacOS (bypassing the alias that I have to actually use GNU sed...) and FreeBSD. They give the same output. For completeness: OpenBSD doesn't require an argument.

bartvanandel added a commit to bartvanandel/CyberChef that referenced this issue Apr 8, 2025
bartvanandel added a commit to bartvanandel/CyberChef that referenced this issue Apr 8, 2025
@bartvanandel bartvanandel changed the title Bug report: npm install fails at exec:fixCryptoApiImports on MacOS Bug report: npm install fails at exec:fixCryptoApiImports on MacOS when sed is GNU sed Apr 10, 2025
@bartvanandel
Copy link
Contributor Author

Adjusted the title and description to better reflect my actual situation. I totally forgot about having setup that alias. My proposed solution doesn't care what your system is, it just checks sed itself.

An arguably better solution would be to just to the text replacement using node-based function, which is quite straightforward with the built-in node:fs package, and would make the install process less platform-bound. This would require more refactoring though, so I haven't pursued that path for now.

@ParkerM
Copy link
Contributor

ParkerM commented May 15, 2025

An arguably better solution would be to just to the text replacement using node-based function, which is quite straightforward with the built-in node:fs package, and would make the install process less platform-bound. This would require more refactoring though, so I haven't pursued that path for now.

I had the same idea when I submitted #1505 but ran out of gas before coming up with an elegant solution (which I imagined as swapping out calls to find and sed with their own bespoke node-based function). I think an approach that avoids platform-dependent shell commands is the only way to address this recurring issue for good. (see also: #1166, #1227, #1306, #1475, #1544)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants