-
Notifications
You must be signed in to change notification settings - Fork 861
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
Cannot call Atom Package Manager apm
from Bash
#2467
Comments
@therealkenc Yes there does appear to be some similarity. Unclear to me if it is the same issue. To me the lightbulb for mine was lines like this in the stack trace:
The stack trace is full of random linux pathnames, but not a windows path to be found anywhere. But then I have no idea what this strace is saying, so I could be completely off base. All I actually know for sure is that if you try to run apm from bash it crashes every time. Atom itself boots up fine and gets handed the properly filepaths. |
@skylize - Those There is a "windows path to be found", at the very first line: the Win32 Atom boots up fine though interop; but then Atom proper isn't trying to read or write to/from It's beyond my pay-grade to say for certain whether it is the same as #2370 or not. Ben will probably chime in when he's around (it's already the long weekend). |
apm
from Bash
@therealkenc Thanks for the insight. I changed the issue's title so it no longer includes my incorrect assessment of the problem. |
@therealkenc Sounds fine. Thanks |
Windows build number
Microsoft Windows [Version 10.0.16251.1002]
Problem
Fails to run
apm
(Atom Package Manager) from WSL.Setup
Install Atom Editor on Windows system verify that user or system PATH includes
C:\Users\{username}\AppData\Local\atom\bin
.What's happening?
In WSL Bash Prompt type
apm
What should be happening instead?
Output in Bash should match this output from calling
apm
in a cmd terminalLayman's interpretation of results
Edit: I was wrong, you really don't need to read this section.
It looks like to me like bash is clobbering Windows environment variables with it's own, causingapm
to look in non-existent locations for dependencies.I think as default behavior WSL should not pass any environment variable to a Windows binary if that variable already exist in the Windows environment.As implied by the name, the standard purpose of anenvironment variable
is to describe the environment in which the binary will run. Even if invoked from bash, a windows binary will never run inside that bash environment, it will run in the Windows environment. Except in special use cases, the environment variables described in bash will be totally meaningless, while Windows variables will often be vital to even the most basic behavior like starting the application.Overwriting the existing environment variables in Windows with variables that describe a completely different environment** (without the User specifically requesting it) **is simply not acceptable.I certainly agree that clobbering as an option would be nice to have. But clobbering by default is prone to cause way more errors than it helps.strace
strace.1094
strace.1095
Other straces
strace -o strace.txt -ff apm
created 16 total trace files. Let me know if for some reason you need more of the traces to help. Trace 1095 has already exited with code0
. So I think posting the rest would be frivolous.See our contributing instructions for assistance.
The text was updated successfully, but these errors were encountered: