-
Notifications
You must be signed in to change notification settings - Fork 332
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
lfcd.sh runs in subshell - does not work well with tmux and {pane_current_path} #1615
Comments
We actually tried to remove the use of tempfiles in Can you please provide a minimal config and steps to reproduce? |
Interesting! Not sure what the best fix is, then. Perhaps there is another way without the temp files. But for now, I managed to reproduce the issue in a fresh Ubuntu VM; here are the steps: SetupInstall tmux and the latest lf
Create minimal config files. Note for tmux, I rebound the split to use the pane_current_path.
Reproduce issue
The new pane will open with the path of your current lf directory; this is the behavior we want :) Now do it again with lfcd
Now, the new pane will open with the path you were in when you entered the lfcd command. :( |
Thanks. I don't use Anyway I was able to reproduce the issue - for testing purposes I ended up displaying set -g status-right "#{pane_current_command} #{pane_current_path}"
set -g status-interval 1 I think the issue comes down to how I can't think of a good solution without making some kind of compromise:
One other thing you can try is to call
|
Also I'm not sure if it helps, but |
Thanks for the comments! It's very interesting; I never knew this limitation of bash. Mapping the I'm not well-versed in how important POSIX compatibility is for this project. All I can say from a user point of view it would be nice to have access to this alternative. As is, this issue happens "silently" - until I saw someone else use it, I thought this was a limitation of It's certainly less elegant than the current solution, which is too bad. |
Yeah the main problem is that it's possible for a pane to have multiple processes running (e.g. via a shell pipeline), and since each process has its own CWD, Regarding POSIX compatibility, I am not extremely uptight about it - TBH I advocated for the |
That sounds good. I'll create a pull request as soon as I get a chance. How would this work? This way, if mktemp does not exist or fails, it reverts to the current method.
credit again to @3ximus for the help 😄. |
After doing some more research, I have found that This is a somewhat hacky heuristic that isn't necessarily correct in all cases, and as a result
# set pane_path when changing directory
cmd on-cd &{{
printf "\e]7;$PWD\e\\" > /dev/tty
}}
# unset pane_path when quitting
cmd on-quit &{{
printf "\e]7;\e\\" > /dev/tty
}}
# trigger on-cd upon startup
on-cd
# use pane_path, falling back to pane_current_path
bind v split-window -h -c "#{?pane_path,#{pane_path},#{pane_current_path}}"
bind s split-window -v -c "#{?pane_path,#{pane_path},#{pane_current_path}}" |
Yes, this works well. I've been using it this way for the last four days now, and no problems. Where do you think is the best place for this solution to live? I could see it going well as part of the |
Works for me! Thanks for the help. I changed the issue title to make it easier to find if someone else runs into this. |
The lfcd function provided by this repo is currently.
However, this runs lf in a subshell. This is problematic because when using tmux and opening a new pane (using the pane_current_path), tmux does not navigate to the current folder; instead, the new pane navigates to the current directory when lf was initially run.
We have a solution that appears to work for now (shout out to @3ximus for helping figure this out).
If acceptable, this or something with similar functionality should be the new lfcd suggestion.
The text was updated successfully, but these errors were encountered: