starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal's working directory (i.e. for duplicate tab) does not default to the startup directory being used #12316

New Issue
Closed
opened 2026-01-31 03:12:10 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 03:12:10 +00:00
Owner
Copy Link

Originally created by @TBBle on GitHub (Jan 30, 2021).

Environment

Windows build number: Microsoft Windows [Version 10.0.19042.746]
Windows Terminal version (if applicable): 1.6.10272.0

Steps to reproduce

  • Get OSC 9;9 working, so that duplicate tab and splitPane+duplicate correctly carry the current working directory (#3158)
  • Duplicate a tab in some directory (ctrl+shift+d)
  • Before that tab issues OSC 9;9, split-duplicate the pane (alt+shift+d, see below)

The following non-default keybind was used to replicate this:

    {
      "command": {
        "action": "splitPane",
        "split": "auto",
        "splitMode": "duplicate"
      },
      "keys": "alt+shift+d"
    },

Expected behavior

Both panes in the new tab are in the desired working directory

Actual behavior

The first pane is in the desired working directory, but the second pane is in the default working directory.

Notes

If I wait between the ctrl+shift+d and alt+shift+d for my profile to load and my prompt to issue the OSC 9;9, then the expected behaviour occurs.

I assume this should be relatively easy to fix, assuming there's some point in the construction process that has access to both settings.StartingDirectory and the ITerminalApi for the new pane or tab.

Originally created by @TBBle on GitHub (Jan 30, 2021). # Environment ```none Windows build number: Microsoft Windows [Version 10.0.19042.746] Windows Terminal version (if applicable): 1.6.10272.0 ``` # Steps to reproduce * Get OSC 9;9 working, so that duplicate tab and splitPane+duplicate correctly carry the current working directory (#3158) * Duplicate a tab in some directory (ctrl+shift+d) * Before that tab issues OSC 9;9, split-duplicate the pane (alt+shift+d, see below) The following non-default keybind was used to replicate this: ```jsonc { "command": { "action": "splitPane", "split": "auto", "splitMode": "duplicate" }, "keys": "alt+shift+d" }, ``` # Expected behavior Both panes in the new tab are in the desired working directory # Actual behavior The first pane is in the desired working directory, but the second pane is in the default working directory. # Notes If I wait between the ctrl+shift+d and alt+shift+d for my profile to load and my prompt to issue the OSC 9;9, then the expected behaviour occurs. I assume this should be relatively easy to fix, assuming there's some point in the construction process that has access to both `settings.StartingDirectory` and the `ITerminalApi` for the new pane or tab.
claunia commented 2026-01-31 03:12:12 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 1, 2021):

Interesting. @skyline75489 I bet if we pre-seed the "last reported working directory" with the starting directory for the pane we will get identical behavior for NON-OSC 9;9 clients and better behavior for OSC-9;9 clients.

In short: duplicate-splitting a pane twice starts the third pane in the wrong folder because it tries to copy the unreported starting directory from the second pane which hasn't send its own OSC 9;9 yet.

@DHowett commented on GitHub (Feb 1, 2021): Interesting. @skyline75489 I bet if we pre-seed the "last reported working directory" with the starting directory for the pane we will get identical behavior for NON-OSC 9;9 clients and *better* behavior for OSC-9;9 clients. In short: duplicate-splitting a pane twice starts the third pane in the wrong folder because it tries to copy the unreported starting directory from the second pane which hasn't send its own OSC 9;9 yet.
claunia commented 2026-01-31 03:12:12 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Feb 2, 2021):

I’m not a pane user so I don’t have the whole picture here. But generally I feel it is a fair request to pre-seed the "last reported working directory" with the starting directory for the pane. I’ll dig later.

获取 Outlook for iOShttps://aka.ms/o0ukef

@skyline75489 commented on GitHub (Feb 2, 2021): I’m not a pane user so I don’t have the whole picture here. But generally I feel it is a fair request to pre-seed the "last reported working directory" with the starting directory for the pane. I’ll dig later. 获取 Outlook for iOS<https://aka.ms/o0ukef>
claunia commented 2026-01-31 03:12:12 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Feb 2, 2021):

I'm not a pane user either (I was playing with panes for the first time to try out OSC 9;9 ^_^), but I expect dupicate-tab twice would have the same issue.

