'xprop: unable to open display ''' message spam, when no display is available

[mokasin]

When logging in remotely over SSH in a non-graphical session, after every command

xprop:  unable to open display ''

is displayed. Maybe check for DISPLAY environment variable first, before running xprop?

So in the spirit of

[ -n "$DISPLAY" ]; and xprop etc

[franciscolourenco]

So you installed this plugin in a server because of your dotfiles?

[mokasin]

It's not on a server but on a machine I also work on remotely.

[franciscolourenco]

I guess we should disable Done completely if the login is from ssh..

[mokasin]

Yes, that's reasonable

[dpc]

I was going to report the same problem.

Maybe you could try to fall back to use tmux display?

Also, as an immediate fix, please just pipe errors to /dev/null and release it. I really like this plugin, but this xprop thing is really annoying. :)

[franciscolourenco]

I will try address this tonight. @dpc In the meanwhile you can actually fork it and install from your repo with fisherman.

[franciscolourenco]

@dcp with tmux display do you mean that you would like to have a notification in tmux status bar when you are using tmux over ssh?

[franciscolourenco]

Can you please test if https://github.com/fisherman/done/tree/20 fixes the problem?

fisher uninstall done
fisher install fisherman/done:20

[dpc]

[I] dpc@futex ~> ls
''$'\266\177'   
(... actual output ...)

[franciscolourenco]

fish version?

[dpc]

fish, version 2.5.0

[franciscolourenco]

@dpc just updated with a new version, can you please try again? If you still have the same branch installed fisher update should be enough, otherwise restart fish after that.

[mokasin]

I can confirm, that the latest update does not produce the unwanted xprop in an ssh session.

[c02y]

When I'm in tty mode such as "Ctrl-Alt-F2", a line

xprop: unable to open display''

will always be displayed before fish prompt.

I tried to update done.fish to the latest version (commit 1485d72), but it is still the same result. It is normal when I'm in Desktop.

And I notice that the environment value of TERM is "linux" when I'm in tty mode such as "Ctrl-Alt-F2", and when I'm in desktop mode, it is "xterm-256color", and I tried to ssh into another remote machine, the TERM value is also "xterm-256color".

So I don't know if this is the generic way to check whether I'm in tty mode such as "Ctrl-Alt-F2".

---

UPDATE:

The environment value of DISPLAY is empty both in tty mode such as "Ctrl-Alt-F2" and when sshing into another machine, and the value of it when I'm in desktop is not empty, I guess this value can be determined to dismiss the error message or not.

This is the main part I tweaked a little in done.fish

....
function __done_get_window_id
    if type -q lsappinfo
        lsappinfo info -only bundleID (lsappinfo front) | cut -d '"' -f4
    else if type -q xprop
        # verify that the system has graphical capabilites before initializing
        if test $DISPLAY
            xprop -root 32x '\t$0' _NET_ACTIVE_WINDOW | cut -f 2
        end
    end
end

if test -n __done_get_window_id  # is able to get window id
    set -g __done_initial_window_id ''
....

Already tested in tty mode and ssh mode.

[franciscolourenco]

@c02y thanks for the report! can you please test 1.4.1?

[c02y]

OK, it works fine. But the line containing "$SSH_CLIENT" is unnecessary, already tested earlier.

Or you can just replace the part in done.fish with the snippet I posted earlier.

[franciscolourenco]

@c02y I left it because I didn't have opportunity to test what happens when you ssh into a mac. Next time you feel like contributing actual code feel free to open a pull request :)

[c02y]

I don't have a mac, so I cannot help with that, but I tested ssh between Linux boxes.

It is not complicated modification, so for me it's unnecessary to open a pull request, hope you wouldn't mind.