Closed mazunki closed 1 month ago
If that's the behavior you want use
--cwd=$(PWD) not --cwd=current
If that's the behavior you want use
--cwd=$(PWD) not --cwd=current
Can I do this when setting my mappings? e.g
map kitty_mod+t launch --cwd=current --copy-env --type=tab
map kitty_mod+n launch --cwd=current --copy-env --type=window
map kitty_mod+enter launch --cwd=current --copy-env --type=os-window
I tried setting --cwd=$(PWD)
and --cwd=${PWD}
here, none of which seem to work.
Nope only with remote control, run from a shell
And I should note that while on Linux/BSD it is possible to use the symlink rather than the realpath it isnt on macos, the OS api returns real paths, and so for consistency it behaves the same on both platforms.
for consistency it behaves the same on both platforms.
I see, that's a fair reason. Thanks. I suspect that means a PR to provide this would not be desired, either.
Any suggestions on how I could make do with this? (I parse my CWD as part of my shell to trigger some hooks, so the difference is meaningful on my end)
You can write your own kitten that does what you want, see https://sw.kovidgoyal.net/kitty/kittens/custom/
It can set cwd to os.readlink('/proc/{pid_of_foreground_process}/exe') and then pass the open request on to the usual kitty machinery.
Describe the bug Launching a new instance of kitty in the current working directory causes the new instance to dereference the symlink of the directory we were in.
To Reproduce Steps to reproduce the behavior:
mkdir physical_dir
ln -sT physical_dir relative_dir
cd relative_dir
kitty @ launch --cwd=current --type=os-window
After running
pwd
on the new instance I would expect cwd to berelative_dir
and notphysical_dir
.Screenshots
We can see the newly spawned window on the right side, where I've run a single
pwd
command showing the unexpected path.Environment details
Additional context I have enabled remote control for the sake of the screenshot. Normally I use a mapping to open a new os window.