The suggested pre-seeding fix sounds like what I would expect to work. If it can be done somewhere that isn't specific to the duplicate tab and duplicate pane code-paths, then it would be consistent for any other situations where a terminal is started with an overridden starting directory, e.g. a future "new tab in this directory" command.

One visible change for non-OSC9;9 clients might be that if you started a profile in a different working directory than its default than it's default (I don't know how to do this, does wt have a starting-directory override arg?) then duplicate-tab and duplicate-pane would inherit that starting directory. That sounds like it might be an improvement, but might be initially surprising to users.

@TBBle commented on GitHub (Feb 2, 2021): I'm not a pane user either (I was playing with panes for the first time to try out OSC 9;9 ^_^), but I expect dupicate-tab twice would have the same issue. The suggested pre-seeding fix sounds like what I would expect to work. If it can be done somewhere that isn't specific to the duplicate tab and duplicate pane code-paths, then it would be consistent for any other situations where a terminal is started with an overridden starting directory, e.g. a future "new tab in this directory" command. One visible change for non-OSC9;9 clients might be that if you started a profile in a different working directory than its default than it's default (I don't know how to do this, does `wt` have a starting-directory override arg?) then duplicate-tab and duplicate-pane would inherit that starting directory. That sounds like it might be an improvement, but might be initially surprising to users.
claunia commented 2026-01-31 03:12:13 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 17, 2021):

I don't actually have an "area path" for this. @zadjii-msft, do you have any ideas for the area that means "Terminal, the application, but not the control, but not the UI exactly -- the thing that ties them all together, and the place where OSC 9;9 is truly considered"?

@DHowett commented on GitHub (Feb 17, 2021): I don't actually have an "area path" for this. @zadjii-msft, do you have any ideas for the area that means "Terminal, the application, but not the control, but not the UI exactly -- the thing that ties them all together, and the place where OSC 9;9 is truly considered"?
claunia commented 2026-01-31 03:12:13 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 17, 2021):

Triaged into 2.0 with help wanted.

@DHowett commented on GitHub (Feb 17, 2021): Triaged into 2.0 with help wanted.
claunia commented 2026-01-31 03:12:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 17, 2021):

We've pretty broadly been using Area-User Interface for anything at the TerminalApp or WindowsTerminal layers, since there's not something more specific. I agree they don't really make sense for this kind of issue. I'll just stick it in UI for now.

@zadjii-msft commented on GitHub (Feb 17, 2021): We've pretty broadly been using `Area-User Interface` for anything at the `TerminalApp` or `WindowsTerminal` layers, since there's not something more specific. I agree they don't really make sense for this kind of issue. I'll just stick it in UI for now.
claunia commented 2026-01-31 03:12:14 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Mar 8, 2021):

I got this wrong last time... The merged fix means we should see this in 1.8, right? (Unless something is wrong and/or the fix is reverted)

@TBBle commented on GitHub (Mar 8, 2021): I got this wrong last time... The merged fix means we should see this in [1.8](https://github.com/microsoft/terminal/milestone/33), right? (Unless something is wrong and/or the fix is reverted)
claunia commented 2026-01-31 03:12:14 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 8, 2021):

I’d likely service this to 1.6 and 1.7, since it’s a low risk quality of life improvement :)

@DHowett commented on GitHub (Mar 8, 2021): I’d likely service this to 1.6 and 1.7, since it’s a low risk quality of life improvement :)
claunia commented 2026-01-31 03:12:14 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 14, 2021):

:tada:This issue was addressed in #9397, which has now been successfully released as Windows Terminal v1.7.1033.0.🎉

Handy links:

@ghost commented on GitHub (Apr 14, 2021): :tada:This issue was addressed in #9397, which has now been successfully released as `Windows Terminal v1.7.1033.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.7.1033.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 03:12:14 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 14, 2021):

:tada:This issue was addressed in #9397, which has now been successfully released as Windows Terminal Preview v1.8.1032.0.🎉

Handy links:

@ghost commented on GitHub (Apr 14, 2021): :tada:This issue was addressed in #9397, which has now been successfully released as `Windows Terminal Preview v1.8.1032.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.8.1032.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface good first issue Help Wanted Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#12316
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?