[REQUEST] please expose current kakoune executable being... executed

[mralusw]

Feature

Please expose the current kakoune executable, so that background %sh{} scripts can run "$kak_bin" -p ....

In an environment containing multiple kak versions (e.g. /opt/kak-master, /usr/bin/kak, /opt/kak-v2021.11.08 etc, with symlinks on top of that) it's confusing to tell which kak is being executed. Granted, kak -p only acts as a client, and probably can send commands just fine, and probably reads the same config files as the session-master; but this is just another uncertainty layer lurking in the back.

Another reason: kak may not be in the $PATH at all.

Usecase

No response

[alexherbo2]

It could be nice to expose the underlying socket path too, so we won’t need to spawn a process for each kak -p.

[Screwtapello]

When Kakoune launches a shell-block, it prefixes $PATH with a directory that only contains a symlink to the running version of Kakoune:

kakoune/src/shell_manager.cc

Lines 76 to 82 in 19e2225

	// Add Kakoune binary location to the path to guarantee that %sh{ ... }
	// have access to the kak command regardless of if the user installed it
	{
	const char* path = getenv("PATH");
	auto new_path = format("{}../libexec/kak:{}", split_path(get_kak_binary_path()).first, path);
	setenv("PATH", new_path.c_str(), 1);
	}

That way, scripts that naively invoke kak will automatically get the right executable.

[krobelus]

It could be nice to expose the underlying socket path too, so we won’t need to spawn a process for each kak -p.

That's also considered in kakoune-lsp/kakoune-lsp#553. Not sure what are reasonable use cases, kak -p is usually fast enough.

[mralusw]

When Kakoune launches a shell-block, it prefixes $PATH with a directory that only contains a symlink to the running version of Kakoune:

Then I guess the remaining limitation is that the binary has to be named kak? E.g. if I run /opt/kak-master/bin/kak.debug (or kak.haskell, or kak.clang, or kak.extra-param-expansion), still the scripts using kak -p would get kak, not $kak_bin (if kak exists at all).

[mralusw]

When Kakoune launches a shell-block, it prefixes $PATH with a directory that only contains a symlink to the running version of Kakoune:

... or is that a real symlink in a removed tmp dir?

[Screwtapello]

When you run make in the Kakoune repo, it builds a binary whose name is based on the given compilation options (kak.opt, kak.debug.san_a, etc.) and then symlinks that binary to kak:

https://github.com/mawww/kakoune/blob/master/src/Makefile#L93-L96

Meanwhile, libexec/kak/kak is a symlink to the kak symlink created above:

https://github.com/mawww/kakoune/tree/master/libexec/kak/kak

If you make install, the build system ensures that the binary you built is installed as $PREFIX/bin/kak, and that $PREFIX/libexec/kak/kak is a symlink to that binary.

You can definitely break this system if you copy the binary to a new location without also copying the libexec directory to the same relative path, but you can also break things by omitting to copy the system kakrc or the standard library plugins or the online documentation, so it's no different in that respect.

[sidkshatriya]

Then I guess the remaining limitation is that the binary has to be named kak

Even if you rename your kak binary to something really custom, you can get around this problem on linux by executing

"/proc/${kak_session}/exe" -p $kak_session

The exe file is a symlink to the kak binary (whatever it is called) in the /proc file system.

Edit: I realize that there might be some issues with named kak sessions so this approach will not work in all cases..

[lenormf]

What’s your usecase?

[sidkshatriya]

Hmm... I thought about this more. Something like

"/proc/${kak_client_pid}/exe" -p $kak_session

should always work in linux if you have a custom name for your kak executable (and even if you have named sessions...)

[mralusw]

Then I guess the remaining limitation is that the binary has to be named kak

Even if you rename your kak binary to something really custom, you can get around this problem on linux by executing

It's nothing "really custom", it's compiling with gcc/clang (with their versions) and finishing up with install/install-strip. In order to test bugs, one needs multiple executables around, being spawned predicatably.

"/proc/${kak_session}/exe" -p $kak_session

Yes! But that's Linux-only. Why not expose $kak_bin?

[mralusw]

When you run make in the Kakoune repo, it builds a binary whose name is based on the given compilation options (kak.opt, kak.debug.san_a, etc.) and then symlinks that binary to kak:

OK. For now, the workaround is to install each kak into its own /opt/kak-v*[.debug][.branch] or whatever. Don't install multiple custom-named executables into /opt/kak/bin/.