Revisit CLI installation strategy

• I am on the latest Hyper.app version

• I have searched the issues of this repo and believe that this is not a duplicate

• OS version and name: Linux

• Hyper.app version: Master

• Link of a Gist with the contents of your .hyper.js: Default

• Relevant information from devtools (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere):

• The issue is reproducible in vanilla Hyper.app: Yes

Issue

This issue was brought up a couple weeks ago that more or less got resolved by 2885 by silently failing cli installation for linux distros.

I was considering different approaches to symlinking/installing the cli on linux(using policykit to prompt user for privileged access to /usr/local/bin, or adding an alias to .bash_profile) but I got curious about the overall CLI install strategy. Overall I'm not convinced it's secure or tenable cross-platform. I couldn't believe that macOS even allowed an unprivileged user to symlink a file to /usr/local/bin from an executable. I wanted to ask why the cli wasn't enclosed in the hyper app itself by reading command line arguments in the main thread to trigger cli commands. This seems to circumvent issues a lot of these moving target issues with symlinking and checking for the current cliscriptpath.

Namely this issue is prevalent in AppImage builds because the the cli is enclosed in the AppImage which will never be mounted without it's execution to begin with, so a symlink to /tmp/.mount###-hyper/... is dead on exit.

Currently hyper doesn't accept command line arguments anyways so there's no worry of CLI namespace conflicts.

Start by reading issue 2891 and pull request 2885 to understand the existing Linux CLI installation behavior. Then inspect the current CLI installation path and AppImage handling described here; done would require an agreed cross-platform installation strategy and a defined implementation scope.