4 ms·
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 legib
by 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 agoDisclosure, 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 agoAnother 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 agoAs 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 agoI 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.
- jodrellblank 7y agoYou can shorten the flags in PowerShell simply by writing less of the flag - as long as you write enough to be unique and unambiguous, it will work. Get-ChildItem -R will map to Get-ChildItem -Recurse because there's nothing else it could be. But if it does clash, you get an error, so really when using this you press tab to demonstrate either that you have a uniquely short string and it autocompletes to the full name, or you press tab and find you don't have a uniquely short string and then tab through until it's the one you want and see the full name. There are short parameter aliases, e.g. -EA for -ErrorAction which are not unique substrings, and you can define those on your own cmdlets and advanced functions, but they seem less common. And it would be possible to enforce some of this with a style checker in your own scripts, because you can introspect cmdlets and advanced functions to see what parameters they support, and make sure your invocations always use the full parameter name. I don't know if any checkers do, but VS Code with the PowerShell extension will style check your scripts.