/usr/bin/im-launch i3 fails

I was able to fix this by changing

```
exec $STARTUP
```

to

```
$STARTUP
```

Interestingly, this doesn't leave a shell process running -- it leaves `gdm-x-session` running. So perhaps that is emulating a shell somehow, but gets the unquoting wrong for `exec`?

@Wl-dustin: Where was that "exec $STARTUP" call? In some i3 config file?

From the first comment:
```
 May 18 11:32:21 hopper /usr/lib/gdm3/gdm-x-session[4733]: /etc/X11/Xsession.d/99x11-common_start: line 5: /usr/bin/im-launch i3: No such file or directory
```
it's in `/etc/X11/Xsession.d/99x11-common_start`

Can it be that you previously have had im-config installed on your machine and later uninstalled it without purging? What does

dpkg -l im-config

output? Any difference if you do:

sudo apt purge im-config

?

[Expired for i3-wm (Ubuntu) because there has been no activity for 60 days.]

[Expired for im-config (Ubuntu) because there has been no activity for 60 days.]

Ah, I didn't get notified of Gunnar's last comment.

```
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-=============-============-====================================
ii im-config 0.44-1ubuntu1 all Input method configuration framework
```

so im-config is installed. As you'll note in the first comment, the problem is not that `/usr/bin/im-launch` is not avaliable, it's that `/usr/bin/im-launch i3` (including the space character in the filename) is not available.

Please note that 'i3' is an argument to the command /usr/bin/im-launch, not part of a file name. So the error message incorrectly says "No such file or directory".

It would still be good if you could try to install im-config:

sudo apt purge im-config

Sorry,

s/install/uninstall/

You are correct that uninstalling `im-config` and reverting `99x11-common_start` to its original `exec $STARTUP`. But that just hides the issue by removing the package containing the bug, and in particular these lines in `70im-config_launch`:

```
if [ -x "$IMLAUNCH" ]; then
    STARTUP="$IMLAUNCH $STARTUP"
fi
```

I'm sorry to insist, but I think the understanding of the issue is incomplete. Please look at the error message in the first comment, and compare:

```
rubin ~ $ bash -c '/usr/bin/nosuch xyz'
bash: /usr/bin/nosuch: No such file or directory
rubin ~ $ bash -c '"/usr/bin/nosuch xyz"'
bash: /usr/bin/nosuch xyz: No such file or directory
```

the shell includes only the first component of the command line in its error message, indicating that it has searched for that string in PATH. In the first comment, you'll see that a space character and `i3` appear in the error message.

Another fix to this issue is to replace

```
exec $STARTUP
```

with

```
$STARTUP
```

meaning that something in how dash is interpreting that `exec` is causing it to not split the argument correctly. If this was bash I might suspect that STARTUP was an array, but dash appears to not support arrays.

It should be possible to replicate this with a new install, installing i3 and selecting that option from the login menu.

Thanks, your latest comment made me realize what the error message in the bug description actually says.

But neither im-config nor x11-common (which provides /etc/X11/Xsession.d/99x11-common_start) does that kind of double quoting AFAICT. The code appears not to be more complex than:

~$ sh
$ START="/usr/bin/apt --version"
$ exec $START
apt 2.0.2ubuntu0.1 (amd64)
~$

And it has worked for many cycles with the common default DMs such as GDM, LightDM and SDDM. So the code should reasonably not be changed without making sure it works everywhere.

Even if I finally understand the nature of the error message, it's not clear to me how that error message gets triggered when using i3.

At least we're seeing the same thing. I tried to experiment with this and couldn't reproduce it outside the Xsession environment.

On 2020-07-22 17:56, Wl-dustin wrote:
> At least we're seeing the same thing.

Yeah, sorry for being slow.

> I tried to experiment with this and couldn't reproduce it outside the
> Xsession environment.

Indeed, the files in /etc/X11/Xsession.d are not run automatically when entering a Wayland session.