8000 Figure out aliases · Issue #929 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

Figure out aliases #929

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
andyleejordan opened this issue Apr 28, 2016 · 64 comments
Closed

Figure out aliases #929

andyleejordan opened this issue Apr 28, 2016 · 64 comments
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif OS-Linux OS-macOS Resolution-Fixed The issue is fixed. Usability (LEGACY) Helps filter issues that might be higher priority because they directly affect usability WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts
Milestone
6.0.0-NiceToHave

Comments

@andyleejordan
Copy link
Member

The PowerShell aliases that conflicted with Linux and OS X were removed in #786, specifically commit 7d9f439.

However, new discussion is happening on how to handle this better than just removing the aliases.
@andyleejordan andyleejordan added Usability (LEGACY) Helps filter issues that might be higher priority because they directly affect usability Issue-Meta an issue used to track multiple issues labels Apr 28, 2016
@andyleejordan andyleejordan added this to the GA milestone Apr 28, 2016
@andyleejordan
Copy link
Member Author
andyleejordan commented May 4, 2016 •
edited
Loading

This makes using rm, ls, etc. sucky, since globbing isn't performed:

> touch blah.tmp
> ls *.tmp                                                                                                          
ls: *.tmp: No such file or directory
> Get-ChildItem *.tmp

    Directory: /Users/andrew/src/PowerShell


Mode                LastWriteTime         Length Name                                                                                 
----                -------------         ------ ----                                                                                 
------           5/3/16   8:39 PM              0 blah.tmp

> rm *.tmp
rm: *.tmp: No such file or directory
> Remove-Item *.tmp
> Get-ChildItem *.tmp

Blah.

@andyleejordan andyleejordan mentioned this issue May 5, 2016
Closed
@joeyaiello
Copy link
Contributor

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).

@andyleejordan andyleejordan modified the milestones: v0.5.0, GA May 18, 2016
@andyleejordan
Copy link
Member Author

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
Copy link
Collaborator
vors commented May 18, 2016

@andschwa and default would be ....?

@andyleejordan
Copy link
Member Author

@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.

@andyleejordan andyleejordan modified the milestones: v0.5.0, v0.6.0 Jun 8, 2016
@andyleejordan
Copy link
Member Author

@BrucePay any updates on this?

@andyleejordan andyleejordan modified the milestones: Aug17, v0.6.0 Jun 8, 2016
@joeyaiello
Copy link
Contributor

Usability sync today reiterated that the aliases should go back in. (Piping to sort is yet another data point in having a totally broken PS experience.)

Leaving Bruce as an assignee to determine the best path forward with the above mitigations. @andschwa: we probably need someone else assigned to do the work to put the aliases back.

@vors
Copy link
Collaborator
vors commented Jul 14, 2016

I just had a conversation with @jpsnover and he is very clear that we are not putting aliases back. We should create inbox aliases.ps1 file and promote dot-sourcing it.

@lzybkr
Copy link
Contributor
lzybkr commented Jul 14, 2016

It's probably worth pointing out that ls in bash typically isn't simply ls, it's an alias with some default arguments, with maybe the most notable to output using color.

PowerShell aliases don't work at all like aliases in Linux, so we'd need to either define ls as a function, or enhance our aliases to work more like bash aliases.

It might also be worth spending some time analyzing modules in the gallery to see how many wouldn't work as is with the aliases removed - sort is especially concerning.

@vors vors modified the milestones: v0.8.0, Aug17 Jul 19, 2016
@joeyaiello joeyaiello modified the milestones: Future, 6.0.0-alpha.8 Jul 21, 2016
@joeyaiello
Copy link
Contributor

The aliases are not in today, and we should make sure for Aug17 we have a healthy discussion about the pros/cons of the alias situations for people to join into.

@vors vors removed the cleanup label Jul 27, 2016
@vors
Copy link
Collaborator
vors commented Jul 27, 2016

Looks like we have a story, closing the issue.

@be5invis
Copy link
be5invis commented Sep 5, 2016

@rkeithhill So let me clearify: For users want to use Powershell, they want types, right? However your native tools, like /bin/ls, cannot communicate with types. Therefore, switching to a typed shell, but without typed utils, the change is meaningless.

Therefore, typical Unix users may want to type the identical command, but get the typed result directly. So there is two options:

  1. Purpose a typed IPC protocol and tell Linus to update their tools — No, they wont’t, because it is purposed by their ENEMY, the EVIL LORD, the destroyer of the free world! They are going to “embrace extend and extinguish” us! or...
  2. Alias ls to a builtin with compatible parameters.

@rkeithhill
Copy link
Collaborator

For users want to use Powershell, they want types, right?

Eventually, they probably will. That said, I work with a number of devs I've started on PowerShell by merely selling them on using it with Git and Posh-Git (something CMD can't provide). They rarely pipeline anything at this point but I expect them to get there. That point is, the git.exe utility behaves under PowerShell just as it behaves under CMD. Easy transition.

