nushell: Nushell doesn't play nice with "current directory"

Describe the bug

I found a problem that is hard to explain, so please bear with me. It seems like nushell doesn’t notify other processes about its current directory, or doesn’t start in the proper directory, or something. If I’m in tmux and I open a new split in the current directory, it actually opens the split in the directory that the initial tmux session was created or joined from. If I just make a split with my terminal, the same thing happens. I have tried in both wezterm and kitty in an effort to narrow it down and make sure this is actually a nushell problem.

How to reproduce

Here is a hopefully simple example with minimal dependencies.

Working:

  1. Configure tmux default-shell to be /usr/bin/bash (even if default-command is nushell)
  2. Create a new tmux session
  3. cd some-folder
  4. Run tmux split-window -v -c "#{pane_current_path}" or tmux new-window -a -c "#{pane_current_path}" or something equivalent
  5. Note that the current folder for the new pane is also some-folder as expected

Not working:

  1. Configure tmux default-shell to be /usr/bin/nu
  2. Create a new tmux session
  3. cd some-folder
  4. Run tmux split-window -v -c "#{pane_current_path}" or tmux new-window -a -c "#{pane_current_path}" or something equivalent
  5. Note that the current folder for the new pane is the original folder, not some-folder

In tmux specifically I just found that I can work around this issue by having default-command be nushell and default-shell be bash, but ironically I’m trying to phase out my usage of tmux and have not yet found a workaround for my terminal, in which the same problem exists. Despite this, I used tmux for my example because it is more common, terminal-agnostic, and lets me test different shells without changing my login shell.

Expected behavior

I expect terminals and terminal multiplexers to open nushell at a specific path when using common “open new split/pane/tab/window/whatever in current directory” functionality.

Screenshots

No response

Configuration

key value
version 0.60.0
branch makepkg
short_commit 74af31a4
commit_hash 74af31a42ff4feb8d5d9897c0d99c7434678a315
commit_date 2022-03-22 19:07:11 +00:00
build_os linux-x86_64
rust_version rustc 1.59.0 (Arch Linux rust 1:1.59.0-1)
cargo_version cargo 1.59.0
pkg_version 0.60.0
build_time 2022-03-23 00:39:08 +00:00
build_rust_channel release
features dataframe, default, trash, which, zip
installed_plugins

Additional context

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (6 by maintainers)

Most upvoted comments

Yes it is working. Thx!

I think I may have figured it out. I’m running Windows Terminal Preview v1.18.1462.0. I bet you’re running the normal Windows Terminal. I’m guessing OSC7 that sets this is not in Windows Terminal and only the preview maybe?

dup-win

As the issue creator I just wanted to weigh in and confirm: the changes work great! Thank you to everybody involved with this.