You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usability sync generally agrees that the interactive experience sucks without the aliases. What we don't agree on is what alternatives should be offered to users who want to use the native binaries by default. Some options that have been floated include:
An environment variable to turn off all the aliases that collide with *nix binaries
A single character (like ^) that automatically falls into the native PATH
Tell people they have to bash -c (many said this is too many characters to be usable)
Tell people that they have to provide the full path (this experience technically already works, but it's very poor)
Side suggestion: Leverage the "hinting subsystem" to tell people that they may have wanted to use the native command if they use parameter sets that match patterns against the native *nix binaries. This can still only work when the command fails (rm -e, for instance, would not fail).
I think this is something we want to figure out sooner rather than later, so I've moved it to v0.5.0. In my opinion, a PowerShell setting to switch modes is the best first step.
Gaelan Steele (@Gaelan) So I shouldn't use PowerShell if I need to use gcc or git? What's wrong with letting folks decide if they want text (ls) or objects (gci)? There are more reasons to use PowerShell than just its OO nature - powerful as it is. Heck I'd rather use PowerShell just for its C/C# like control flow statements (vs if/fi and switch case/esac) and its proper type system (where numbers are numbers and not strings).
So I shouldn't use PowerShell if I need to use gcc or git?
On a *nix system, if users just wanted to use the shell for gcc or git they wouldn't bother with PowerShell, because the shell that came with their OS does that perfectly well.
Heck I'd rather use PowerShell just for its C/C# like control flow statements (vs if/fi and switch case/esac)
Perhaps if someone was already using PowerShell they would prefer it because of that, but I doubt that someone would install PS just for that.
its proper type system (where numbers are numbers and not strings)
/bin/ls doesn't work with the type system either: if I run ls -l, I will get file sizes as a string instead of a proper PS number.
I feel like the reasons a new user would switch to PS on *nix largely revolve around the OO and the type system. We should make it as easy as possible for new users to get started with PS–if I saw something about PS, tried to check it out, only to discover that I needed to relearn everything about the command line to use it, I would probably be much less likely to bother with learning it than if I could fire up PS, type ls and immediately see the type system in action. Yes, I could use aliases, but if I'm just trying out PS in a few spare minutes I'm unlikely to want to do much configuration before I jump in and start playing around.
On a *nix system, if users just wanted to use the shell for gcc or git they wouldn't bother with PowerShell, because the shell that came with their OS does that perfectly well.
Perhaps if someone was already using PowerShell they would prefer it because of that, but I doubt that someone would install PS just for that.
Sorry, but I strongly disagree. As a Linux user, I want to use PowerShell instead of shell that came with my OS. For everything. Because it's awesome, you know :)
Heck, I am even packaging PowerShell for NixOS right now just to use it for everything.
Please consider that our target users are not only native Unix users who accidentally use Windows+PowerShell, but also Windows users who accidentally use Unix+PowerShell ;)
Reacted by Kexy Biscuit a.k.a. るる, Ryan Yates, Keith Hill and Yupei Liu
Reacted by Flavien MICHALECZEK, Ryan Yates, eFiggy and Mike
A single character (like ^) that automatically falls into the native PATH
I would also prefer to keep aliases compatible across OS whenever they are valid on these platforms and use an escape character (like ^ls) to get an implicit access to native commands, as suggested by Joey Aiello (@joeyaiello)
I'm not familiar with the whole PowersShell philosophy, but what could be wrong with such an approach?
Liturgist Currently, the WSL is a very separate environment from PowerShell. The commands are not callable from a PowerShell session. Additionally, this would likely be considered a regression by many current Windows PowerShell users as many scripts would break if they received the output from, say, GNU ls rather than ls -> Get-ChildItem. While the use of aliases was never recommended in scripts, the fact remains that they have been used and breakage would cause difficulty for many people.
Liturgist: Brian G. Shacklett (@bgshacklett) is on right here. The problem is not that something happens when you type ls, the question is what parameters you expect while using that, and whether or not the output emitted is consumable in an object-oriented fashion by other PowerShell cmdlets (i.e. ls | Where-Object Name -like *foo* won't work if you're using the WSL ls).
The original issue with conflicting aliases with native cmds has been addressed. If there is a need to have the capability to add back popular Windows PowerShell aliases, that should be a separate issue.
Activity
andyleejordan commentedon May 4, 2016
This makes using
rm,ls, etc. sucky, since globbing isn't performed:Blah.
joeyaiello commentedon May 5, 2016
Usability sync generally agrees that the interactive experience sucks without the aliases. What we don't agree on is what alternatives should be offered to users who want to use the native binaries by default. Some options that have been floated include:
^) that automatically falls into the native PATHbash -c(many said this is too many characters to be usable)rm -e, for instance, would not fail).andyleejordan commentedon May 18, 2016
I think this is something we want to figure out sooner rather than later, so I've moved it to v0.5.0. In my opinion, a PowerShell setting to switch modes is the best first step.
vors commentedon May 18, 2016
Andy Jordan (@andschwa) and default would be ....?
andyleejordan commentedon May 18, 2016
sergei (@vors) my personal opinion: the PowerShell aliases enabled; because you're running PowerShell.
Eventually we're going to want a first-time startup "getting started" guide for PowerShell anyway, and would state that this is an available setting.
64 remaining items
rkeithhill commentedon Sep 6, 2016
Gaelan Steele (@Gaelan) So I shouldn't use PowerShell if I need to use gcc or git? What's wrong with letting folks decide if they want text (ls) or objects (gci)? There are more reasons to use PowerShell than just its OO nature - powerful as it is. Heck I'd rather use PowerShell just for its C/C# like control flow statements (vs if/fi and switch case/esac) and its proper type system (where numbers are numbers and not strings).
Gaelan commentedon Sep 6, 2016
Keith Hill (@rkeithhill)
On a *nix system, if users just wanted to use the shell for gcc or git they wouldn't bother with PowerShell, because the shell that came with their OS does that perfectly well.
Perhaps if someone was already using PowerShell they would prefer it because of that, but I doubt that someone would install PS just for that.
/bin/lsdoesn't work with the type system either: if I runls -l, I will get file sizes as a string instead of a proper PS number.I feel like the reasons a new user would switch to PS on *nix largely revolve around the OO and the type system. We should make it as easy as possible for new users to get started with PS–if I saw something about PS, tried to check it out, only to discover that I needed to relearn everything about the command line to use it, I would probably be much less likely to bother with learning it than if I could fire up PS, type
lsand immediately see the type system in action. Yes, I could use aliases, but if I'm just trying out PS in a few spare minutes I'm unlikely to want to do much configuration before I jump in and start playing around.ForNeVeR commentedon Sep 6, 2016
Sorry, but I strongly disagree. As a Linux user, I want to use PowerShell instead of shell that came with my OS. For everything. Because it's awesome, you know :)
Heck, I am even packaging PowerShell for NixOS right now just to use it for everything.
Please consider that our target users are not only native Unix users who accidentally use Windows+PowerShell, but also Windows users who accidentally use Unix+PowerShell ;)
xoofx commentedon Nov 19, 2016
I would also prefer to keep aliases compatible across OS whenever they are valid on these platforms and use an escape character (like
^ls) to get an implicit access to native commands, as suggested by Joey Aiello (@joeyaiello)I'm not familiar with the whole PowersShell philosophy, but what could be wrong with such an approach?
vors commentedon Dec 7, 2016
Actually, one more point for using a single-character escaping: bash already does it. https://twitter.com/climagic/status/806536501232340992
\lsignores all aliases.Liturgist commentedon Feb 20, 2017
Is the answer to aliases solved by enabling WSL (Windows Subsystem for Linux)? This will provide native sed, awk, ls, etc. commands in a bash shell.
While it is still beta code for Windows 10, surely it will be coming and made available in Server 2016 and 2012.
bgshacklett commentedon Feb 21, 2017
Liturgist Currently, the WSL is a very separate environment from PowerShell. The commands are not callable from a PowerShell session. Additionally, this would likely be considered a regression by many current Windows PowerShell users as many scripts would break if they received the output from, say, GNU
lsrather thanls -> Get-ChildItem. While the use of aliases was never recommended in scripts, the fact remains that they have been used and breakage would cause difficulty for many people.joeyaiello commentedon Feb 21, 2017
Liturgist: Brian G. Shacklett (@bgshacklett) is on right here. The problem is not that something happens when you type
ls, the question is what parameters you expect while using that, and whether or not the output emitted is consumable in an object-oriented fashion by other PowerShell cmdlets (i.e.ls | Where-Object Name -like *foo*won't work if you're using the WSLls).SteveL-MSFT commentedon Apr 18, 2017
The original issue with conflicting aliases with native cmds has been addressed. If there is a need to have the capability to add back popular Windows PowerShell aliases, that should be a separate issue.
SteveL-MSFT commentedon Apr 20, 2017
Opened #3610 to capture secondary issue