search

project-repo / cagebreak

Cagebreak: A Wayland Tiling Compositor Inspired by Ratpoison
MIT License
289 stars 19 forks source link

Losing reference to $CAGEBREAK_SOCKET #17

Closed kinleyd closed 2 years ago

kinleyd commented 2 years ago

After starting Cagebreak, initial configuration calls to the IPC socket work as usual. However, after cagebreak/config is executed, if I run this in a terminal: $ rlwrap nc -U $CAGEBREAK_SOCKET
I get this message: Ncat: You have to specify path to a socket to connect to. QUITTING. At this point 'echo $CAGEBREAK_SOCKET' returns nothing.

If I save the value of $CAGEBREAK_SOCKET in cagebreak/config (in the call to my initialization shell script, cb-netcat): 'echo $CAGEBREAK_SOCKET > socket-path' and use that socket path to access the IPC socket, it works.

So the ipc socket itself isn't the problem just the $CAGEBREAK_SOCKET seems to be getting lost at some point.

project-repo commented 2 years ago

Interesting...

I cannot reproduce your issue. For me, $CAGEBREAK_SOCKET is set after the start of cagebreak.

Could you please describe the issue more precisely?

cheers project-repo

kinleyd commented 2 years ago

Could you please describe the issue more precisely?

  • Which cagebreak version are you using? v. 1.8.2

  • Is the shell you use to interact with the socket special in some way?

    • Is it in a different TTY? No, the same as Cagebreak.

    • Is it started before or after executing cagebreak? After.

    • Is your shell bash or sh or something else? Currently zsh. When I experienced the issue I thought maybe it was because of the switch in shell environment. So I tried bash again but faced the same issue. This could still be the cause but I can't reason why.

    • What happens if you run nc directly without rlwrap? No difference.

  • Can you determine more precisely when (point in time relative to execution of cagebreak) $CAGEBREAK_SOCKET is lost? I will get back on this - I'll set it up to save socket path at different points and see: At the start and end of config, and at the start and end of my shell configuration file (the one called by ncat from config).

  • Is there any other detail you would like to share? (You mentioned emacs in another issue, is there any special way to start programs from emacs which somehow messes with env vars? Or any other programs you know that might have any influence?) Emacs has a section where we set env vars. Here all I do is take the existing $PATH variable and add specific paths I need for Emacs. I don't think this could be the cause because I was already doing this earlier and could get $CAGEBREAK_SOCKET's value.

kinleyd commented 2 years ago

$CAGEBREAK_SOCKET value was accessible at all points in cagebreak/config and the shell script called for initial configuration.

Anyway, I managed to identify the problem: Initially I was starting the Emacs daemon in config, but later changed to starting it as a systemd service, emacs.service. Set this way Emacs starts before Cagebreak and doesn't pick up $CAGEBREAK_SOCKET. The terminal I start netcat in is an Emacs package, vterm, which of course doesn't see $CAGEBREAK_SOCKET. I thought I had tested running netcat in alacritty (non-Emacs terminal) but apparently I hadn't, because when I tried it just now, it works while vterm doesn't.

So if I want to continue using systemd and emacs.service, I just have to continue to add a bit of setenv settings in Emacs to pick up $CAGEBREAK_SOCKET.

Dammit, sorry to have bothered you!

project-repo commented 2 years ago

Great! I'm glad to hear your problem is resolved. I am closing this issue.

cheers project-repo