To me, ls (like ps, grep, sed, awk, gcc, curl, etc) is just another native utility that any "shell" should be able to run. Now, if someone is ready for and wants the object emitting command for listing container contents, they can use Get-ChildItem or its alias gci. If they are of the bent that they will never use the native ls utility, then they can create a ls alias for Get-ChildItem in their profile.

BTW I don't think trying to make Get-ChildItem parameter compatible with ls is feasible. You'll get hung up pretty quickly with PowerShell parameters not being case-sensitive e.g. -c/-C, -d/-D, -i/-I. And PowerShell doesn't support parameter combining e.g. ls -rt. It's a reach and it violates PowerShell's Monad principle. A task like sorting would be done by a separate cmdlet (Sort-Object) and not by Get-ChildItem itself.

@be5invis
Copy link
be5invis commented Sep 5, 2016

@rkeithhill I am not going to make Get-ChildItem being compatible with ls. I am purposing another cmdlet, may be called UnixCompatibles-ls as its full name, and have a separate command parser which accepts GNU getopt flavor, instead of PowerShell.

@ygra
Copy link
ygra commented Sep 5, 2016 •
edited
Loading

@be5invis Isn't the easier option at that point a separate function that runs ls, passing it all its arguments, parses the output and creates objects from them? A completely separate command parser (along with completely separate command metadata, formatting for Get-Help, ...) is a bit overkill (apart from replicating much of PowerShell's internal workings in an incompatible manner.

There's always going to be two separate worlds here, one native, one typed. PowerShell already services both of them, by being able to execute native programs and cmdlets. I personally don't see any benefit (just a massive undertaking in development effort) in trying to add a layer above native commands that replicates their parameter metadata within PowerShell. Besides, what would you do about tar, or find (and lots of other programs), which AFAIK don't adhere to the GNU conventions. Implement yet another command parser, along with wrapper functions to call those? Note also that for a command parser to work, the native program's arguments have to be parsed within PowerShell and must not conflict with the language. Something that might be difficult with weird things like [.

@be5invis
Copy link
be5invis commented Sep 5, 2016

@ygra It is okay either.

@Liturgist
Copy link
Liturgist commented Sep 5, 2016 •
edited
Loading

For users want to use Powershell, they want types, right?

@be5invis, perhaps this is where a bit of disconnect occurs. No, they do not want types. The user wants to get their work, or play, done. The user knows that ls produces a stream of text.

Is UnixCompatibles a verb? Would this change the user's $PROFILE script permanently, or only for this session? I would not want Get-ChildItem to be ls compatible. Let ls be ls and do what ls does. It sounds like this would give the user a choice to replace ls with Get-ChildItem. That's fine. I am not sure that I want that, but for those who do, that's fine.

@Gaelan
Copy link
Gaelan commented Sep 6, 2016

@Liturgist I think what @be5invis means is that if people went to the trouble of switching to Powershell (as opposed to staying with Bash), it is because they want something Powershell provides. If people wanted a stream of text out of ls, (on Linux or macOS) they would never have bothered with Powershell.

@rkeithhill
Copy link
Collaborator

@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
Copy link
Gaelan commented Sep 6, 2016

@rkeithhill

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.

@ForNeVeR
Copy link
Contributor
ForNeVeR commented Sep 6, 2016

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 ;)

@kilasuit kilasuit mentioned this issue Sep 13, 2016
Closed
@HemantMahawar HemantMahawar modified the milestones: 6.0.0, post-6.0.0 Oct 17, 2016
@xoofx
Copy link
xoofx commented Nov 19, 2016

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 @joeyaiello
I'm not familiar with the whole PowersShell philosophy, but what could be wrong with such an approach?

@vors
Copy link
Collaborator
vors commented Dec 7, 2016

Actually, one more point for using a single-character escaping: bash already does it. https://twitter.com/climagic/status/806536501232340992

\ls ignores all aliases.

@joeyaiello joeyaiello mentioned this issue Dec 14, 2016
Closed
@joeyaiello joeyaiello mentioned this issue Jan 25, 2017
Closed
@Liturgist
Copy link

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
Copy link

@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.

@joeyaiello
Copy link
Contributor

@Liturgist: @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).

@lzybkr lzybkr mentioned this issue Mar 9, 2017
Closed
@SteveL-MSFT
Copy link
Member

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 SteveL-MSFT added the Resolution-Fixed The issue is fixed. label Apr 18, 2017
@SteveL-MSFT SteveL-MSFT mentioned this issue Apr 20, 2017
Closed
@SteveL-MSFT
Copy link
Member

Opened #3610 to capture secondary issue

@mklement0 mklement0 mentioned this issue Jul 15, 2017
Closed
@swernli swernli mentioned this issue Jan 24, 2021
Closed
@iSazonov iSazonov mentioned this issue Jul 18, 2024
Closed
21 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif OS-Linux OS-macOS Resolution-Fixed The issue is fixed. Usability (LEGACY) Helps filter issues that might be higher priority because they directly affect usability WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts
Projects
None yet
Milestone
6.0.0-NiceToHave
Development

No branches or pull requests
0