sfdx: No such file or directory

[mshanemc]

What's the error?

sfdx: No such file or directory
“/Users/you/.local/share/sfdx/client/bin/sfdx: line 16: /Users/you/.local/share/sfdx/client/bin/../7.209.6-aaaaaaa/bin/sfdx: No such file or directory

Why's it doing that?

oclif's update code cleans up old versions of the CLI after 6 weeks. sfdx hasn't been published...in about 6 weeks. So sfdx is trying to delete itself.

We've never not published a CLI for 6 weeks, so we didn't know the code was wrong.

OK, what can I do as a workaround?

Well, the good news: there are a lot of workaround options!

1. Above all, we recommend not using sfdx anymore. Use sf sf (v2) is Generally Available #2132
2. sfdx plugins:install @oclif/[email protected] will replace the plugin that has the bug. You can run this before the CLI deletes itself to prevent the problem. If the problem already happened, you need on one of the other options.
3. Installs from npm don't update that way, so those should be immune to the problem
4. Reinstalling the CLI will solve the problem (well, for just over 6 weeks before you have to do it again 😄 if you don't do option 2)
5. The deletion logic is using the mtime (the last modified date) of the directory. So you could do something like touch .local/share/sf/client/7.209.6-[whatever that SHA was]. Someone who knows windows can hopefully post the equivalent.
6. If you plan to stay on sfdx, since we don't plan any updates for sfdx, you could try turning off the auto-update code by setting SF_DISABLE_AUTOUPDATE=true in your env to keep the bad code from ever running.

[AndrewRayCode]

Is this on your radar @cromwellryan? This is the second bug I'm aware of where sfdx deletes itself. Once is really surprising, twice is worrying! Will there be changes in sf to prevent this happening a third time?

[rchoubey1]

I am facing similar issue without doing any manual update
'"C:\Users\myuser\AppData\Local\sfdx\client\bin..\7.209.6-8ba3197\bin\sfdx.cmd"' is not recognized
as an internal or external command,
operable program or batch file.

this is happening with both sfdx and sf command

[mshanemc]

@rchoubey1 yes, the issue will continue to happen unless you take some action. The CLI autoupdates itself (workaround 6 turns this off).

[gsbasso]

This feature impacted a number of our devs before we realized what was happening. I would argue another v7 update should be published that includes the fix.

Re: workaround 6, should the value be true rather than false (i.e. we want to turn on the disabling)? Or is the name of the environment variable misleading? Also, when SFDX_DISABLE_AUTOUPDATE is defined you get a warning that the variable has been replaced by SF_DISABLE_AUTOUPDATE. Should we also set the latter?

Finally, just wanted to ask if CLI plugins can be sourced from a salesforce.com domain? It's one thing to justify opening the firewall for an approved vendor domain but quite another for an open source domain. To update our Jenkins server to v2 I had to copy the content of plugin-packaging from my dev machine and then run sf plugins link (a variation on the solution from this post).

[mshanemc]

Re: workaround 6, should the value be true rather than false

yes, good catch, fixed, thanks!

[mshanemc]

Finally, just wanted to ask if CLI plugins can be sourced from a salesforce.com domain? It's one thing to justify opening the firewall for an approved vendor domain but quite another for an open source domain.

What's the domain that's causing problems? npm/yarn?

[AndrewRayCode]

See also #718

[Desjardins-CRM]

So, now that the damage is done, is there a CLI removal tool to get rid of all the remnants left behind? I will go ahead and install SF, but want to clean up what's left behind before doing so.
Thanks!

[SCWells72]

is there a CLI removal tool to get rid of all the remnants left behind?

I can help with this one as I provide this link pretty frequently to my own product's users:

https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_uninstall.htm

Make sure that you remove the additional directories documented there for the respective platforms to ensure you have a full uninstall. You do not need to remove the contents of ~/.sf or ~/.sfdx or the directories with the corresponding names under the individual project directories, though, nor should you as that would remove auth'ed orgs, source tracking state, etc., that will be used by the newly-installed v2 CLI.

[Desjardins-CRM]

Thank you Scott!

[gsbasso]

This feature impacted a number of our devs before we realized what was happening. I would argue another v7 update should be published that includes the fix.

Re: workaround 6, should the value be true rather than false (i.e. we want to turn on the disabling)? Or is the name of the environment variable misleading? Also, when SFDX_DISABLE_AUTOUPDATE is defined you get a warning that the variable has been replaced by SF_DISABLE_AUTOUPDATE. Should we also set the latter?

Finally, just wanted to ask if CLI plugins can be sourced from a salesforce.com domain? It's one thing to justify opening the firewall for an approved vendor domain but quite another for an open source domain. To update our Jenkins server to v2 I had to copy the content of plugin-packaging from my dev machine and then run sf plugins link (a variation on the solution from this post).

Finally, just wanted to ask if CLI plugins can be sourced from a salesforce.com domain? It's one thing to justify opening the firewall for an approved vendor domain but quite another for an open source domain.

What's the domain that's causing problems? npm/yarn?

npm, so I guess https://registry.npmjs.org?

In fact, even from my work computer I have to switch to the non-secure URL (i.e. http vs. https). Otherwise we get a certificate error.

[mshanemc]

CLI plugins are npm packages (always have been), both Salesforce's packages and 3rd-party packages. That is unlikely to change.

Typically, when companies want more control of npm packages than "all of npm" they use something like Artifactory (think private npm registry) that proxies some subset of preferred/approved packages.

[gsbasso]

This feature impacted a number of our devs before we realized what was happening. I would argue another v7 update should be published that includes the fix.

Re: workaround 6, should the value be true rather than false (i.e. we want to turn on the disabling)? Or is the name of the environment variable misleading? Also, when SFDX_DISABLE_AUTOUPDATE is defined you get a warning that the variable has been replaced by SF_DISABLE_AUTOUPDATE. Should we also set the latter?

Finally, just wanted to ask if CLI plugins can be sourced from a salesforce.com domain? It's one thing to justify opening the firewall for an approved vendor domain but quite another for an open source domain. To update our Jenkins server to v2 I had to copy the content of plugin-packaging from my dev machine and then run sf plugins link (a variation on the solution from this post).

Finally, just wanted to ask if CLI plugins can be sourced from a salesforce.com domain? It's one thing to justify opening the firewall for an approved vendor domain but quite another for an open source domain.

What's the domain that's causing problems? npm/yarn?

npm, so I guess https://registry.npmjs.org?

In fact, even from my work computer I have to switch to the non-secure URL (i.e. http vs. https). Otherwise we get a certificate error.

CLI plugins are npm packages (always have been), both Salesforce's packages and 3rd-party packages. That is unlikely to change.

Typically, when companies want more control of npm packages than "all of npm" they use something like Artifactory (think private npm registry) that proxies some subset of preferred/approved packages.

Well if you had originally installed using the Windows installer updates worked fine. But in recent years the ability to install has been removed so we had to switch to using npm (npm is an approved tool that can be installed automatically).

However, as previously noted, we can only install/update with npm through the non-secure URL. There must be something different between running sfdx update vs. updating with npm.

[azanatta]

Got the issue with sf today. It worked until before lunchtime, when I got back any sf command fails:
PS C:\Entwicklung\CTI2> sf --version '"C:\Users\yo\AppData\Local\sfdx\client\bin\..\7.209.6-8ba3197\bin\sf.cmd"' is not recognized as an internal or external command, operable program or batch file.

I'm not using sfdx.
I guess sf got updated automatically and it tries to redirect to the sf.cmd in the folder 7.209.6-8ba3197\bin, which only contains a node.exe file, nothing else.

I'm now deleting any trace of sf-related software and I will re-install it from scratch, setting the env SFDX_DISABLE_AUTOUPDATE=true.

[mshanemc]

@azanatta whoa. Thanks for letting us know.

[cristiand391]

@azanatta SFDX_DISABLE_AUTOUPDATE only works in sfdx, for sf use SF_DISABLE_AUTOUPDATE

[mshanemc]

@azanatta that's v1 of sf that was bundled in the last version of sfdx, so it also has the same bug. Here's the migration instructions (uninstall sfdx and sf v1, install sf v2).

#2132
https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm

[gkibilov]

Using plugins in VSC, this happened to me too:
sfdx force:auth:web:login --setalias dev --instanceurl https://xyz.my.salesforce.com/ --setdefaultusername

/Users/gkibilov/.local/share/sfdx/client/bin/sfdx: line 16: /Users/gkibilov/.local/share/sfdx/client/bin/../7.209.6-8ba3197/bin/sfdx: No such file or directory

Question:
After switching to salesforce/cli 2.7.11
Do I now need to set SF_DISABLE_AUTOUPDATE = true instead of SFDX_DISABLE_AUTOUPDATE to keep this from happening again?

Details:
I think I had old version of CLI to prevent this error:
Java.lang.UnsupportedClassVersionError: apex/jorje/lsp/ApexLanguageServerLauncher has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
So after uninstalling and re installing latest plugins and pointing Salesforcedx-vscode-apex › Java: Home to JDK11

gkibilov@Georges-MacBook-Pro xyz-dev % sf plugins --core
(node:23385) Warning: Deprecated environment variable: SFDX_DISABLE_AUTOUPDATE. Please use SF_DISABLE_AUTOUPDATE instead.
...
@salesforce/cli 2.7.11 (core)
apex 2.3.12 (core)
...

[gkibilov]

@azanatta whoa. Thanks for letting us know.

@mshanemc
But
Warning: Deprecated environment variable: SFDX_DISABLE_AUTOUPDATE. Please use SF_DISABLE_AUTOUPDATE instead.

[gkibilov]

@azanatta SFDX_DISABLE_AUTOUPDATE only works in sfdx, for sf use SF_DISABLE_AUTOUPDATE
@cristiand391
So even with sf V2 we want to set SF_DISABLE_AUTOUPDATE to prevent the issue from happening going forward?

[mshanemc]

@azanatta SFDX_DISABLE_AUTOUPDATE only works in sfdx, for sf use SF_DISABLE_AUTOUPDATE
@cristiand391
So even with sf V2 we want to set SF_DISABLE_AUTOUPDATE to prevent the issue from happening going forward?

No, it only affects sfdx and sf v1 (if you got sf v1 bundled with sfdx)

[shivamnaik98]

Thanks @mshanemc ! I did manage to install 7.158.1 (my employer provides it by default) but the issue remains. I have made no upgrades to JDK either but the VSC extensions did update a week back. I will seek out help on the given site

[pgonzaleznetwork]

@mshanemc what does the vscode extension use? if it uses sfdx and sfdx uninstalls itself, how can we use the vscode extensions for salesforce?

[pgonzaleznetwork]

Just noticed that sfdx is aliased to sf so maybe that answers my question...

[mshanemc]

@mshanemc what does the vscode extension use? if it uses sfdx and sfdx uninstalls itself, how can we use the vscode extensions for salesforce?

Just noticed that sfdx is aliased to sf so maybe that answers my question...

VSCode makes calls to "sfdx" and that works with either CLI.

[ssk42]

What if we don't have sudo access? Is there another way to migrate?

[mshanemc]

What if we don't have sudo access? Is there another way to migrate?

@ssk42 sudo is not required. And discouraged for npm installs.
https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm

[ssk42]

@mshanemc - Meant sudo for the uninstall! Sorry, should have clarified as seen in https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_uninstall.htm because npm uninstall seemingly didn't do anything

[mshanemc]

you can try it without sudo. If your install was done correctly you should be the owner of those folders/files. Hopefully?

[ssk42]

Nope, no dice. Permission denied on a bunch (most?) of the files

[ssk42]

Resolved by just going to /usr/local/bin/ and trashing sfdx and sf. Thanks!

[EarlyBitcoiner]

I had the same problem, just deleted the sfdx folder which was in the error message and everything works as normal.

[bdwankhede1124]

This will resolve this issue on my macOS

rm -rf ~/.local/share/sfdx ~/.config/sfdx ~/.cache/sfdx
rm -rf ~/.local/share/sf ~/.config/sf ~/.cache/sf

[victorabraham]

For me this issue continues even after using the latest sf cli and disabling updates for sfdx. Anyone else noticing the same behavior?

[ragoergens]

@mshanemc My time had come this afternoon.
After reinstalling the CLI, I tried workaround 2: sfdx plugins:install @oclif/plugin-update@latest

This is what happens:
This plugin is not digitally signed and its authenticity cannot be verified. Continue installation y/n?: y
Finished digital signature check.
error @oclif/[email protected]: The engine "node" is incompatible with this module. Expected version ">=18.0.0". Got "16.17.1"
error Found incompatible module.
Installing plugin @oclif/plugin-update... failed
Error: yarn add @oclif/plugin-update@latest --non-interactive
--mutex=file:C:\Users\user\AppData\Local\sfdx\yarn.lock
--preferred-cache-folder=C:\Users\user\AppData\Local\sfdx\yarn --check-files exited with code 1

What would you recommend? Thx

[mshanemc]

@ragoergens I'd recommend option 1 🤪...almost half of daily executions are on sf. What's holding you back?
but for workaround 2, uh try sfdx plugins:install @oclif/[email protected]

That's the last one before all the node support stuff started changing, and the in-progress ESM updates. https://www.npmjs.com/package/@oclif/plugin-update?activeTab=versions

[shetzel]

If you're installing sf v2 from sfdx I would follow the documented steps here: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm

Also, to ensure a complete uninstall before installing sf v2 follow these steps: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_uninstall.htm

[ragoergens]

For some reason I was on sf v2 but had never removed C:\Program Files\sfdx, which was first in my PATH 🙈
So thank you @shetzel for the links

@mshanemc sfdx plugins:install @oclif/[email protected] worked with sfdx-cli/7.172.0
But once I got rid of that, sfdx plugins:install @oclif/plugin-update@latest worked fine:
Installing plugin @oclif/plugin-update@latest... installed v4.1.3

@SCWells72 for Illuminated Cloud, it's just a matter of configuring the proper executable 😁

[Mahakb]

Facing the same issue. Do we have any workaround for it? When can we expect this to be resolved??

[SCWells72]

@Mahakb, the solution is to do a 100% clean uninstall of what you hav installed now and install the latest v2 CLI build. See links above for both.

[Mahakb]

@Mahakb, the solution is to do a 100% clean uninstall of what you hav installed now and install the latest v2 CLI build. See links above for both.

Thanks this worked.

[mshanemc]

I'm going to close/unpin this issue. Seems to have quieted down now that most of you are on sf.