Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sessions are opened in the server's cwd (/ by default) instead of the creating client's cwd #14

Open
Yaraslaut opened this issue Dec 12, 2022 · 3 comments
Labels
Kind: Bug 🐞 Something isn't working Target: Communication protocol 💬⚠️ A part of the core library which deals with client-server messaging Target: Core 💥 Core architectural support library Target: Reference implementation 📃 The "official" Client & Server implementations

Comments

@Yaraslaut
Copy link

Yaraslaut commented Dec 12, 2022

It would be nice to open it in $HOME or $PWD directory.

@whisperity whisperity added Kind: Bug 🐞 Something isn't working Target: Reference implementation 📃 The "official" Client & Server implementations labels Dec 12, 2022
@whisperity
Copy link
Owner

This is likely because of the call to ::daemon() when a server is started in the background. I vaguely recall the manpage mentioning such...

Starting sessions in HOME should be fairly easy to implement. Starting new sessions in pwd is a tougher cookie, because the communication protocol right now does not submit this information at session start request, but of course it could be extended with such option.

In general, maybe Process::SpawnOptions should have an optional "starting directory" member, and all of this would just need to be wired onto that.

@whisperity whisperity changed the title Monomux on startup opens in / Monomux on startup opens in / Dec 12, 2022
@whisperity whisperity added Target: Communication protocol 💬⚠️ A part of the core library which deals with client-server messaging Target: Core 💥 Core architectural support library labels Dec 12, 2022
@Yaraslaut
Copy link
Author

Yaraslaut commented Dec 13, 2022

Indeed, you can specify this in ::daemon call

/* Put the program in the background, and dissociate from the controlling
   terminal.  If NOCHDIR is zero, do `chdir ("/")'.  If NOCLOSE is zero,
   redirects stdin, stdout, and stderr to /dev/null.  */
extern int daemon (int __nochdir, int __noclose) __THROW __wur;

So, we can simply change daemon(0,0) -> daemon(1,0) here

[] { return ::daemon(0, 0); }, "Backgrounding ourselves failed", -1);

And it will spawn server in pwd

@whisperity
Copy link
Owner

whisperity commented Dec 13, 2022

That solution is too simple and dumbs the problem down to the cwd of the server, which, in fact, should be completely irrelevant.
A server is spawned, generally, once per uptime (on our developer server, I have had the server running since early July!). Now, if the initial call to the server's spawn happens to be in a directory which no longer exists by the time you end up wanting to create new sessions, it will cause problems because all the newly created sessions will create with a cwd that is not valid.

The server existing under / is not inherently the problem. The solution is to make sure that every child that is spawned, they spawn with the right directory. In fact, a quick glance at tmux shows that while they indeed have daemon(1, 0) somewhere, the client sends its own cwd when creating the session:

	client_send_identify(ttynam, termname, caps, ncaps, cwd, feat);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Kind: Bug 🐞 Something isn't working Target: Communication protocol 💬⚠️ A part of the core library which deals with client-server messaging Target: Core 💥 Core architectural support library Target: Reference implementation 📃 The "official" Client & Server implementations
Projects
None yet
Development

No branches or pull requests

2 participants