xprop: error: Invalid window id format: _NET_SUPPORTING_WM_CHECK. about screenfetch HOT 23 CLOSED

I'm going to mark this as WONTFIX at this point. Closing.

from screenfetch.

They're the best. I'll look at this tomorrow.

from screenfetch.

Is there any update on this @ShanaTsunTsunLove?

from screenfetch.

Ooops, I think I missed your update a month ago. Sorry to keep you waiting.

from screenfetch.

Grrr. That's a pesky bug you have there. Might have to break out the spray.

from screenfetch.

Blech. I will get to this, I promise.

from screenfetch.

I think the issue might be that you're checking for the substring "invalid window id format" when you need to be checking for "Invalid window id format"

from screenfetch.

I completely forgot this was open. That MIGHT be a problem. Hmmm...lemme check. That could DEFINITELY be the problem.

Check the referenced commit.

from screenfetch.

Even worse.

from screenfetch.

Wow, that was quick for an old issue! Thanks for check it so quickly. Hmmm....tricky bug you got here. Oh. Wait.

I put something in recently to help with WM name case-sensitiveness and that's what's causing those declare errors. I wonder why that's a problem for your setup? Maybe an older version of BASH?

from screenfetch.

GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

from screenfetch.

I just remembered that there's zsh on this box as well. After a rather long wait (60 sec+) here's what I get. Mind that this is a headless box (or rather, it has X installed but I'm SSHing to it without doing anything like X forwarding).

zsh 4.2.6 (x86_64-redhat-linux-gnu)

from screenfetch.

Ah yes! That will do it. Okay, I've corrected THAT bug with latest commit (adc2324) and now we can get back to working on your other one. Would you test to make sure it's actually fixed?

Also, that just refreshed for me. Running through ZSH will not result in the same output and WILL error on some things.

And...headless. So...WM info shouldn't be showing up at ALL?

from screenfetch.

I confirm that it's back to just throwing

xprop: error: Invalid window id format: _NET_SUPPORTING_WM_CHECK.
xprop: error: Invalid window id format: _NET_SUPPORTING_WM_CHECK.

from screenfetch.

So, can we confirm that this is a box not running X? So it shouldn't be displaying X-dependent values in the first place?

from screenfetch.

OH DAMMIT. I know why it's STILL throwing those errors. [[ ]] is a BASH 4.0+ thing, iirc. So it has no idea what to do with those. HM.

from screenfetch.

I did a little experimentation just now. All the times throughout this bug I have been using ssh -Y (because ssh -X doesn't work for various reasons). Just using plain ssh without unecrypted X forwarding (-Y) behave correctly for a headless box

I'm unsure whether this invalidates this bug and it's something that I need to fix on my end.

from screenfetch.

Well, ssh -Y implies X-Forwarding, so it thinks there is an X session there. Which is why it is throwing X dependent output in the first place and erroring because there is no $DISPLAY.

The problem, however, will still persist for anyone running BASH pre-4.0 on a machine running X.

from screenfetch.

Can we confirm the above @Fuuzetsu?

from screenfetch.

Sorry, I didn't realise you wanted me to confirm anything.

$DISPLAY is set and X forwarding works as seen on the screenshot (limolssh is just an alias for ssh which includes -Y)

from screenfetch.

Honestly, since your BASH is so far behind, I'm not even sure where to start on making it compatible. I may be forced to mark this one WONTFIX. :/

from screenfetch.

Well, personally I don't actually care about this working on bash 3.* and I only reported it because I happened to spot the bug. Let me know if you WONTFIX for bash 3 so that I can file an appropriate dependency issue with my distro.

There does remain the issue of it not working in zsh though, doesn't it? I posted the screenshot of what happens on the same box with zsh few comments up. I'm not sure if it's the same bug or what.

from screenfetch.

zsh doesn't contain a lot of BASHISMs that screenfetch relies on. Such as [[ ]] operators and some other such things. screenfetch also explicitly asks for BASH functionality at certain points.

I do believe your problems are related to BASH -4.0 but I need to look into it a little more. I REALLY hate marking ANY bug/issue as WONTFIX, so I'll leave this open for now. Thank you very much for reporting this!

from screenfetch.