> needs to have a concerted effort to learn how powershell works.
Unless I am a windows administrator, my question is: Why should I?
There is literally ZERO reason for me as an administrator *nix machines to ever touch pwsh.
> but there's some genius in there
I am sure there is. But it's buried very well under layers upon layers of deep integration with windows and .NET, the attempt to shoehorn a character-based shell into working with objects somehow, and a syntax that rivals enterprise java in its verbosity.
> nd specifically the help system is categorically better
Is it? Why? Man pages, infopages, and `apropos` all exist. Individual man pages may be bad, but the system as a whole is solid. It also isn't dependent on the shell. All these mechanisms are just normal programs that can be executed by any shell.
> a rising tide lifts all ships but bash is the mooring block.
> But it's buried very well under layers upon layers of deep integration with windows and .NET, the attempt to shoehorn a character-based shell into working with objects somehow, and a syntax that rivals enterprise java in its verbosity.
You do know it runs on Windows, Mac (amd64/arm64) and Linux(amd64/arm)? There is definitely integration with .net, which is available for the same platforms. The integration with .net is part of its power for me.
Verbosity can increase readability.
> Is it? Why? Man pages, infopages, and `apropos` all exist. Individual man pages may be bad, but the system as a whole is solid. It also isn't dependent on the shell. All these mechanisms are just normal programs that can be executed by any shell.
You will not loose those tools and their man pages when using PowerShell. He is referring to the documentation of all helper functions defined within PowerShell. When you create a helper function in Bash, how do you document it and what tool can you use to consult that documentation?
Bash does not have named parameters for its functions, let alone metadata on them…
> You do know it runs on Windows, Mac (amd64/arm64) and Linux(amd64/arm)?
"Runs somewhere" and "Is useful there" are two very different things.
> Verbosity can increase readability.
And usually it hinders readability. If anyone disagrees, he may explain how enterprise Java is more readable than Python, Go or Rust code. And yes, I do consider Rust more readable than Enterprise Java.
And that's when we talk about PROGRAMMING LANGUAGES. We are, however, talking about SHELL LANGUAGES. Other than most PLs, shells are in fact written more than they are read, so yes, "typeability" and terseness is a feature in shells, not a problem. And before anyone says "autocomplete": If a shell requires autocomplete to be somewhat useable, I will look for another shell.
> You will not loose those tools and their man pages when using PowerShell.
Did I say I will? That line was in reply to the statement that "the help system is categorically better", a statement I happen to disagree with.
> He is referring to the documentation of all helper functions defined within PowerShell.
And I am refering to the documentation that is defined within the shell environment on *NIX terminals.
> When you create a helper function in Bash, how do you document it and what tool can you use to consult that documentation?
Off the top of my head:
- I can embed a `-h --help` flag directly in the script
- I can write a manpage and use it via `man NAME`
- A manpage is also discoverable by the `apropos` program
- If it's a builtin I can use bashs builtin `help PATTERN`
- I can write an entry for the `info` program
So yeah, I'd say there are more than enough methods, all of which are well established in the shell ecosystem, and work seamlessly with it.
> Bash does not have named parameters for its functions, let alone metadata on them…
Which would truly be a bummer if bash needed named parameters. Since it doesn't, I don't see why this would be an advantage. If I want named params for a shell script, I can write it in python.
So to defend the help points because it's interesting;
You literally cannot write a powershell function that doesn't support get-help <myfunc>. So that's already a win it's self documenting because of the type system. The better the developer uses the type system the better the generated help. Sticking to the standard format for help (which is generated for you again from tab-complete) enhances this help document further. Finally, adding a url(https://learn.microsoft.com/en-us/powershell/scripting/devel...) lets the builtin update-help download new help, independent of publishing a new cmdlet version. So authors can fix typos/wording or add translations or examples without having to issue a release.
I've been doing linux sysadmin at least a decade, literally never heard of apropos before. I disagree that leaving this up to the authors is beneficial. When I'm lost and confused consistency is key.
Because this it builtin by default, it's worth it for the authors to add.
A lot of odd pwsh syntax is precisely because it's a proper language in a shell format, and just by that nature there's some ugly stuff in there. < > is already used so -le -gt -lte -eq exists.
Because it's a typed structured language, you will never have it without tab-complete, it's just designed in. That's the answer to maintain readability and typeabillity they chose. Bash just didn't choose readability. they both have alias' for common things. You may disagree but I would say that's just like refusing to use dot-sourcing or import statements in any language. It's there to use.
Your final remark about python I feel just adds to my point of don't bother with bash. I'd almost insist a shell that does even less then pwsh/bash and forced you to use a proper language sooner would be better.
In this example, it doesn't matter in what order I put the values for source, dest or the boolean to ignore headers, as they are all named by the associated command line flag.
I believe this is clean Bash code and clean PowerShell code, and a script with a certain complexity. The functions inside the Bash script are documented using comments, the ones inside the PowerShell script are documented using "structured comments" (similar to javadoc/xmldoc/...). The parameters of the functions inside the PowerShell script also contain metadata which is used to provide completion on the commandline and similar functionality as the command line flags you demonstrated.
I just learned about 'getopts' in Bash, which you can actually also use to implement parameters to a Bash function. So what you are showing on a script level, can also be applied for functions. Did not know about that.
Still, not saying PowerShell is better than Bash in a Linux context, but it seems a lot of Linux users have a gut reaction to right out reject PowerShell. I think it does have some advantages for certain use cases, like more complex scripts, a cross-platform context, ... and of course, for someone with a .NET background it's easier to program more complex things with it.
Unless I am a windows administrator, my question is: Why should I?
There is literally ZERO reason for me as an administrator *nix machines to ever touch pwsh.
> but there's some genius in there
I am sure there is. But it's buried very well under layers upon layers of deep integration with windows and .NET, the attempt to shoehorn a character-based shell into working with objects somehow, and a syntax that rivals enterprise java in its verbosity.
> nd specifically the help system is categorically better
Is it? Why? Man pages, infopages, and `apropos` all exist. Individual man pages may be bad, but the system as a whole is solid. It also isn't dependent on the shell. All these mechanisms are just normal programs that can be executed by any shell.
> a rising tide lifts all ships but bash is the mooring block.
What?