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

Allow opening new tab in CWD, but without the ssh kitten #5672

Closed
azertyfun opened this issue Nov 15, 2022 · 4 comments
Closed

Allow opening new tab in CWD, but without the ssh kitten #5672

azertyfun opened this issue Nov 15, 2022 · 4 comments

Comments

@azertyfun
Copy link

Is your feature request related to a problem? Please describe.

I just tried the ssh kitten, and it just works wonderfully!
My only gripe is that I need to be able to:

  1. Open an SSH kitten
  2. Open a new tab in the current kitten (very handy feature)
  3. Open another new tab in the current directory OUTSIDE the ssh kitten to work on my local copy.

Describe the solution you'd like

Anything that allows me to specify whether I want the local or remote CWD is fine by me.

Describe alternatives you've considered

new_[tab|window]_with_cwd implicitely using cwd as meaning "current remote directory" is a bit weird, but understandable. Either having more explicit directives (new_tab_with_remote_cwd/new_tab_with_local_cwd) or an argument new_tab_with_cwd local sounds great.

In the meantime I've been using new_tab, but this means I have to cd back to my local directory every time I create a new tab/window.

Additional context

If you tell me what syntax you want, I'd be happy to write a PR for it. Looks like it's as simple as giving a flag to .window.CwdRequest's constructor and using it in CwdRequest.modify_argv_for_launch_with_cwd?

@kovidgoyal
Copy link
Owner

map f1 launch --cwd=oldest

https://sw.kovidgoyal.net/kitty/launch/#cmdoption-launch-cwd

@azertyfun
Copy link
Author

Ah, thanks for that! Hadn't noticed there was such a flexible option available.

However this does not work for me, as it looks like the CwdRequest.request_type flag is completely ignored here.
Whatever setting I use for --cwd, it always drops me in the kitten since reported_cwd is always set as I use the shell integration everywhere.

The following patch fixes the issue for me and allows --cwd=oldest to properly drop me into the local shell:

diff --git a/kitty/window.py b/kitty/window.py
index 1532a09d..5e6e94c6 100644
--- a/kitty/window.py
+++ b/kitty/window.py
@@ -99,7 +99,7 @@ def modify_argv_for_launch_with_cwd(self, argv: List[str]) -> str:
         if not window:
             return ''
         reported_cwd = path_from_osc7_url(window.screen.last_reported_cwd) if window.screen.last_reported_cwd else ''
-        if reported_cwd:
+        if reported_cwd and self.request_type is CwdRequestType.current:
             # First check if we are running ssh kitten, and trying to open the configured login shell
             if argv[0] == resolved_shell(get_options())[0]:
                 ssh_kitten_cmdline = window.ssh_kitten_cmdline()

Should I create a PR or a separate issue for this?

@kovidgoyal
Copy link
Owner

Actually thinking about it, this wont work as the foreground process
group will consist of the ssh kitten and the actual ssh process not the
shell from which you launched the kitten as the shell usually
relinquishes the tty to the process it launches.

For your use case you will need a new special keyword for --cwd say
"root", which will resolve to the very first process launched in that
window, aka the shell in your case.

@khaitranhq
Copy link

Thank you.
Worked with config root

map ctrl+shift+t launch --type tab --cwd root

haunt98 added a commit to haunt98/dotfiles that referenced this issue May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants