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

CLI: Support tilde (~) shortcut to user profile in -d argument #10374

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

Originally created by @Ariane-B on GitHub (Aug 28, 2020).

Description of the new feature/enhancement

Currently, if I want to open a Terminal tab that starts in a specific folder in my user profile, I have to write -d C:\Users\MyUser\somefolder. I wish I could use the shortcut ~ to say "that's my user folder".

Proposed technical implementation details (optional)

For example, I could use the command wt -d ~/somefolder, which would be equivalent to wt -d C:\Users\MyUser\somefolder.

Originally created by @Ariane-B on GitHub (Aug 28, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement Currently, if I want to open a Terminal tab that starts in a specific folder in my user profile, I have to write `-d C:\Users\MyUser\somefolder`. I wish I could use the shortcut ~ to say "that's my user folder". <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. --> For example, I could use the command `wt -d ~/somefolder`, which would be equivalent to `wt -d C:\Users\MyUser\somefolder`.
claunia commented 2026-01-31 02:19:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 4, 2020):

Hey, this is a good idea.

@DHowett commented on GitHub (Sep 4, 2020): Hey, this is a good idea.
claunia commented 2026-01-31 02:19:53 +00:00
Author
Owner
Copy Link

@kaifee-haque commented on GitHub (Sep 5, 2020):

Looks like we can already open a Terminal tab that starts in C:\Users\MyUser\somefolder by using the command wt -d somefolder.

@kaifee-haque commented on GitHub (Sep 5, 2020): Looks like we can already open a Terminal tab that starts in `C:\Users\MyUser\somefolder` by using the command `wt -d somefolder`.
claunia commented 2026-01-31 02:19:53 +00:00
Author
Owner
Copy Link

@Ariane-B commented on GitHub (Sep 5, 2020):

That is cool, but it would be nice if it were clearer in the docs, because I was convinced the root for the -d parameter was "My PC" or "C:".

@Ariane-B commented on GitHub (Sep 5, 2020): That is cool, but it would be nice if it were clearer in the docs, because I was convinced the root for the -d parameter was "My PC" or "C:".
claunia commented 2026-01-31 02:19:53 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 5, 2020):

As with all Windows applications, the root of any relative directory parameter is the current working directory.

This means that if you run wt -d x from C:\a it will start a profile in C:\a\x.

We opted not to document behavior that is either incidental or not a deviation from other applications :)

@DHowett commented on GitHub (Sep 5, 2020): As with all Windows applications, the root of any relative directory parameter is the current working directory. This means that if you run `wt -d x` from `C:\a` it will start a profile in `C:\a\x`. We opted not to document behavior that is either incidental or not a deviation from other applications :)
claunia commented 2026-01-31 02:19:53 +00:00
Author
Owner
Copy Link

@Ariane-B commented on GitHub (Sep 5, 2020):

Oh, that's what you meant! I thought you meant that the -d argument was always based on the current user's directory. If the base is the current command line directory, then my suggestion stands.

What you describe makes perfect sense. But in the context of a startup shortcut, for example, the directory it runs from is not immediately obvious. Add in general, I don't think it's entirely safe to assume everyone will always be running the shell command line from their home folder.

Also, there might be cases where a single shell file will be run by several users, who'd want the starting directory to be in -their- user folder.

Finally, some people like to specify things when they're insecure about what the automatic behaviour would be. Simply mentioning the thing is sometimes simpler than researching the default behaviour, after all.

For all these reasons, I think I'll stand behind my suggestion.

@Ariane-B commented on GitHub (Sep 5, 2020): Oh, that's what you meant! I thought you meant that the -d argument was always based on the current user's directory. If the base is the current command line directory, then my suggestion stands. What you describe makes perfect sense. But in the context of a startup shortcut, for example, the directory it runs from is not immediately obvious. Add in general, I don't think it's entirely safe to assume everyone will always be running the shell command line from their home folder. Also, there might be cases where a single shell file will be run by several users, who'd want the starting directory to be in -their- user folder. Finally, some people like to specify things when they're insecure about what the automatic behaviour would be. Simply mentioning the thing is sometimes simpler than researching the default behaviour, after all. For all these reasons, I think I'll stand behind my suggestion.
claunia commented 2026-01-31 02:19:53 +00:00
Author
Owner
Copy Link

@KnapSac commented on GitHub (Sep 9, 2020):

Can I pick this up?

@KnapSac commented on GitHub (Sep 9, 2020): Can I pick this up?
claunia commented 2026-01-31 02:19:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 9, 2020):

I'm a little worried about this request. Treating ~ as %USERPROFILE%seems like a good idea, but what if someone wants to use ~ as their WSL ~ directory, not their Windows one?

IMO I'd want that question answered before we ship this.

@zadjii-msft commented on GitHub (Sep 9, 2020): I'm a little worried about this request. Treating `~` as `%USERPROFILE%`seems like a good idea, but what if someone wants to use `~` as their WSL `~` directory, not their Windows one? IMO I'd want that question answered before we ship this.
claunia commented 2026-01-31 02:19:54 +00:00
Author
Owner
Copy Link

@KnapSac commented on GitHub (Sep 9, 2020):

Maybe that should depend on the profile you're targeting? For instance, when opening a WSL profile we could treat ~ as their WSL ~ directory, and for other profiles we could treat it as %USERPROFILE%.

@KnapSac commented on GitHub (Sep 9, 2020): Maybe that should depend on the profile you're targeting? For instance, when opening a WSL profile we could treat ```~``` as their WSL ```~``` directory, and for other profiles we could treat it as ```%USERPROFILE%```.
claunia commented 2026-01-31 02:19:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 9, 2020):

Ah but how do we know for certain if they"re targeting a WSL profile? The user could make other WSL profiles other than the dynamically generated ones. In that case, we wouldn't have the source data to tell use that the profile is a WSL profile. Maybe we need to add another wslDistro property that identifies which distro the profile is for. That might play into #592 (et al) as well.

/cc @DHowett since we've been having discussion about this in the past

@zadjii-msft commented on GitHub (Sep 9, 2020): Ah but how do we know for certain if they"re targeting a WSL profile? The user could make other WSL profiles other than the dynamically generated ones. In that case, we wouldn't have the `source` data to tell use that the profile is a WSL profile. Maybe we need to add another `wslDistro` property that identifies which distro the profile is for. That might play into #592 (et al) as well. /cc @DHowett since we've been having discussion about this in the past
claunia commented 2026-01-31 02:19:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 3, 2022):

We might have low key done this unintentionally.

#12437

If we find that we were unable to mangle ~ into the user's WSL commandline, then we will re-evaluate that startingDirectory as %USERPROFILE%, which is at least something sensible, if albeit not what they wanted.

I mean, it makes sense. ~ isn't a valid path for a Windows process, but it is for a WSL process. We've already got some magic to make this work for WSL processes. Now we've got different magic to make it work for anything other than wsl.exe. If we see a startingDirectory of ~, we're gonna treat it like %USERPROFILE% now.

This should be in Terminal v1.12.10393.0, Terminal Preview v1.13.10395.0

@zadjii-msft commented on GitHub (Mar 3, 2022): We might have low key done this unintentionally. #12437 > If we find that we were unable to mangle ~ into the user's WSL commandline, then we will re-evaluate that startingDirectory as %USERPROFILE%, which is at least something sensible, if albeit not what they wanted. I mean, it makes sense. `~` isn't a valid path for a Windows process, but it is for a WSL process. We've already got some magic to make this work for WSL processes. Now we've got different magic to make it work for anything other than wsl.exe. If we see a startingDirectory of `~`, we're gonna treat it like `%USERPROFILE%` now. This should be in `Terminal v1.12.10393.0`, `Terminal Preview v1.13.10395.0`
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-Commandline good first issue Help Wanted Issue-Task Priority-2 Product-Terminal Resolution-Fix-Available
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#10374
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?