Every Bash bashing post has one thing in common; they ignore the fact that the Bash programming language features are meant to facilitate its purpose as a command interpreter, rather than as a general-purpose, interpreted programming language.
As per the Bash Info manual:
As a command interpreter, the shell provides the user interface to the rich set of GNU utilities. The programming language features allow these utilities to be combined.
If you don't spend a lot of time on the command line using Bash as a command interpreter for other programs/utilities while using anonymous pipes (or any other Unix IPC) for message passing, then maybe you don't need its programming language features anyways. Most people can get by with the built-in facilities Bash provides, along with simple sed, grep, awk, or perl one-liners without having to delve too deep.
Bash, like all shells, is largely misunderstood by those who complain that the programming features are bad, or don't work as expected, or are inefficient as compared to general-purpose, interpreted programming languages, while completely missing the point.
If you work on a Unix -like system to get real work done, properly knowing Bash, or any other shell, along with the built-in Unix IPC mechanisms and all the *utils suits (coreutils, binutils, util-linux, etc...) is almost a panacea. But, but, but...Bash doesn't have any data-structures and Bash arrays suck! Have you tried recutils?
Bash on its own isn't a panacea. Its the collection of tools that make Unix-like systems so powerful. If you want to take advantage of full power of Bash, you have to learn all the other parts that go with it. Only then will you understand the foolishness of comparing Bash to any general purpose, interpreted programming languages. They are not the same thing at all.
Your response is eloquent, and I am in complete agreement with the sentiments expressed. Your final paragraph, in particular, adds a much needed context to this discussion.
IMO Bash is a weak command interpreter. I got comfortable with it over the years and can read the man pages when needed. It's still a terrible experience that we, as the developer community, should push to improve.
There are no common bash/sh standards across multiple utilities, built-in facilities, different OSs. Utilities and their flags are named with "I feel like this letter today" approach. They mean different things on different operating systems. You need a lot of utilities and curl/wget/apt-get commands to add them (even for jq) to do any more or less serious setup on a medium-large project.
My choice is pwsh. It's easy to install on all major OSs. It's very well documented and the documentation is in a single place. It has clear flag names. It has text parsers for JSON, CSV, XML, HTML and other formats out of the box. It can connect to DBs out of the box. It has full access to the whole dotnet framework (gazillion of features). It's a first class citizen on Azure.
I'd like to preface this by saying that I am not proselytizing Bash, Unix, etc, or trying to disparage other systems or projects. That said, It seems like what you are comparing are disparate systems.
Bash, while POSIX compliant, is part of the GNU project, with tools that have many extensions on top of POSIX. Other similar projects have done the same and the extensions, of course, cannot be expected to all have the same command line switches since, as you say, there is no common standard beyond POSIX.
That said, the GNU project certainly has made attempts to standardize the command line switches among all the individual tools within their own project by adding long-options, while the short options that emulate the original Unix tools are the same as would be expected by the original tools, AFAIK.
What you describe as cohesiveness among the Microsoft tools should be expected by any project, and is largely true for all of them, respectively.
The inconsistencies you mention are mostly the result of disparate projects that have provided extensions to the POSIX standards.
I may be wrong about any of this, as I am not an expert historian of technology, and please correct me if I am. This is my understanding of the differences you mentioned.
I understand the historical reasons but it doesn't eliminate the fact that bash is a lot harder to learn and to maintain than pwsh once scripts get passed simple cd, ls, cat stuff.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Every Bash bashing post has one thing in common; they ignore the fact that the Bash programming language features are meant to facilitate its purpose as a command interpreter, rather than as a general-purpose, interpreted programming language.
As per the Bash Info manual:
If you don't spend a lot of time on the command line using Bash as a command interpreter for other programs/utilities while using anonymous pipes (or any other Unix IPC) for message passing, then maybe you don't need its programming language features anyways. Most people can get by with the built-in facilities Bash provides, along with simple sed, grep, awk, or perl one-liners without having to delve too deep.
Bash, like all shells, is largely misunderstood by those who complain that the programming features are bad, or don't work as expected, or are inefficient as compared to general-purpose, interpreted programming languages, while completely missing the point.
If you work on a Unix -like system to get real work done, properly knowing Bash, or any other shell, along with the built-in Unix IPC mechanisms and all the *utils suits (coreutils, binutils, util-linux, etc...) is almost a panacea. But, but, but...Bash doesn't have any data-structures and Bash arrays suck! Have you tried recutils?
Bash on its own isn't a panacea. Its the collection of tools that make Unix-like systems so powerful. If you want to take advantage of full power of Bash, you have to learn all the other parts that go with it. Only then will you understand the foolishness of comparing Bash to any general purpose, interpreted programming languages. They are not the same thing at all.
Your response is eloquent, and I am in complete agreement with the sentiments expressed. Your final paragraph, in particular, adds a much needed context to this discussion.
IMO Bash is a weak command interpreter. I got comfortable with it over the years and can read the man pages when needed. It's still a terrible experience that we, as the developer community, should push to improve.
There are no common bash/sh standards across multiple utilities, built-in facilities, different OSs. Utilities and their flags are named with "I feel like this letter today" approach. They mean different things on different operating systems. You need a lot of utilities and curl/wget/apt-get commands to add them (even for jq) to do any more or less serious setup on a medium-large project.
My choice is pwsh. It's easy to install on all major OSs. It's very well documented and the documentation is in a single place. It has clear flag names. It has text parsers for JSON, CSV, XML, HTML and other formats out of the box. It can connect to DBs out of the box. It has full access to the whole dotnet framework (gazillion of features). It's a first class citizen on Azure.
learn.microsoft.com/en-us/powershell/
I'd like to preface this by saying that I am not proselytizing Bash, Unix, etc, or trying to disparage other systems or projects. That said, It seems like what you are comparing are disparate systems.
Bash, while POSIX compliant, is part of the GNU project, with tools that have many extensions on top of POSIX. Other similar projects have done the same and the extensions, of course, cannot be expected to all have the same command line switches since, as you say, there is no common standard beyond POSIX.
That said, the GNU project certainly has made attempts to standardize the command line switches among all the individual tools within their own project by adding long-options, while the short options that emulate the original Unix tools are the same as would be expected by the original tools, AFAIK.
What you describe as cohesiveness among the Microsoft tools should be expected by any project, and is largely true for all of them, respectively.
The inconsistencies you mention are mostly the result of disparate projects that have provided extensions to the POSIX standards.
I may be wrong about any of this, as I am not an expert historian of technology, and please correct me if I am. This is my understanding of the differences you mentioned.
I understand the historical reasons but it doesn't eliminate the fact that bash is a lot harder to learn and to maintain than pwsh once scripts get passed simple cd, ls, cat stuff.