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

PowerShell shell window - can't change default settings #10845

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

Originally created by @JustinWebDev on GitHub (Oct 1, 2020).

Environment

Windows 10 x64 V2004

Windows build number:  10.0.19041.0
Windows Terminal version (if applicable):

Any other software?

Steps to reproduce

1 - Launch PS from the Start menu
2 - on the window control menu (Alt+Space), select Defaults cmd
3 - change a default, e.g., Colors tab, Opacity, OK
4 - open a new PS window - the change is not seen/persisted

Expected behavior

Any changes made via Defaults will be seen in the next instance of a PS window.

Actual behavior

The changes are not seen in the next instance of a PS window.

NOTE 1: you can change defaults via the Properties cmd! (but not Defaults cmd)
NOTE 2: I tested this on another V2004 machine and got an inexplicable error after trying to commit defaults changes:

Error Updating Shortcut

Unable to modify the shortcut:
C:\Users\justin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk.
Check to make sure it has not been deleted or renamed.

OK

Originally created by @JustinWebDev on GitHub (Oct 1, 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! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment Windows 10 x64 V2004 ```none Windows build number: 10.0.19041.0 Windows Terminal version (if applicable): Any other software? ``` # Steps to reproduce 1 - Launch PS from the Start menu 2 - on the window control menu (Alt+Space), select Defaults cmd 3 - change a default, e.g., Colors tab, Opacity, OK 4 - open a new PS window - the change is not seen/persisted # Expected behavior Any changes made via Defaults will be seen in the next instance of a PS window. # Actual behavior The changes are not seen in the next instance of a PS window. NOTE 1: you can change defaults via the Properties cmd! (but not Defaults cmd) NOTE 2: I tested this on another V2004 machine and got an inexplicable error after trying to commit defaults changes: --------------------------- Error Updating Shortcut --------------------------- Unable to modify the shortcut: C:\Users\justin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk. Check to make sure it has not been deleted or renamed. --------------------------- OK ---------------------------
claunia added the Issue-QuestionNeeds-TriageNeeds-Tag-FixResolution-Answered labels 2026-01-31 02:31:48 +00:00
claunia commented 2026-01-31 02:31:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 1, 2020):

Unfortunately, that's just how the vintage console properties are designed. The console properties are composed of settings from various different sources, including the "defaults", and also the "shortcut settings". When opening a new console window, it first applies the default settings to the window, then also applies the shortcut settings on top of the defaults. When you open the "defaults", then you're changing only the "default" settings, the settings that apply to all windows, not just the current window. If you want to change the PowerShell settings, you'll want to open the "properties" menu entry. That'll only affect the PowerShell shortcut, as well as update the settings for the current window.

@zadjii-msft commented on GitHub (Oct 1, 2020): Unfortunately, that's just how the vintage console properties are designed. The console properties are composed of settings from various different sources, including the "defaults", and also the "shortcut settings". When opening a new console window, it first applies the default settings to the window, then also applies the shortcut settings on top of the defaults. When you open the "defaults", then you're changing only the "default" settings, the settings that apply to all windows, not just the current window. If you want to change the PowerShell settings, you'll want to open the "properties" menu entry. That'll only affect the PowerShell shortcut, as well as update the settings for the current window.
claunia commented 2026-01-31 02:31:50 +00:00
Author
Owner
Copy Link

@JustinWebDev commented on GitHub (Oct 2, 2020):

Strange system. Sounds like a poor design. I'm using a PS window, not CMD prompt. The user could not know the of the masking magic behind the scenes and thus know how to work it. Not user-friendly or intuitive. Window makes the two consoles appear to be different 'things', thus the user thinks about them also as different 'things'.

Anyway, thanks for the info.

@JustinWebDev commented on GitHub (Oct 2, 2020): Strange system. Sounds like a poor design. I'm using a PS window, not CMD prompt. The user could not know the of the masking magic behind the scenes and thus know how to work it. Not user-friendly or intuitive. Window makes the two consoles appear to be different 'things', thus the user thinks about them also as different 'things'. Anyway, thanks for the info.
claunia commented 2026-01-31 02:31:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 2, 2020):

Unfortunately, this is the settings model the Windows Console has had since 1995 (or earlier; Windows 3.1 had "pif" files that specified console settings per-application!) and every time we change it, all of the people who have built up decades of comfort around this model complain.

We've tried.

That's one of the reasons we're working on Windows Terminal: it has a sane and reasonable and consolidated settings model, where every customizable thing happens in one place 😄

@DHowett commented on GitHub (Oct 2, 2020): Unfortunately, this is the settings model the Windows Console has had since 1995 (or earlier; Windows 3.1 had "pif" files that specified console settings per-application!) and every time we change it, all of the people who have built up decades of comfort around this model complain. We've tried. That's one of the reasons we're working on Windows Terminal: it has a sane and reasonable and consolidated settings model, where every customizable thing happens in _one place_ :smile:
claunia commented 2026-01-31 02:31:50 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Oct 3, 2020):

Strange system. Sounds like a poor design. I'm using a PS window, not CMD prompt.

They don't look like different windows to me. The settings for PowerShell use a different default color scheme and font, and PowerShell uses low-level console I/O in order to implement its own command-line editor. CMD and other simple REPLs (read-eval-print loop CLIs, such as the python.exe shell) rely on the console's builtin cooked read, which provides rudimentary line editing, input aliases, input history and input-control hooks (e.g. tab completion), but doesn't support a way to configure different line-editor modes (e.g. emacs mode) or persist input history across console sessions.

