[GH-ISSUE #182] Under WSL, `spt` does nothing on invocation

kerem commented

2026-02-28 14:46:58 +03:00

Owner

Originally created by @ix on GitHub (Dec 2, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/182

I have installed spotify-tui both through cargo install spotify-tui and by building from git master, in both cases running spt results in nothing happening and the program exiting.

spotify-tui $ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.20s
     Running `target/debug/spt`
spotify-tui $

On the first run I was prompted for my credentials, which I entered. I have tried deleting ~/.config/spotify-tui and re-authenticating to see if that fixed it, which it did not.

Let me know if any further information is needed!

Cargo/Rust versions:

spotify-tui $ cargo --version
cargo 1.39.0 (1c6ec66d5 2019-09-30)
spotify-tui $ rustc --version
rustc 1.39.0 (4560ea788 2019-11-04)

Originally created by @ix on GitHub (Dec 2, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/182 I have installed spotify-tui both through `cargo install spotify-tui` and by building from git master, in both cases running `spt` results in nothing happening and the program exiting. ``` spotify-tui $ cargo run Finished dev [unoptimized + debuginfo] target(s) in 0.20s Running `target/debug/spt` spotify-tui $ ``` On the first run I was prompted for my credentials, which I entered. I have tried deleting `~/.config/spotify-tui` and re-authenticating to see if that fixed it, which it did not. Let me know if any further information is needed! Cargo/Rust versions: ``` spotify-tui $ cargo --version cargo 1.39.0 (1c6ec66d5 2019-09-30) spotify-tui $ rustc --version rustc 1.39.0 (4560ea788 2019-11-04) ```

kerem closed this issue

2026-02-28 14:46:58 +03:00

kerem commented

2026-02-28 14:46:59 +03:00

Author

Owner

@ix commented on GitHub (Dec 2, 2019):

Some additional information:
After entering the Client ID and Client Secret on the first run or after deleting the config directory, the following message is displayed in the program output

Error Os { code: 2, kind: NotFound, message: "No such file or directory" };Please navigate here ["https://accounts.spotify.com/authorize?[some redacted params]"]

Navigating to this URL leads to the below success page, but the program quits after that and continues its behavior of doing nothing.

spotify-tui
Client authorized. You can return to your terminal and close this window.

@ix commented on GitHub (Dec 2, 2019): Some additional information: After entering the Client ID and Client Secret on the first run or after deleting the config directory, the following message is displayed in the program output ``` Error Os { code: 2, kind: NotFound, message: "No such file or directory" };Please navigate here ["https://accounts.spotify.com/authorize?[some redacted params]"] ``` Navigating to this URL leads to the below success page, but the program quits after that and continues its behavior of doing nothing. ``` spotify-tui Client authorized. You can return to your terminal and close this window. ```

kerem commented

2026-02-28 14:46:59 +03:00

Author

Owner

@Rigellute commented on GitHub (Dec 2, 2019):

Sorry to hear this @ix, which operating system are you on? I have a suspicion this is related to the new clipboard feature.

If you are on linux, you might now need to install xorg-dev

@Rigellute commented on GitHub (Dec 2, 2019): Sorry to hear this @ix, which operating system are you on? I have a suspicion this is related to the new clipboard feature. If you are on linux, you might now need to install [xorg-dev](https://github.com/aweinstock314/rust-clipboard#prerequisites)

kerem commented

2026-02-28 14:46:59 +03:00

Author

Owner

@ix commented on GitHub (Dec 2, 2019):

Hi there Rigellute, thanks for a timely response.

/etc/lsb-release lists the following;

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"

This is in Windows Subsystem for Linux, with a full uname of

Linux ahostname 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01 16:53:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

Windows specifications are as follows:

I have tried running the program both in and out of tmux to no avail. xorg-dev is installed, alongside the libxcb* dependencies... xorg-dev is already the newest version (1:7.7+19ubuntu7.1)

I am running the program in a headless environment, perhaps that could be related to it as I assume an X server is needed for the X clipboard functionality to work? I will test later with X11 support through Xming if needed.

@ix commented on GitHub (Dec 2, 2019): Hi there Rigellute, thanks for a timely response. /etc/lsb-release lists the following; ``` DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" ``` This is in Windows Subsystem for Linux, with a full `uname` of ``` Linux ahostname 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01 16:53:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux ``` Windows specifications are as follows: ![image](https://user-images.githubusercontent.com/1900521/69981405-28783e00-152a-11ea-9299-b5b4254b2e7c.png) I have tried running the program both in and out of tmux to no avail. `xorg-dev` is installed, alongside the libxcb* dependencies... `xorg-dev is already the newest version (1:7.7+19ubuntu7.1)` I am running the program in a headless environment, perhaps that could be related to it as I assume an X server is needed for the X clipboard functionality to work? I will test later with X11 support through Xming if needed.

kerem commented

2026-02-28 14:46:59 +03:00

Author

Owner

@Rigellute commented on GitHub (Dec 2, 2019):

Hmm... thanks for this extra information.

If it is not too much bother, would you mind reproducing this in dev mode? i.e. clone the repo and cargo run?

That might give you the error causing the app to exit immediately.

I need to make the error appear in release mode too.

@Rigellute commented on GitHub (Dec 2, 2019): Hmm... thanks for this extra information. If it is not too much bother, would you mind reproducing this in dev mode? i.e. clone the repo and `cargo run`? That might give you the error causing the app to exit immediately. I need to make the error appear in release mode too.

kerem commented

2026-02-28 14:46:59 +03:00

Author

Owner

@ix commented on GitHub (Dec 3, 2019):

I've worked it out!

With Xming (a Windows X server) running, invoking spt like follows causes it to work fine:
env DISPLAY=localhost:0.0 spt (note that I use the "fish" shell and so this is equivalent to DISPLAY=localhost:0.0 spt)

Removing the environment variable with a valid X11 display causes the "silent fail" behavior I initially reported to occur. Since you mentioned X support being a requirement for the clipboard functionality, it would perhaps be best to either have the clipboard (and thus dependency on X) toggleable with a flag such as --no-x or to check the existence of the X display within the code, store it using something like std::Option and henceforth operate on it only if existent.

I would be more than happy to contribute this change if desirable, but it may take me a week or so to have the time for it.

@ix commented on GitHub (Dec 3, 2019): I've worked it out! With Xming (a Windows X server) running, invoking `spt` like follows causes it to work fine: ```env DISPLAY=localhost:0.0 spt``` (note that I use the "fish" shell and so this is equivalent to `DISPLAY=localhost:0.0 spt`) Removing the environment variable with a valid X11 display causes the "silent fail" behavior I initially reported to occur. Since you mentioned X support being a requirement for the clipboard functionality, it would perhaps be best to either have the clipboard (and thus dependency on X) toggleable with a flag such as `--no-x` or to check the existence of the X display within the code, store it using something like `std::Option` and henceforth operate on it only if existent. I would be more than happy to contribute this change if desirable, but it may take me a week or so to have the time for it.

kerem commented

2026-02-28 14:47:00 +03:00

Author

Owner

@ix commented on GitHub (Dec 3, 2019):

Just to add to the above: xfvb-run spt also works, by running spt in the context of an in-memory X Server, and is useful when there isn't actually an X server set up to connect to.

@ix commented on GitHub (Dec 3, 2019): Just to add to the above: `xfvb-run spt` also works, by running spt in the context of an in-memory X Server, and is useful when there isn't actually an X server set up to connect to.

kerem commented

2026-02-28 14:47:00 +03:00

Author

Owner

@Rigellute commented on GitHub (Dec 3, 2019):

Great that you've figured it out! And thanks for the write up.

You are right, we should probably gracefully handle the error when the clipboard can't be set up. This should be easy to implement. Will investigate setting up a flag to toggle the clipboard behaviour.

@Rigellute commented on GitHub (Dec 3, 2019): Great that you've figured it out! And thanks for the write up. You are right, we should probably gracefully handle the error when the clipboard can't be set up. This should be easy to implement. Will investigate setting up a flag to toggle the clipboard behaviour.

kerem commented

2026-02-28 14:47:00 +03:00

Author

Owner

@Rigellute commented on GitHub (Jan 26, 2020):

This was fixed in #217

@Rigellute commented on GitHub (Jan 26, 2020): This was fixed in #217

kerem referenced this issue

2026-02-28 14:47:02 +03:00

[GH-ISSUE #207] Extremely slow #102

kerem referenced this issue

2026-02-28 14:47:03 +03:00