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

Proposal: Evolution of startingDirectory #13666

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

Originally created by @zadjii-msft on GitHub (Apr 29, 2021).

What if we had something like:

{
    "ignoreStartingDirectories": bool,
}

as a global setting? Then we'd just never use the startingDirectory for a profile, and always use the CWD of the Terminal. That seems like a big hammer, but there might be folks who are all setting "startingDirectory": "." for all their profiles, where this would be an easier solution.

Alternatively:
What about wt --cwd C:\foo new-tab? That would make sure that the Terminal's CWD is set to C:\foo, not just the CWD of that tab.
That would work better for things like the context menu, that might want subsequent tabs to open in the same CWD, but poorly for wt -w 0 --cwd C:\foo nt

Originally created by @zadjii-msft on GitHub (Apr 29, 2021). What if we had something like: ```json { "ignoreStartingDirectories": bool, } ``` as a global setting? Then we'd just _never_ use the `startingDirectory` for a profile, and always use the CWD of the Terminal. That seems like a big hammer, but there might be folks who are all setting `"startingDirectory": "."` for all their profiles, where this would be an easier solution. Alternatively: What about `wt --cwd C:\foo new-tab`? That would make sure that the Terminal's CWD is set to `C:\foo`, not just the CWD of that tab. That would work _better_ for things like the context menu, that might want subsequent tabs to open in the same CWD, but poorly for `wt -w 0 --cwd C:\foo nt`
claunia commented 2026-01-31 03:48:51 +00:00
Author
Owner
Copy Link

@jerblack commented on GitHub (Jun 4, 2021):

Far more important to me would be an option where you don't interfere in the startup at all and just open my WSL terminals in ~. The fact that you havce a checkbox option in your settings UI that causes Terminal to open in /mnt/c/Windows/system32 but nothing at all to say "just stay out of the way and don't interfere with the Ubuntu default behavior" is insane to me.

@jerblack commented on GitHub (Jun 4, 2021): Far more important to me would be an option where you don't interfere in the startup at all and just open my WSL terminals in ~. The fact that you havce a checkbox option in your settings UI that causes Terminal to open in /mnt/c/Windows/system32 but nothing at all to say "just stay out of the way and don't interfere with the Ubuntu default behavior" is insane to me.
claunia commented 2026-01-31 03:48:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 4, 2021):

just stay out of the way and don't interfere with the Ubuntu default behavior

Bad news: Opening in whatever directory you run it from is the WSL launcher's default behavior. That checkbox is, quite literally, a paraphrased version of "Do the default behavior for the thing you are launching."

@DHowett commented on GitHub (Jun 4, 2021): > just stay out of the way and don't interfere with the Ubuntu default behavior Bad news: Opening in whatever directory you run it from is the WSL launcher's default behavior. That checkbox is, quite literally, a paraphrased version of "Do the default behavior for the thing you are launching."
claunia commented 2026-01-31 03:48:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 4, 2021):

(That checkbox is, to put it another way, "do not interfere in the startup at all.")

@DHowett commented on GitHub (Jun 4, 2021): (That checkbox is, to put it another way, "do not interfere in the startup at all.")
claunia commented 2026-01-31 03:48:52 +00:00
Author
Owner
Copy Link

@jerblack commented on GitHub (Jun 5, 2021):

To recap:

  • SSH or open console on most any GUI-less install, get dropped into ~ for logged in user by default.
  • Open terminal from almost any Linux desktop, get dropped into ~ for logged in user by default.
  • Open default WSL prompt Start Menu, get dropped into ~ for logged in user by default.
  • Open WSL through terminal from Start Menu, get forced into home folder for Windows user, not ~

Feedback: don't do that.
MSFT: What is this foreign and unexpected behavior you are requesting?

@jerblack commented on GitHub (Jun 5, 2021): To recap: - SSH or open console on most any GUI-less install, get dropped into ~ for logged in user by default. - Open terminal from almost any Linux desktop, get dropped into ~ for logged in user by default. - Open default WSL prompt Start Menu, get dropped into ~ for logged in user by default. - Open WSL through terminal from Start Menu, get forced into home folder for Windows user, not ~ Feedback: don't do that. MSFT: What is this foreign and unexpected behavior you are requesting?
claunia commented 2026-01-31 03:48:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 5, 2021):

There is no need for you to be curt with us or misrepresent our position.

@DHowett commented on GitHub (Jun 5, 2021): There is no need for you to be curt with us or misrepresent our position.
claunia commented 2026-01-31 03:48:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 9, 2021):

Oh my god I must have totally forgotten about #4637, because that's the same thing. That's on me.

/dup #4637

@zadjii-msft commented on GitHub (Dec 9, 2021): Oh my god I must have totally forgotten about #4637, because that's the same thing. That's on me. /dup #4637
claunia commented 2026-01-31 03:48:53 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 9, 2021):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Dec 9, 2021): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
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-Settings Issue-Feature Issue-Question Product-Terminal Resolution-Duplicate
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#13666
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?