The user could not know the of the masking magic behind the scenes and thus know how to work it. Not user-friendly or intuitive.

This is a significant user interface, user experience, and user + developer education problem for console applications that, as far as I know, was never seriously addressed for over 20 years between 1993 and 2015 (from Windows NT 3.1 until Windows 10). I had to stitch together the details on my own regarding "defaults" vs "properties" and how this relates to the default settings in "HKCU\Console", settings (properties) based on the initial window title in subkeys of "HKCU\Console", console settings stored in shell links [MS-SHLLINK], and the lpTitle field and STARTF_TITLEISLINKNAME flag in the process STARTUPINFO.

@eryksun commented on GitHub (Oct 3, 2020): > Strange system. Sounds like a poor design. I'm using a PS window, not CMD prompt. They don't look like different windows to me. The settings for PowerShell use a different default color scheme and font, and PowerShell uses low-level console I/O in order to implement its own command-line editor. CMD and other simple REPLs (read-eval-print loop CLIs, such as the python.exe shell) rely on the console's builtin cooked read, which provides rudimentary line editing, input aliases, input history and input-control hooks (e.g. tab completion), but doesn't support a way to configure different line-editor modes (e.g. emacs mode) or persist input history across console sessions. > The user could not know the of the masking magic behind the scenes and thus know how to work it. Not user-friendly or intuitive. This is a significant user interface, user experience, and user + developer education problem for console applications that, as far as I know, was never seriously addressed for over 20 years between 1993 and 2015 (from Windows NT 3.1 until Windows 10). I had to stitch together the details on my own regarding "defaults" vs "properties" and how this relates to the default settings in "HKCU\Console", settings (properties) based on the initial window title in subkeys of "HKCU\Console", console settings stored in [shell links](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/e6b432b4-5a49-4826-9c25-e28695e8dd0c) [MS-SHLLINK], and the `lpTitle` field and `STARTF_TITLEISLINKNAME` flag in the process [`STARTUPINFO`](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-startupinfow).
claunia commented 2026-01-31 02:31:50 +00:00
Author
Owner
Copy Link

@JustinWebDev commented on GitHub (Oct 5, 2020):

These look different to me. Sure, they are both plain-looking windows, but too different to be confused, nor is one just a makeover of the the other.
cmd_vs_ps

Not trying to argue, just saying they are different enough to be known as different 'things' to the user.

@JustinWebDev commented on GitHub (Oct 5, 2020): These look different to me. Sure, they are both plain-looking windows, but too different to be confused, nor is one just a makeover of the the other. ![cmd_vs_ps](https://user-images.githubusercontent.com/40804543/95134195-0e9a1f80-0728-11eb-8579-89d88de13a83.PNG) Not trying to argue, just saying they are different enough to be known as different 'things' to the user.
claunia commented 2026-01-31 02:31:50 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Oct 6, 2020):

These look different to me. Sure, they are both plain-looking windows, but too different to be confused, nor is one just a makeover of the the other.

It's just a different icon and initial window title -- based on the shell link or application that allocated the console session. But it's still the same weird 'menu' tacked onto the control menu, which looks like something hacked together for testing in the early 90s that never got replaced with a better UI.

The properties/defaults dialogs should at least have a fixed frame at the top or bottom that informs the user where settings are being stored in the registry or shell link, including a URL link to a page that explains in detail how console window properties are stored, loaded, and applied as well as a table of supported registry values. The console team has written a couple of blog posts that touch on these topics -- but not in as much detail as I would want. This information should be consolidated into the console documentation instead of scattered about on the web.

@eryksun commented on GitHub (Oct 6, 2020): > These look different to me. Sure, they are both plain-looking windows, but too different to be confused, nor is one just a makeover of the the other. It's just a different icon and initial window title -- based on the shell link or application that allocated the console session. But it's still the same weird 'menu' tacked onto the control menu, which looks like something hacked together for testing in the early 90s that never got replaced with a better UI. The properties/defaults dialogs should at least have a fixed frame at the top or bottom that informs the user where settings are being stored in the registry or shell link, including a URL link to a page that explains in detail how console window properties are stored, loaded, and applied as well as a table of supported registry values. The console team has written a couple of blog posts that touch on these topics -- but not in as much detail as I would want. This information should be consolidated into the console documentation instead of scattered about on the web.
claunia commented 2026-01-31 02:31:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 7, 2020):

Yea, the two windows definitely look different to the casual user of the console, even when they are fundamentally the same application. The Console properties have always been a bit of a mess, since before I was even born. Every time we try changing them, we end up with more bugs and broken users than we did before, which is why we're not touching them any more. Hence part of the reason why we built the Windows Terminal 😜

@zadjii-msft commented on GitHub (Oct 7, 2020): Yea, the two windows definitely look different to the casual user of the console, even when they are fundamentally the same application. The Console properties have always been a bit of a mess, since before I was even born. Every time we try changing them, we end up with more bugs and broken users than we did before, which is why we're _not touching them any more_. Hence part of the reason why we built the Windows Terminal 😜
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 Issue-Question Needs-Tag-Fix Needs-Triage Resolution-Answered
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#10845
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?