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.

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

Figure out aliases #929

Closed
andschwa opened this Issue Apr 28, 2016 · 64 comments

Comments

@andschwa
Member

andschwa commented Apr 28, 2016

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.

@andschwa andschwa added this to the GA milestone Apr 28, 2016

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa May 4, 2016

Member

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.

Member

andschwa commented May 4, 2016

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.

@joeyaiello

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello May 5, 2016

Member

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

joeyaiello commented 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:

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

@andschwa andschwa modified the milestones: v0.5.0, GA May 18, 2016

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa May 18, 2016

Member

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.

Member

andschwa commented 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

This comment has been minimized.

Show comment
Hide comment
@vors

vors May 18, 2016

Collaborator

@andschwa and default would be ....?

Collaborator

vors commented May 18, 2016

@andschwa and default would be ....?

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa May 18, 2016

Member

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

Member

andschwa commented May 18, 2016

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

@andschwa andschwa modified the milestones: v0.5.0, v0.6.0 Jun 8, 2016

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 8, 2016

Member

@BrucePay any updates on this?

Member

andschwa commented Jun 8, 2016

@BrucePay any updates on this?

@andschwa andschwa modified the milestones: Aug17, v0.6.0 Jun 8, 2016

@joeyaiello

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello Jun 13, 2016

Member

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.

Member

joeyaiello commented Jun 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vors

vors Jul 14, 2016

Collaborator

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.

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

This comment has been minimized.

Show comment
Hide comment
@lzybkr

lzybkr Jul 14, 2016

Member

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.

Member

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 added the cleanup label Jul 20, 2016

@joeyaiello joeyaiello modified the milestones: Future, 6.0.0-alpha.8 Jul 21, 2016

@joeyaiello

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello Jul 21, 2016

Member

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.

Member

joeyaiello commented Jul 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vors

vors Jul 27, 2016

Collaborator

Looks like we have a story, closing the issue.

Collaborator

vors commented Jul 27, 2016

Looks like we have a story, closing the issue.

@be5invis

This comment has been minimized.

Show comment
Hide comment
@be5invis

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

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

This comment has been minimized.

Show comment
Hide comment
@rkeithhill

rkeithhill Sep 5, 2016

Contributor

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.

Contributor

rkeithhill commented Sep 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@be5invis

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

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

This comment has been minimized.

Show comment
Hide comment
@ygra

ygra Sep 5, 2016

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

ygra commented Sep 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@be5invis

be5invis Sep 5, 2016

@ygra It is okay either.

be5invis commented Sep 5, 2016

@ygra It is okay either.

@Liturgist

This comment has been minimized.

Show comment
Hide comment
@Liturgist

Liturgist Sep 5, 2016

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.

Liturgist commented Sep 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Gaelan

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

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

This comment has been minimized.

Show comment
Hide comment
@rkeithhill

rkeithhill Sep 6, 2016

Contributor

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

Contributor

rkeithhill commented Sep 6, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Gaelan

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

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

This comment has been minimized.

Show comment
Hide comment
@ForNeVeR

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

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

@HemantMahawar HemantMahawar modified the milestones: 6.0.0, post-6.0.0 Oct 17, 2016

@xoofx

This comment has been minimized.

Show comment
Hide comment
@xoofx

xoofx 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?

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

This comment has been minimized.

Show comment
Hide comment
@vors

vors Dec 7, 2016

Collaborator

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

\ls ignores all aliases.

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.

@Liturgist

This comment has been minimized.

Show comment
Hide comment
@Liturgist

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

Liturgist commented 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

This comment has been minimized.

Show comment
Hide comment
@bgshacklett

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

bgshacklett commented 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 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

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello Feb 21, 2017

Member

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

Member

joeyaiello commented Feb 21, 2017

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

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Apr 18, 2017

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.

Member

SteveL-MSFT commented 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

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Apr 20, 2017

Member

Opened #3610 to capture secondary issue

Member

SteveL-MSFT commented Apr 20, 2017

Opened #3610 to capture secondary issue

@joeyaiello joeyaiello added this to Completed in Linux/Mac Usability May 2, 2017

@mklement0 mklement0 referenced this issue Jul 15, 2017

Closed

ignore #4263

@SteveL-MSFT SteveL-MSFT moved this from Completed to Done in Linux/Mac Usability Mar 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment