Unable to open Atom from the command line without executing Install Shell Commands each time I open Oh My Zsh


#1

In order for the atom . shell command to work, I have to run “Install Shell Commands” each time I open my zsh shell. As long as I haven’t closed the shell, it doesn’t matter if I’ve exited Atom or not, atom . (and the variants that open folders/files) still works.

As soon as the shell’s been closed though, I have to repeat the process in order to get the command to work. Not the worst thing in the world, but not being able to open files from the command line is a bit of a pain. Thanks!

OS X 10.12.1 Sierra
Atom 1.12.5
iTerm 3.0.12
Oh My Zsh


#2

What the install shell commands menu item does is to create a symlink between where Atom has the commands and a standard location that is on your PATH. There should be no reason why this symlink would go away between invocations unless you (or Oh My Zsh) are doing something to delete it.


#3

I am having a similar situation can anyone explain this or have some idea’s?
Atom cli tools magically disappears when the Atom UI is quit.
Atom cli tools magically reappears when the Atom UI is running again.

I have no other UI with Command Line tools with this problematic behavior other than Atom?

  1. Start Atom via “Spotlight SearchCMD-SPC atom <ret>

  2. Install Atom Command Line Tools via Atom Menubar Item

  3. Open a MacOS Terminal Window (bash).
    3a. I can invoke Atom from the Command Line all day long as long as Atom is running

  4. $ which atom —> /usr/local/bin/atom

  5. $ ls -l atom —> lrwxr-xr-x 1 rbirch admin 152 Mar 21 11:48 /usr/local/bin/atom -> /private/var/folders/j2/_4czmcd503v36bd6v03n9jhc0000gn/T/AppTranslocation/F8ABC49C-89A4-4513-AB9B-118430A173CE/d/Atom.app/Contents/Resources/app/atom.sh

  6. Quit Atom -> CMD-Q

  7. $ which atom —> absolutely nothing comes back WTF?

  8. Restart atom same method as #1 via Spotlight

  9. $ which atom —> /usr/local/bin/atom

  10. ls -l /usr/local/bin/atom —> lrwxr-xr-x 1 rbirch admin 152 Mar 21 12:00 /usr/local/bin/atom -> /private/var/folders/j2/_4czmcd503v36bd6v03n9jhc0000gn/T/AppTranslocation/E05D3F5C-093C-4FF5-BA03-4EAFEB39F727/d/Atom.app/Contents/Resources/app/atom.sh
    10a. WTF? WTF? WTF!?!?!?

  11. Google/var/private/folder
    "/var/folders" (or “/private/var/folders”) is “per-user temporary files and caches”. It is created and managed by Mac OS X. It first showed up in 10.5. It’s purpose is to increase security by improving permissions (rwxr-xr-x) over previous temp and cache locations (/Library/Caches and /tmp, which are both rwxrwxrwt).

For now this is where I stop digging …

MacOS: 10.12.3
Atom: 1.15.0
MacOS Term: Version 2.7.1 (388)


#4

@robdbirch What you’re running into is macOS Sierra’s App Translocation security feature. According to that article, I would have to assume that you haven’t installed Atom to your /Applications folder. You need to do that for Atom to be trusted by your system.


#5
~ 2.2.5 >ls -ld /Applications/Atom.app/
drwxr-xr-x@ 3 rbirch  staff  102 Mar  8 11:21 /Applications/Atom.app/

~ 2.2.5 >ls -ld ~/Applications/Atom.app/
ls: /Users/rbirch/Applications/Atom.app/: No such file or directory

#6

I assume that you’re saying you’ve already done that and still get the same result?


#7

Argh!
I’ve have changed nothing it has always been that way.
This problem has been my bane for a while, at least since Sierra.
I finally got around to looking into it.


#8

The path that is linked to mentions AppTranslocation:

lrwxr-xr-x 1 rbirch admin 152 Mar 21 12:00 /usr/local/bin/atom -> /private/var/folders/j2/_4czmcd503v36bd6v03n9jhc0000gn/T/AppTranslocation/E05D3F5C-093C-4FF5-BA03-4EAFEB39F727/d/Atom.app/Contents/Resources/app/atom.sh

I would either:

  1. Remove the copy of Atom you have installed and then install it again
  2. Look further into how to get something out of being translocated

According to this blog post removing the quarantine extended attribute could resolve item 2.


#9

Why exactly do I as a customer have to resolve this complex problem with Atom CLI installs?
This appears to be a problem with installing the Atom CLI tools in certain macOS Sierra security environments.
NOT exactly a problem a customer should need to resolve for only the Atom CLI application that is giving the customer this problem!
Though, if I had some expertise in this area I would be happy to help you.
Don’t try push this problem off on me like you did to the customer in this original post.
I believe I gave you enough information to resolve this issue.
If there something else you need that I can help you resolve this issue from a customer perspective then please let me know.
I’ve seen this problem or similar problems mentioned on several threads and on the GitHub issues.
Otherwise for me, it’s back to Emacs and Long Live EMACS!!!


#10

This is the first time I’ve seen anyone refer to a user of a costless, free, and open-source application as a “customer”, and even when a purchase has been made, an issue that’s very specific to the user’s computer (that is, most other users don’t encounter it) usually requires some amount of testing from the user.

Similarly, an explanation of how the command install works does not constitute pushing the problem off on the user.


#11

Wait a minute!
If you publish a product and expect people to use it, then you need to stand behind that product.
No matter what the user paid for it, that doesn’t give the developer or product owner carte blanche to shrug off hard problems.
As I pointed out I felt I gave enough information, offered from a user perspective.
I even offered more information if he needed.
I also pointed there are numerous instances in the GitHub issues and on other forums e.g. StackOverflow.
I am willing to bet it is an issue in some inconsistent piece of garbage javascript file library that doesn’t behave properly in the MacOS file/process security model.


