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

Elvish cannot find its binary to start daemon #496

Closed
zzamboni opened this Issue Oct 5, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@zzamboni
Contributor

zzamboni commented Oct 5, 2017

It seems that if elvish is not in the path when starting Elvish for the first time, it cannot find its own binary to start the daemon. I have observed this problem on macOS 10.12.6. To reproduce:

  • Install Elvish using Homebrew or Nix.
  • Leave user's shell to the default of /bin/bash (or something other than Elvish)
  • Make sure no other copies of elvish are already running (including the elvish daemon)
  • Open Terminal.app and configure "Shells open with" to the path of the elvish binary (see screenshot for an example)

general

  • Start a new tab

I see an error like the following:

warning: cannot start daemon: cannot find elvish: not found
cannot connect to daemon after 1s: dial unix /var/folders/h0/rh70xwd16913g_2lg0rx9_300320w3/T/elvish-3212163/sock: connect: no such file or directory
Failed to initialize command history. Disabled.

Workaround: Use the -bin option to specify the binary location, like this: /Users/taazadi1/.nix-profile/bin/elvish -bin /Users/taazadi1/.nix-profile/bin/elvish

@xiaq

This comment has been minimized.

Member

xiaq commented Oct 10, 2017

The way Elvish finds itself is either from PATH or from argv[0]. This works most of the time, but unfortunately if you are running Elvish from somewhere not in PATH and as a login shell, Elvish won't be able to find itself, causing the error above. Login shells have argv[0] like -elvish which does not contain the full path to the binary. :-/ And this particular setting of Terminal.app causes Elvish to be run as a login shell.

You also mentioned on Telegram that putting Elvish in /usr/local/bin does not work. This is likely because /usr/local/bin is not part of PATH in the environment from which Terminal.app is launched. If you are seeing /usr/local/bin in PATH when you run bash from Terminal.app, that might be because it is set by bash, which sources /etc/profile. I am not very familiar about MacOS's setup of environment variables, but this is the most plausible explanation I have ATM.

To use Elvish as the "pseudo" login shell, the way I configure Terminal.app is by setting the following option in the profile configuration:

2017-10-10 7 51 39 pm

Be sure to enable "run inside shell", so that all environment variables set by bash are honored.

@xiaq

This comment has been minimized.

Member

xiaq commented Oct 10, 2017

A bit more on the background: Go does not support a simple fork syscall, only a fork-exec combo (as syscall.ForkExec). There is a good reason behind this: all Go binaries are multithreaded, and fork and threading do not work well together; here is one post but there are many other similar articles.

Due to this limitation, when forking the daemon, Elvish cannot just fork its own process; instead it has to find its binary and do a fork-exec on the same binary. To do this it first needs to know where its own binary it is. It uses argv[0] if it is available, and then falls back to PATH.

tw4452852 added a commit to tw4452852/elvish that referenced this issue Nov 26, 2017

try to set default executable path explicitly
fix elves#496

Signed-off-by: Tw <tw19881113@gmail.com>

tw4452852 added a commit to tw4452852/elvish that referenced this issue Nov 29, 2017

daemon: use os.Executable to get absolute executable path
fix elves#496

Signed-off-by: Tw <tw19881113@gmail.com>

@xiaq xiaq closed this in #519 Nov 29, 2017

xiaq added a commit that referenced this issue Nov 29, 2017

daemon: use os.Executable to get absolute executable path
fix #496

Signed-off-by: Tw <tw19881113@gmail.com>
@zzamboni

This comment has been minimized.

Contributor

zzamboni commented Nov 29, 2017

Great! I can confirm that the problem is solved in my tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment