gchq
Bug report: `npm install` fails at `exec:fixCryptoApiImports` on MacOS when `sed` is GNU `sed`
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.
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? :)
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.
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.
May be fixed by using the non-abbreviated
--in-placeinstead 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.
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.
An arguably better solution would be to just to the text replacement using
node-based function, which is quite straightforward with the built-innode:fspackage, 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)