#12

There’s a negative interaction with your local security system, but that doesn’t necessarily mean that something’s wrong with Atom.

No matter what the user paid for it, that doesn’t give the developer or product owner carte blanche to shrug off hard problems.

When the problem is localized on your machine, the fix most likely is, too. You were given multiple potential leads for resolving the problem; that’s hardly shrugging it off.

I also pointed there are numerous instances in the GitHub issues and on other forums e.g. StackOverflow.

There are apparently multiple reasons why an app might be translocated, since your case doesn’t match the most common one.

I am willing to bet it is an issue in some inconsistent piece of garbage javascript file library that doesn’t behave properly in the MacOS file/process security model.

Do you have this difficulty with other Electron applications, or with Node in general? There are clearly some Mac users who have absolutely no issue with the security model.


#13

When the problem is localized on your machine, the fix most likely is, too. You were given multiple potential leads for resolving the problem; that’s hardly shrugging it off.

Maybe you didn’t notice but I didn’t start this thread with this problem someone else started this thread., I just gave more information about what was the cause of the disappearing command line tools because I have the SAME problem.

There are apparently multiple reasons why an app might be translocated, since your case doesn’t match the most common one.

Because not everybody see’s the problem doesn’t mean there isn’t one, and besides for months I ignored it and just worked around by not invoking from the command line. I am sure many are doing same.

Do you have this difficulty with other Electron applications, or with Node in general? There are clearly some Mac users who have absolutely no issue with the security model.

As a matter of fact since Postman quit running as a Chrome app and started running on Electron it has an issue updating. If I recall correctly it has some problem with a helper process. Again, another edge Electron problem with quite a few GitHub issues, claiming to be resolved an always reopened over multiple releases.

It’s most unfortunate that virus of a language, javascript, ever left the browser. Now I watch thousands of developers waste their lives on a crappy language, with crappy libraries, with crappy development tools and of course creating crappy buggy apps for customer/users.

This is my last comment to this useless thread, as I said I am sticking to Emacs it has been the worlds best IDE for over 20 years for me.


#14

It’s not the same problem. The original post talks about the commands needing to be reinstalled every time zsh is started. @jonny.kanai specifically says that, when he closed Atom and kept zsh open, the commands remained.

Your problem is that the commands are only working when you have an Atom window open. That’s completely different.

Even if they were the same, your computer translocating Atom when other people running Sierra aren’t seeing the same problem is, by definition, a problem that’s localized on your computer.

Because not everybody see’s the problem doesn’t mean there isn’t one, and besides for months I ignored it and just worked around by not invoking from the command line. I am sure many are doing same.

We can’t presume that other people have a problem they aren’t reporting. That’s a poor assumption. It might be that there are other people in your situation, but your situation would have to be solved in order to help them. That means that you would have to stop being intransigent and answer @leedohm’s questions.

As a matter of fact since Postman quit running as a Chrome app and started running on Electron it has an issue updating.

Okay, ignore Postman (because you don’t know if it’s a translocation issue). What about others? Slack? WP-Desktop? Nylas? Brave? Hyperterm? If this happens consistently across Electron apps, then that’s informative.

Again, another edge Electron problem with quite a few GitHub issues, claiming to be resolved an always reopened over multiple releases.

Links, please.

It’s most unfortunate that virus of a language, javascript, ever left the browser. Now I watch thousands of developers waste their lives on a crappy language, with crappy libraries, with crappy development tools and of course creating crappy buggy apps for customer/users.

If you have this level of prejudice, perhaps you should avoid the thing you have a problem with.

This is my last comment to this useless thread

Cool. Well, I’m replying anyway so that people who come after know how they should request assistance and what they shouldn’t do.


#15

Again, another edge Electron problem with quite a few GitHub issues, claiming to be resolved an always reopened over multiple releases.

Links, please.

From Postman:

"The helper daemon is needed for the auto updates. Ideally, this helper shouldn't be throwing a admin 
 privilege prompt and asking for installation, but we are tracking an upstream issue in the app's 
 underlying framework that might cause this in some versions of OSX. Could you let us know your OSX    
 version? We'll roll out a fix for the app as soon as this is fixed upstream.

 Upstream issue: https://github.com/electron/electron/issues/8191"

If you have this level of prejudice, perhaps you should avoid the thing you have a problem with.

Slack works great!
Thanks to it’s App Store installer!!!

Here is the resolution for those who might have been marginalized because Atom lacked a standard macOS installer:

It appears that since Atom lacks a standard macOS/OS X application installer it is now incumbent upon the user to explicitly use AND ONLY use the macOS Finder to move the Atom application from the Downloads Folder to the Application Folder. A user/customer must not use the Terminal shell to move, mv the Atom application to the Applications Folder or any other mechanism.

A Big Thanks to the poster of this link I posted earlier in this thread: /var/folders" (or “/private/var/folders”) is “per-user temporary files and caches”. It is created and managed by Mac OS X. It first showed up in 10.5. It’s purpose is to increase security by improving permissions (rwxr-xr-x) over previous temp and cache locations (/Library/Caches and /tmp, which are both rwxrwxrwt). and this Gist: Detect/disable translocation when moving app on macOS Sierra:

~ 2.2.5 >ls -l /usr/local/bin/atom
lrwxr-xr-x  1 rbirch  admin  53 Mar 23 16:50 /usr/local/bin/atom -> /Applications/Atom.app/Contents/Resources/app/atom.sh

Actually, the links posted by @leedohm were quite good, too.
I don’t know how I missed them originally?

this blog post
macOS Sierra’s App Translocation security feature
Though, I had read the one by Hoakley when he/she original posted the article.