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

Feature Suggestion: *nix compatability mode for non-wsl shells #980

New Issue
Closed
opened 2026-01-30 22:12:58 +00:00 by claunia · 4 comments
claunia commented 2026-01-30 22:12:58 +00:00
Owner
Copy Link

Originally created by @trondhindenes on GitHub (May 11, 2019).

On linux-based terminals / WSL this works:

mycommand &&\
myothercommand &&\
mythirdcommand

and

FOO=BAR mycommand

In "native" windows shells such as cmd.exe and powershell.exe it doesnt.
I'm thinking that Terminal is the perfect place to introduce some kind of optional compatability mode to help bring windows-native shells closed to how linux-based shells work:

  • Intercept backslashes prepended by spaces and double "and" symbols (visual line break)
  • Intercept && patterns (command chaining)
  • Intercept key=valuepatterns at the start of a command (local env vars)

This would allow things like pasting "unix-style" scriptblocks into the terminal, such as

docker run &&\
-p 80:80 &&\
nginx

Which can be found all over the internets, without having to switch to WSL.

Originally created by @trondhindenes on GitHub (May 11, 2019). On linux-based terminals / WSL this works: ```bash mycommand &&\ myothercommand &&\ mythirdcommand ``` and ```bash FOO=BAR mycommand ``` In "native" windows shells such as cmd.exe and powershell.exe it doesnt. I'm thinking that Terminal is the perfect place to introduce some kind of optional compatability mode to help bring windows-native shells closed to how linux-based shells work: - Intercept backslashes prepended by spaces and double "and" symbols (visual line break) - Intercept `&&` patterns (command chaining) - Intercept `key=value`patterns at the start of a command (local env vars) This would allow things like pasting "unix-style" scriptblocks into the terminal, such as ``` docker run &&\ -p 80:80 &&\ nginx ``` Which can be found all over the internets, without having to switch to WSL.
claunia added the Resolution-AnsweredProduct-Cmd.exe labels 2026-01-30 22:12:58 +00:00
claunia commented 2026-01-30 22:12:59 +00:00
Author
Owner
Copy Link

@Nek- commented on GitHub (May 11, 2019):

You mean having bash everywhere? This will be a no-go in the 2 couple of years. Sorry.

@Nek- commented on GitHub (May 11, 2019): You mean having bash everywhere? This will be a no-go in the 2 couple of years. Sorry.
claunia commented 2026-01-30 22:12:59 +00:00
Author
Owner
Copy Link

@parkovski commented on GitHub (May 11, 2019):

  • Don't want to get into all the details, but it is almost impossible to determine what is shell program text at the terminal level. May be easier if you're just preprocessing pasted text, but still really hacky and error prone. If you wanted to do this, it belongs in a shell.
  • Cmd.exe is not going to be updated for reasons the official devs have outlined in several places here - it's basically a decades long jenga game at this point and overloading the backslash or equals sign would be a disaster.
  • Backslash is not a very good escape character in a Windows shell. I wish it was. I and probably many others hate that it's the path separator, but it's too late to change it now. If you only care about the line separator behavior, again, this makes it quite a bit less tricky, but also more limited.

So as for the &&, || operators, there's currently an open PowerShell issue. I hope they add this because a shell really should have them.

I also like the env X=Y idea. I have a function called with in my PowerShell profile (here, although I'm sure it's pretty buggy) so I can kind of fake this behavior. It'd be nice to have official support for this. This does really need to be a shell feature though.

# In bash:
FOO=1 some_command --args
# In pwsh with my profile:
with FOO=1 some_command --args
@parkovski commented on GitHub (May 11, 2019): - Don't want to get into all the details, but it is almost impossible to determine what is shell program text at the terminal level. May be easier if you're just preprocessing pasted text, but still _really_ hacky and error prone. If you wanted to do this, it belongs in a shell. - Cmd.exe is not going to be updated for reasons the official devs have outlined in several places here - it's basically a decades long jenga game at this point and overloading the backslash or equals sign would be a disaster. - Backslash is not a very good escape character in a Windows shell. I wish it was. I and probably many others hate that it's the path separator, but it's too late to change it now. If you _only_ care about the line separator behavior, again, this makes it quite a bit less tricky, but also more limited. So as for the `&&`, `||` operators, there's currently [an open PowerShell issue](https://github.com/PowerShell/PowerShell/issues/3241). I hope they add this because a shell really should have them. I also like the env `X=Y` idea. I have a function called `with` in my PowerShell profile ([here, although I'm sure it's pretty buggy](https://github.com/parkovski/config/blob/master/shared/lib/with.ps1)) so I can kind of fake this behavior. It'd be nice to have official support for this. This does really need to be a shell feature though. ```shell # In bash: FOO=1 some_command --args # In pwsh with my profile: with FOO=1 some_command --args ```
claunia commented 2026-01-30 22:12:59 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (May 11, 2019):

On linux-based terminals / WSL this works:

mycommand &&\
myothercommand &&\
mythirdcommand

This has always worked in cmd, in exactly the same way. For example:

c> REM conditionally start service, only if we can stop it.
c:> net stop fooservice && net start fooservice

and

FOO=BAR mycommand

The compatibility risks far outweigh the effort to just use set FOO=BAR.

This would allow things like pasting "unix-style" scriptblocks into the terminal, such as

docker run &&\
-p 80:80 &&\
nginx

Which can be found all over the internets, without having to switch to WSL.

You know, you don't have to "switch to WSL" in this case:

C:\> wsl docker run && ... etc..

Just prefixing a linux command from within the window shell will invoke in WSL context, and even return the values back to the windows context. Tired of complaining about the lack of grep in cmd?

c:\> cat c:\temp\foo.txt | wsl grep -i "hello"
hello, there
c:\>

I'd argue this is far more useful.

@oising commented on GitHub (May 11, 2019): > On linux-based terminals / WSL this works: > > ```shell > mycommand &&\ > myothercommand &&\ > mythirdcommand > ``` This has always worked in cmd, in exactly the same way. For example: c\> REM conditionally start service, only if we can stop it. c:\> net stop fooservice && net start fooservice > and > > ```shell > FOO=BAR mycommand > ``` The compatibility risks far outweigh the effort to just use `set FOO=BAR.` > This would allow things like pasting "unix-style" scriptblocks into the terminal, such as > > ``` > docker run &&\ > -p 80:80 &&\ > nginx > ``` > > Which can be found all over the internets, without having to switch to WSL. You know, you don't have to "switch to WSL" in this case: ``` C:\> wsl docker run && ... etc.. ``` Just prefixing a linux command from within the window shell will invoke in WSL context, and even return the values back to the windows context. Tired of complaining about the lack of grep in cmd? ``` c:\> cat c:\temp\foo.txt | wsl grep -i "hello" hello, there c:\> ``` I'd argue this is far more useful.
claunia commented 2026-01-30 22:12:59 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 11, 2019):

Thanks for the suggestion; however, @parkovski said it best:

  • Don't want to get into all the details, but it is almost impossible to determine what is shell program text at the terminal level. May be easier if you're just preprocessing pasted text, but still really hacky and error prone. If you wanted to do this, it belongs in a shell.

  • Cmd.exe is not going to be updated for reasons the official devs have outlined in several places here - it's basically a decades long jenga game at this point and overloading the backslash or equals sign would be a disaster.

These are both extremely correct assertions, and are the reason it's out of scope for this project and for this team. As a terminal--an application whose sole job it is to get text mode applications onto the screen and give them input--we don't have control fundamentally over how those applications work. Sorry!

@DHowett-MSFT commented on GitHub (May 11, 2019): Thanks for the suggestion; however, @parkovski said it best: > * Don't want to get into all the details, but it is almost impossible to determine what is shell program text at the terminal level. May be easier if you're just preprocessing pasted text, but still _really_ hacky and error prone. If you wanted to do this, it belongs in a shell. > > * Cmd.exe is not going to be updated for reasons the official devs have outlined in several places here - it's basically a decades long jenga game at this point and overloading the backslash or equals sign would be a disaster. These are both extremely correct assertions, and are the reason it's out of scope for this project and for this team. As a terminal--an application whose sole job it is to get text mode applications onto the screen and give them input--we don't have control fundamentally over how those applications _work_. Sorry!
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 Product-Cmd.exe 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#980
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?