5 ms·

I've never been able to quite put my finger on why I loath Powershell so much, but yes, I think this is part of it. I also dislike how verbose commands are (and

I've never been able to quite put my finger on why I loath Powershell so much, but yes, I think this is part of it. I also dislike how verbose commands are (and the shortened versions are not safe to use cross-platform), and the weird Pascal-Kebab-Casing-Hybrid of idiomatic Powershell also irks me. Still, there is something else... I just don't like it.

Ididntdothis 7y ago
Same here. In theory it could be a great tool and often is but it just doesn’t feel right. I would much prefer if they had done an interpreted version of C# and added the cmdlets to that.
- GordonS 7y ago
  Yep, Powershell is actually really powerful, and even cross-platform with Powershell Core... I wonder if anyone has tried to large-scale "re-skin" it, aliasing command names to make them less verbose and more obvious?
  - Ididntdothis 7y ago
    PowerShell Core is quite nice. I actually used it on my Mac to crunch through a few image files and it worked really well compared to my failed attempts of doing the same with bash.
pfranz 7y ago
I could never get used to PowerShell, but in languages like Bash I /really/ like using short flags in the REPL (for speed), but long flags in scripts (for legibility). Unfortunately, this means there's a higher bar to learn and I've never seen a way to enforce this (I rarely see others use this convention). I hoped PowerShell would address this or the ISE (maybe great autocomplete negates the need for short flags?)
- guhidalg 7y ago
  Disclosure, I work at MSFT and I have a special place in my heart for PowerShell. PowerShell provides incredibly flexible syntax, enough that it can satisfy most styles of script writing. The practice you describe (short names in CLI and long names in scripts) can be achieved. A couple of things to note about how PS binds arguments to function calls: 1. If you omit names, the parameters are bound positionally. 1. If you use names, you do not have to type the full name. It is sufficient to type an unambiguous prefix of the parameter name and the most appropriate parameter will be selected. So for example in the CLI you can just to `ls -r -fi .csproj` whereas in a script you can use the fully self-documenting `ls -Recurse -Filter .csproj`. Hope this helps!
  - partdavid 7y ago
    Another commenter complained about short aliases not being safe cross-platform, and this is an example. In powershell core on Unix systems 'ls' is the 'ls' command, not an alias for Get-ChildItem. So I would say the correct "long" version for your example is 'Get-ChildItem -Recurse -Filter .csproj'. In my opinion this is a non-issue (at least when comparing powershell to other shells) because the number of cases where you have to worry about bash command 'X' actually being different from your system (even across varieties of Unix-y OSes) is much greater than this handful of convenience aliases in powershell.
  - GordonS 7y ago
    As I mentioned though, it's not "safe" to use the shortened aliases cross-platform - I've been bitten by that multiple times before, from memory including `ls` and `wget`.
- partdavid 7y ago
  I like your style! IMO scripts and documented examples should use long options. You can shorten flags in powershell, fyi. I made the switch to powershell from bash recently (after 20+ years with bash and its antecedents). I didn't love the aesthetic of powershell to begin with, but the advantages are pretty convincing. Short aliases are "unsafe" across platforms but this is a non-issue since this situation is so much worse for bash, and at least you have long canonical names for things when it counts (i.e. writing scripts). How much bash code has been written over the years to figure out which code path to follow based on which flavor of awk you have or safeguard your function from user aliases for rm? Thinking there is a "higher bar" to learn powershell vs bash is purely bias due to what you already know. I'm not saying everyone needs powershell and I don't think it's great for everyone but it definitely isn't harder to learn than bash. It's much more discoverable (even if only thanks to actual types and 'gm'). I haven't used ISE at all.

Ididntdothis 7y ago

Same here. In theory it could be a great tool and often is but it just doesn’t feel right. I would much prefer if they had done an interpreted version of C# and added the cmdlets to that.

GordonS 7y ago
Yep, Powershell is actually really powerful, and even cross-platform with Powershell Core... I wonder if anyone has tried to large-scale "re-skin" it, aliasing command names to make them less verbose and more obvious?
- Ididntdothis 7y ago
  PowerShell Core is quite nice. I actually used it on my Mac to crunch through a few image files and it worked really well compared to my failed attempts of doing the same with bash.

pfranz 7y ago

I could never get used to PowerShell, but in languages like Bash I /really/ like using short flags in the REPL (for speed), but long flags in scripts (for legibility). Unfortunately, this means there's a higher bar to learn and I've never seen a way to enforce this (I rarely see others use this convention). I hoped PowerShell would address this or the ISE (maybe great autocomplete negates the need for short flags?)

guhidalg 7y ago
Disclosure, I work at MSFT and I have a special place in my heart for PowerShell. PowerShell provides incredibly flexible syntax, enough that it can satisfy most styles of script writing. The practice you describe (short names in CLI and long names in scripts) can be achieved. A couple of things to note about how PS binds arguments to function calls: 1. If you omit names, the parameters are bound positionally. 1. If you use names, you do not have to type the full name. It is sufficient to type an unambiguous prefix of the parameter name and the most appropriate parameter will be selected. So for example in the CLI you can just to `ls -r -fi .csproj` whereas in a script you can use the fully self-documenting `ls -Recurse -Filter .csproj`. Hope this helps!
- partdavid 7y ago
  Another commenter complained about short aliases not being safe cross-platform, and this is an example. In powershell core on Unix systems 'ls' is the 'ls' command, not an alias for Get-ChildItem. So I would say the correct "long" version for your example is 'Get-ChildItem -Recurse -Filter .csproj'. In my opinion this is a non-issue (at least when comparing powershell to other shells) because the number of cases where you have to worry about bash command 'X' actually being different from your system (even across varieties of Unix-y OSes) is much greater than this handful of convenience aliases in powershell.
- GordonS 7y ago
  As I mentioned though, it's not "safe" to use the shortened aliases cross-platform - I've been bitten by that multiple times before, from memory including `ls` and `wget`.
partdavid 7y ago
I like your style! IMO scripts and documented examples should use long options. You can shorten flags in powershell, fyi. I made the switch to powershell from bash recently (after 20+ years with bash and its antecedents). I didn't love the aesthetic of powershell to begin with, but the advantages are pretty convincing. Short aliases are "unsafe" across platforms but this is a non-issue since this situation is so much worse for bash, and at least you have long canonical names for things when it counts (i.e. writing scripts). How much bash code has been written over the years to figure out which code path to follow based on which flavor of awk you have or safeguard your function from user aliases for rm? Thinking there is a "higher bar" to learn powershell vs bash is purely bias due to what you already know. I'm not saying everyone needs powershell and I don't think it's great for everyone but it definitely isn't harder to learn than bash. It's much more discoverable (even if only thanks to actual types and 'gm'). I haven't used ISE at all.