Incompatible launch.sh for Almquist Shell (default on Alpine)

[florianb]

Precheck

• This issue seems to be reported underneath a different issue: Launch script can fail #944 (comment)

Environment

• Elixir & Erlang versions (elixir --version): Elixir 1.15.4 (compiled with Erlang/OTP 26)
• Elixir Language Server version: 0.16.0
• Operating system: Alpine Linux 3.18 (index.docker.io/elixir:alpine)
• Editor or IDE name (e.g. Emacs/VSCode): VSCode
• Editor Plugin/LSP Client name and version: ElixirLS 0.16.0

Current behavior

After the update to 0.16.0 the ElixirLS server fails to start:

Running /root/.vscode-server/extensions/jakebecker.elixir-ls-0.16.0/elixir-ls-release/launch.sh
Preffered shell ash is not supported, continuing in POSIX shell
Looking for ASDF install
ASDF not found
Looking for rtx executable
rtx not found
Installing ElixirLS release v0.16.0
Running in /app
Install complete
/root/.vscode-server/extensions/jakebecker.elixir-ls-0.16.0/elixir-ls-release/launch.sh: line 102: syntax error: unexpected redirection
[Error - 8:00:31 AM] Server initialization failed.
  Message: Pending response rejected since connection got disposed
  Code: -32097 
[Error - 8:00:31 AM] The ElixirLS - app server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.
[Error - 8:00:31 AM] ElixirLS - app client: couldn't create connection to server.
  Message: Pending response rejected since connection got disposed
  Code: -32097 
[Error - 8:00:31 AM] Restarting server failed
  Message: Pending response rejected since connection got disposed
  Code: -32097 

See the reproduction steps at the end of the issue.

Expected behavior

I'd expect the LS just starts without errors.

Cause for the problem?

The startup of the LS is interrupted by the syntax error thrown by ash.

I assume (i was not able to verify that behaviour) that the ash-parser starts parsing the final if-statement of the launch.sh it then stumbles over the bash redirection <<< in line 102 which is parsed as subsequent redirection due to missing support in ash (see this SO post).

Possible solution

I think the safest (in the awareness that there might be n other shells using different parsers) way to handle this is either move shell specific commands into dedicated shell-files. I immediately ran into the next syntax error (for the zsh section).

I would have offered a quick fix but splitting up into different files might touch objections.. 🙂

---

I use Docker to work with the ElixirLS, i tried to condense our Dockerfile:

FROM index.docker.io/elixir:alpine as base

ARG ELIXIR_LS_VERSION=v0.16.0
# see https://github.com/elixir-lsp/elixir-ls
ENV LS_DL_URL="https://github.com/elixir-lsp/elixir-ls/releases/download/${ELIXIR_LS_VERSION}/elixir-ls-${ELIXIR_LS_VERSION}.zip"

# Install build dependencies
RUN apk add --no-cache \
    build-base \
    openssh \
    curl \
    unzip \
    npm \
    git

# Prepare the build dir
WORKDIR /app

# Install hex and rebar
RUN mix local.hex --force \
    && mix local.rebar --force

RUN apk add --update-cache \
    && rm -rf /var/cache/apk/* \
    && mkdir /hex-home

RUN apk add --no-cache \
    inotify-tools \
    shadow \
    git \
    git-lfs \
    openssh \
    curl \
    unzip \
    bash \
    openssh \
    && mkdir /elixir-ls \
    && echo "${LS_DL_URL}" \
    && curl -Lo /elixir-ls/elixir-ls.zip "${LS_DL_URL}" \
    && cd /elixir-ls \
    && unzip elixir-ls \
    && rm /elixir-ls/elixir-ls.zip

RUN apk add --update-cache \
    && rm -rf /var/cache/apk/*

ENV PATH="${PATH}:/elixir-ls"

CMD sleep infinity

Building & Starting the container using

docker build -t elixir-ls .
docker run -it elixir-ls sh

Launching the LS in the container

cd /elixir-ls
./launch.sh

Steps to reproduce

[lukaszsamson]

So far only zsh and bash shells are supported (fish shell support is coming up). I don't have knowledge of ash nor resources to support it.

I would have offered a quick fix but splitting up into different files might touch objections.. 🙂

Please send a PR. Splitting is probably a good idea and fish script is already extracted

[florianb]

Done - i have the feeling that the handling of fish is somehow special and in my tests i wasn't able to start it using fish. However, i also added a Dockerfile to be able to quickly test stuff.

Let me know what you think.

[emk]

I found and commented on a related issue over at elixir-lsp/vscode-elixir-ls#374. I installed my entire Elixir & Erlang environment fresh as of yesterday. There is something moderately weird going on that I haven't figured out yet.

If we try to run under fish, the shell selector fails in a weird way.

[florianb]

Thanks a lot @emk - i guess the shell detection is not very robust since it relys on the existence and correctness of the $SHELL environment variable.

It would probably be more robust stick with a process-based approach here, f.e.:

SHELL=`echo $0`

This would be also a good point to add smoke tests for different shells (see #987).

[emk]

@florianb It's weirder than that, because first the script does:

preferred_shell=$(basename "$SHELL")

Then it does the following twice:

if [ "$preferred_shell" = "bash" ]; then

1. The first time it does this, it recognizes that it is not bash.
2. The second time it does this, it takes the then branch, thinking it's bash

So either someone has clobbered $preferred_shell, or the script is getting invoked twice, or something else equivalently wild is happening. And I've reproduce this on two different installs now.

Anyway, VS Code users can work around it by changing the first line to #!/bin/bash. I am honestly very confused.

[florianb]

@emk thanks a lot - i didn't dabble a lot with fish.

I guess (sorry i didn't make that clear in my previous post) that the $SHELL-variable isn't set properly for your environment.

I don't actually know why there's a relaunch at all, but probably it has something to do with preserving the current users environment and having the elixir-ls polluting a dedicated one.

However, because of the wrongly set $SHELL (which traditionally might be set by login - as this SO-post claims) i guess the launch scripts take a wrong path. That's why i supposed trying a different shell detection mechanism instead.

You also state in the referenced issue that the launch script prints:

Preffered shell $preferred_shell is not supported, continuing in POSIX shell,

If that's the case we also have an issue with the variable substitution.

Con you verify the contents of your $SHELL variable?

I think about a way to make the launch-procedure more robust in general.

[lukaszsamson]

Version 0.17.0 with support for fish and fixes for other shells has been released

[drobban]

Version 0.17.0 with support for fish and fixes for other shells has been released

Running into the exact same problem with version elixir_ls 0.18 in launch.sh

Running FreeBSD 13.2 with fish, version 3.6.1.
NVIM v0.9.4

Changing the script to use /usr/local/bin/bash instead of bourne shell solves the problem for me.

Is there a commit related to this issue that I can look at?

[lukaszsamson]

@drobban commit history of scripts directory?

[drobban]

@drobban commit history of scripts directory?

Took a look again.
I must have been sleeping last time I checked the source, as I thought the problem was still in place.

I now noticed the code change - thanks and awesome!

Just so weird, trying to figure out how the old version of the scripts ended up on my system.
Will have to back track this one =) I must have been sleep walking.