5 ms·

I feel anyone that really likes bash needs to have a concerted effort to learn how powershell works. It's got a lot of failings and MS has made deploying things

I feel anyone that really likes bash needs to have a concerted effort to learn how powershell works. It's got a lot of failings and MS has made deploying things and using them a pain but there's some genius in there and specifically the help system is categorically better. nushell is having a similar crack at it. a rising tide lifts all ships but bash is the mooring block.

Already__Taken 3y ago
I feel like anyone disagreeing with me that they won't swap to powershell every day from now on didn't really read my point and just clutched bash harder. I just said learn from it a bit, you don't have to live with it. It's not perfect, it won't replace your unix tools and bash because it never promised to, it's different. Python isn't trying really hard to be a better javascript.
taraparo 3y ago
I gave powershell a good try but I believe it sucks. too verbose and the syntax is too inconsistent. trying nushell next, it looks very promising.
- mr_mitm 3y ago
  There are short aliases for the most used Cmdlets and tab completion takes care of the rest. Type "Get-Process -" and then press CTRL-Space for a list of all arguments. That works with any Cmdlet. Impossible in bash. PowerShell is one of the best ideas to ever come out of Microsoft.
  - INGSOCIALITE 3y ago
    so one of the best ideas to ever come out of microsoft is an attempt to copy the functionality of bash and incorporate it into their .net ecosystem? i hardly think this is a compliment
    - Already__Taken 3y ago
      > why invent PowerShell, why not just use ksh or bash? I’m a long time Unix dev so that was my first instinct. I tried and failed. There is a core architectural difference between Unix and Windows. Linux is a file-oriented OS and Windows is an API-oriented OS. In Linux, if you can modify a file and run a process, you can manage anything. That is why awk, sed, and grep are management tools. At the time, nothing on Windows worked that way. Everything was behind an API which returned a structured object. That is why awk doesn’t work with WMI, sed doesn’t work with Active Directory, and grep doesn’t work against the registry. I had to invent a new tool that manipulated this environment. - Jeffrey Snover, Powershell Inventor. https://evrone.com/blog/jeffrey-snover-interview https://evrone.com/blog/jeffrey-snover-interview Literally designed not to copy bash.
    - steve1977 3y ago
      It’s not like bash (or UNIX shells in general) have invented command line interfaces…
  - rvdginste 3y ago
    I do not understand the "inconsistent" comment either. The "verbose" comment I can follow, but since you have tab-completion, it does not really matter that much. The Get-Help command is super useful, with the option to show examples (-Examples). Consistency is encouraged because every PowerShell command is the combination of a verb and a noun. The verbs are standardised and you can get a list of supported verbs using Get-Verb. Nouns are free to choose. There is also Get-Command which gives you a list of available commands in your current shell. You can import modules in the shell which will give you access to extra commands. Get-Command supports the parameters Module, Verb and Noun to filter commands. This allows you to fairly easily discover commands that might be usefull to you. The Get-Alias command will show you what aliases are defined in your shell. This can sometimes be confusing as some of the default aliases look like Linux/UNIX shell commands. Creating a PowerShell module is also not that hard. When defining a PowerShell command, it is for example very easy to limit the values for a certain parameter and that in turn hooks in into the completion functionality. The completion functionality is available out-of-the-box for every PowerShell command available, including the ones that you create yourself. My main OS is Linux, but I do work a lot with Windows systems (I develop in C#). I've used bash a lot, but I also learned PowerShell because that is simply the way to go on Windows systems. I like PowerShell, it has a lot of nice features and it is easy to work with. I find it a lot easier to program extra functionality in a PowerShell module compared to defining extra functions in bash. As a C# developer, PowerShell basically also gives me access to any C# class available by default in .NET. It is even simple to load a class from a third-party assembly, and even to compile C# code on the fly. In short, I can do whatever I want in PowerShell a lot easier than in Bash. Note that that does not mean that I no longer use Bash. It depends. My default shell on linux is bash. When I need a one-liner to do something, I will first reach for bash. It is only when I need a longer script that I will reach for PowerShell. For example, I need to read a json file, manipulate the json structures and write the data back out. That is something I would do in PowerShell. For a build script that is simply a sequence of steps, I would go for bash, even if it involves the use of jq for json for example. And obviously on Windows, my default shell is PowerShell. Even though I have used cygwin/ming before, I would not do that if I can avoid it... there is really no need to try to run bash or anything else on Windows when you have PowerShell.
chasil 3y ago
The POSIX shell, like the 1988 version of the Korn shell before it, is able to operate with minimal memory. In the case of ksh88, it was able to be compiled into a 64k text segment which was the maximum allowed on Microsoft XENIX running on an 80286. This is a place that Powershell cannot go.
chubot 3y ago
No this doesn't really make sense. Unix shell is "situated in" a bunch of native executables (grep, awk, ripgrep, etc.) and textual data, while PowerShell is VM-based, with bindings to Windows. If I were doing stuff with Windows registries, I might use PowerShell, but I don't. I use Unix. One is not a substitute for the other -- it's both the language AND the "bindings" that count. bash runs on Windows, and PowerShell runs on Linux, but you lose a lot of "enviroment" in both cases. I wrote about this distinction here - https://www.oilshell.org/blog/2023/06/ysh-design.html https://www.oilshell.org/blog/2023/06/ysh-design.html - Oils Is Exterior-First (Code, Text, and Structured Data) In those terms, I say PowerShell/nushell are "interior-first", while bash and OSH/YSH are "exterior-first". It makes a big difference when using them.
- forgotpwd16 3y ago
  Believe GP meant it as (not necessarily end up using it due to lacking the environment as you said) "check pwsh to see how things can be if you think bash is good". Worth noting, since you mention that pwsh has bindings only to Windows, that it's possible to make Linux-specific cmdlets/bindings in fashion similar to your YSH if understood it correctly (that is layering an object environment atop the text i/o of Linux commands).
- joiewjfoi2 3y ago
  In PowerShell, you can skip the need to master numerous DSLs for various data formats. Simply convert XML, JSON, YAML, etc., into objects and leverage built-in methods for manipulation. Bash, on the other hand, often requires you to familiarize yourself with tools like xmlstarlet and JQ, making the learning curve steeper. Additionally, PowerShell offers enhanced reliability since it primarily deals with structured data rather than raw text. Its consistency is also a notable advantage when compared to Bash, and the longer cmdlet names are offset by handy 2-3 letter abbreviations.
  - Already__Taken 3y ago
    I'd like to add my issue with the specific DSL approach isn't the learning curve, but the curve is a saw tooth pattern. If you don't keep using those DSL's weekly, in 2 years I dare you to write a valid one from memory. pwsh reinforces pretty much the same* thing every time it's used, the more you learn the more you can do with every command, even ones you haven't used yet. same subject to some base-level provided by the module. i.e. the active directory cmdlets have their own dsl inside -filter because it is a different thing. It's very analogous to `a = sql.cmd('SELECT ...').map(etc...)`. you can, you shouldn't, but maybe its fine. It's up to you.
__MatrixMan__ 3y ago
I really like bash. I tried to like powershell. Nushell feels much better than powershell to me as it's not overspecialized for integration with .Net and it gets many of the shell niceties right out of the box (vi mode, simultaneous history and file autocomplete). I think there will always be a place for something like bash pipelines, where the handoff is just a bunch of bits. Some work is all about discovering the structure of your data: you can't have tools that already know it. But that's not the majority of work these days. Having the handoff be just bits is an elegant solution to the tower-of-babel problem, but it would probably be ok if we spent more time in structured-mode and only leaned into that solution when it was specifically called for. The problem is that there's no intrinsic structure to data, just useful fictions. This makes structured-mode necessarily opinionated, which means that the ecosystem will always be fragmented: bash and zsh are friends. Powershell and nushell are rivals.
ndsipa_pomu 3y ago
Sorry, but powershell is not going to help me manage a bunch of linux machines and it doesn't come with all the usual gnu tools that I'm used to. I keep thinking that I should do more complicated stuff in a proper language, but BASH is just positioned as a perfect duck-tape kind of language - it ties together a bunch of other tools and I know it's going to already be there on any Linux machine that I deal with.
- tempodox 3y ago
  Duct tape. Ducks are glueless.
  - phkx 3y ago
    You might be surprised (as I was), when you consult Wikipedia on this topic: https://en.m.wikipedia.org/wiki/Duck_tape https://en.m.wikipedia.org/wiki/Duck_tape
    - fourthark 3y ago
      My whole life, I've been lied to. Thank you.
mgdlbp 3y ago
Some (topical) amusements: $ echo 25 | pwsh -c '$input-replace"\d",{2*"$_"}' 410 $ echo 25 | perl -pe 's/\d/2*$&/eg' 410 ``` PS> $temp:pwsh_out = 10000 PS> /bin/cat /tmp/pwsh_out 10000 ``` $ echo '''' PS> echo '''' ' ``` PS> $Y = { param($f) . { param($x) . $x $x } { param($y) . $f { param($x) . (. $y $y) $x }.GetNewClosure() }.GetNewClosure() } PS> $fac = & $Y { param($f) { param($n) $n -lt 2 ? 1 : $n * (. $f ($n - 1)) }.GetNewClosure() } PS> & $fac 5 120 ``` PS> gv -v|% m*d|% t* gv -v|% m*d|% t* PS> &($x={"&(`$x={$x})"}) &($x={"&(`$x={$x})"}) $ bash $ eval ${x='echo eval \${${x@A}}'} eval ${x='echo eval \${${x@A}}'} ``` bilingual pun, .ps1 .pl 1 1 {1} {1} end {1} sub {1} {end {1}} {sub {1}} &{end {1}} &{sub {1}} ``` awk -e 'BEGIN { printf "3\n" }' perl -e 'BEGIN { printf "3\n" }' ruby -e 'BEGIN { printf "3\n" }' pwsh -c 'BEGIN { printf "3\n" }' ``` $ time ...; time ...; .... real 0.00 ... real 0.00 ... real 0.03 ... real 0.22 ...
no_time 3y ago
Powershell for Linux fails the Litmus test of "Is it in the Debian community repo" This means it's either - Some "Open Core" bullshit with the secret sauce conveniently tucked away in some proprietary blob or restrictive license submodule - Has a build process so convoluted and mystery-meat-dependency filled it's not worth to bother with. - Has so many anti features it would require an extensive patchset (like ungoogled-chromium) to fix. So it might be interesting technology, but it's not something I'd deploy by default to every server and expect to work in 5 years time.
- eichin 3y ago
  https://github.com/PowerShell/PowerShell/blob/master/LICENSE.txt https://github.com/PowerShell/PowerShell/blob/master/LICENSE... is the MIT license. (Microsoft supplies debs directly which may reduce the motivation for Debian to do so.) Oh, heh, also https://github.com/PowerShell/PowerShell/blob/master/docs/building/linux.md https://github.com/PowerShell/PowerShell/blob/master/docs/bu... the build script is written in PowerShell, so there's a bootstrapping problem :-) (Debian has solved those before of course, but with community sentiment like the above maybe noone is motivated to bother.)
usrbinbash 3y ago
> 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. What?
- rvdginste 3y ago
  > 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…
  - usrbinbash 3y ago
    > 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.

Already__Taken 3y ago

I feel like anyone disagreeing with me that they won't swap to powershell every day from now on didn't really read my point and just clutched bash harder. I just said learn from it a bit, you don't have to live with it. It's not perfect, it won't replace your unix tools and bash because it never promised to, it's different. Python isn't trying really hard to be a better javascript.

taraparo 3y ago

I gave powershell a good try but I believe it sucks. too verbose and the syntax is too inconsistent. trying nushell next, it looks very promising.

mr_mitm 3y ago
There are short aliases for the most used Cmdlets and tab completion takes care of the rest. Type "Get-Process -" and then press CTRL-Space for a list of all arguments. That works with any Cmdlet. Impossible in bash. PowerShell is one of the best ideas to ever come out of Microsoft.
- INGSOCIALITE 3y ago
  so one of the best ideas to ever come out of microsoft is an attempt to copy the functionality of bash and incorporate it into their .net ecosystem? i hardly think this is a compliment
  - Already__Taken 3y ago
    > why invent PowerShell, why not just use ksh or bash? I’m a long time Unix dev so that was my first instinct. I tried and failed. There is a core architectural difference between Unix and Windows. Linux is a file-oriented OS and Windows is an API-oriented OS. In Linux, if you can modify a file and run a process, you can manage anything. That is why awk, sed, and grep are management tools. At the time, nothing on Windows worked that way. Everything was behind an API which returned a structured object. That is why awk doesn’t work with WMI, sed doesn’t work with Active Directory, and grep doesn’t work against the registry. I had to invent a new tool that manipulated this environment. - Jeffrey Snover, Powershell Inventor. https://evrone.com/blog/jeffrey-snover-interview https://evrone.com/blog/jeffrey-snover-interview Literally designed not to copy bash.
  - steve1977 3y ago
    It’s not like bash (or UNIX shells in general) have invented command line interfaces…
- rvdginste 3y ago
  I do not understand the "inconsistent" comment either. The "verbose" comment I can follow, but since you have tab-completion, it does not really matter that much. The Get-Help command is super useful, with the option to show examples (-Examples). Consistency is encouraged because every PowerShell command is the combination of a verb and a noun. The verbs are standardised and you can get a list of supported verbs using Get-Verb. Nouns are free to choose. There is also Get-Command which gives you a list of available commands in your current shell. You can import modules in the shell which will give you access to extra commands. Get-Command supports the parameters Module, Verb and Noun to filter commands. This allows you to fairly easily discover commands that might be usefull to you. The Get-Alias command will show you what aliases are defined in your shell. This can sometimes be confusing as some of the default aliases look like Linux/UNIX shell commands. Creating a PowerShell module is also not that hard. When defining a PowerShell command, it is for example very easy to limit the values for a certain parameter and that in turn hooks in into the completion functionality. The completion functionality is available out-of-the-box for every PowerShell command available, including the ones that you create yourself. My main OS is Linux, but I do work a lot with Windows systems (I develop in C#). I've used bash a lot, but I also learned PowerShell because that is simply the way to go on Windows systems. I like PowerShell, it has a lot of nice features and it is easy to work with. I find it a lot easier to program extra functionality in a PowerShell module compared to defining extra functions in bash. As a C# developer, PowerShell basically also gives me access to any C# class available by default in .NET. It is even simple to load a class from a third-party assembly, and even to compile C# code on the fly. In short, I can do whatever I want in PowerShell a lot easier than in Bash. Note that that does not mean that I no longer use Bash. It depends. My default shell on linux is bash. When I need a one-liner to do something, I will first reach for bash. It is only when I need a longer script that I will reach for PowerShell. For example, I need to read a json file, manipulate the json structures and write the data back out. That is something I would do in PowerShell. For a build script that is simply a sequence of steps, I would go for bash, even if it involves the use of jq for json for example. And obviously on Windows, my default shell is PowerShell. Even though I have used cygwin/ming before, I would not do that if I can avoid it... there is really no need to try to run bash or anything else on Windows when you have PowerShell.

chasil 3y ago

The POSIX shell, like the 1988 version of the Korn shell before it, is able to operate with minimal memory. In the case of ksh88, it was able to be compiled into a 64k text segment which was the maximum allowed on Microsoft XENIX running on an 80286. This is a place that Powershell cannot go.

chubot 3y ago

No this doesn't really make sense. Unix shell is "situated in" a bunch of native executables (grep, awk, ripgrep, etc.) and textual data, while PowerShell is VM-based, with bindings to Windows. If I were doing stuff with Windows registries, I might use PowerShell, but I don't. I use Unix. One is not a substitute for the other -- it's both the language AND the "bindings" that count. bash runs on Windows, and PowerShell runs on Linux, but you lose a lot of "enviroment" in both cases. I wrote about this distinction here - https://www.oilshell.org/blog/2023/06/ysh-design.html https://www.oilshell.org/blog/2023/06/ysh-design.html - Oils Is Exterior-First (Code, Text, and Structured Data) In those terms, I say PowerShell/nushell are "interior-first", while bash and OSH/YSH are "exterior-first". It makes a big difference when using them.

forgotpwd16 3y ago
Believe GP meant it as (not necessarily end up using it due to lacking the environment as you said) "check pwsh to see how things can be if you think bash is good". Worth noting, since you mention that pwsh has bindings only to Windows, that it's possible to make Linux-specific cmdlets/bindings in fashion similar to your YSH if understood it correctly (that is layering an object environment atop the text i/o of Linux commands).
joiewjfoi2 3y ago
In PowerShell, you can skip the need to master numerous DSLs for various data formats. Simply convert XML, JSON, YAML, etc., into objects and leverage built-in methods for manipulation. Bash, on the other hand, often requires you to familiarize yourself with tools like xmlstarlet and JQ, making the learning curve steeper. Additionally, PowerShell offers enhanced reliability since it primarily deals with structured data rather than raw text. Its consistency is also a notable advantage when compared to Bash, and the longer cmdlet names are offset by handy 2-3 letter abbreviations.
- Already__Taken 3y ago
  I'd like to add my issue with the specific DSL approach isn't the learning curve, but the curve is a saw tooth pattern. If you don't keep using those DSL's weekly, in 2 years I dare you to write a valid one from memory. pwsh reinforces pretty much the same* thing every time it's used, the more you learn the more you can do with every command, even ones you haven't used yet. same subject to some base-level provided by the module. i.e. the active directory cmdlets have their own dsl inside -filter because it is a different thing. It's very analogous to `a = sql.cmd('SELECT ...').map(etc...)`. you can, you shouldn't, but maybe its fine. It's up to you.

__MatrixMan__ 3y ago

I really like bash. I tried to like powershell. Nushell feels much better than powershell to me as it's not overspecialized for integration with .Net and it gets many of the shell niceties right out of the box (vi mode, simultaneous history and file autocomplete). I think there will always be a place for something like bash pipelines, where the handoff is just a bunch of bits. Some work is all about discovering the structure of your data: you can't have tools that already know it. But that's not the majority of work these days. Having the handoff be just bits is an elegant solution to the tower-of-babel problem, but it would probably be ok if we spent more time in structured-mode and only leaned into that solution when it was specifically called for. The problem is that there's no intrinsic structure to data, just useful fictions. This makes structured-mode necessarily opinionated, which means that the ecosystem will always be fragmented: bash and zsh are friends. Powershell and nushell are rivals.

ndsipa_pomu 3y ago

Sorry, but powershell is not going to help me manage a bunch of linux machines and it doesn't come with all the usual gnu tools that I'm used to. I keep thinking that I should do more complicated stuff in a proper language, but BASH is just positioned as a perfect duck-tape kind of language - it ties together a bunch of other tools and I know it's going to already be there on any Linux machine that I deal with.

tempodox 3y ago
Duct tape. Ducks are glueless.
- phkx 3y ago
  You might be surprised (as I was), when you consult Wikipedia on this topic: https://en.m.wikipedia.org/wiki/Duck_tape https://en.m.wikipedia.org/wiki/Duck_tape
  - fourthark 3y ago
    My whole life, I've been lied to. Thank you.

mgdlbp 3y ago

Some (topical) amusements: $ echo 25 | pwsh -c '$input-replace"\d",{2*"$_"}' 410 $ echo 25 | perl -pe 's/\d/2*$&/eg' 410 ``` PS> $temp:pwsh_out = 10000 PS> /bin/cat /tmp/pwsh_out 10000 ``` $ echo '''' PS> echo '''' ' ``` PS> $Y = { param($f) . { param($x) . $x $x } { param($y) . $f { param($x) . (. $y $y) $x }.GetNewClosure() }.GetNewClosure() } PS> $fac = & $Y { param($f) { param($n) $n -lt 2 ? 1 : $n * (. $f ($n - 1)) }.GetNewClosure() } PS> & $fac 5 120 ``` PS> gv -v|% m*d|% t* gv -v|% m*d|% t* PS> &($x={"&(`$x={$x})"}) &($x={"&(`$x={$x})"}) $ bash $ eval ${x='echo eval \${${x@A}}'} eval ${x='echo eval \${${x@A}}'} ``` bilingual pun, .ps1 .pl 1 1 {1} {1} end {1} sub {1} {end {1}} {sub {1}} &{end {1}} &{sub {1}} ``` awk -e 'BEGIN { printf "3\n" }' perl -e 'BEGIN { printf "3\n" }' ruby -e 'BEGIN { printf "3\n" }' pwsh -c 'BEGIN { printf "3\n" }' ``` $ time ...; time ...; .... real 0.00 ... real 0.00 ... real 0.03 ... real 0.22 ...

no_time 3y ago

Powershell for Linux fails the Litmus test of "Is it in the Debian community repo" This means it's either - Some "Open Core" bullshit with the secret sauce conveniently tucked away in some proprietary blob or restrictive license submodule - Has a build process so convoluted and mystery-meat-dependency filled it's not worth to bother with. - Has so many anti features it would require an extensive patchset (like ungoogled-chromium) to fix. So it might be interesting technology, but it's not something I'd deploy by default to every server and expect to work in 5 years time.

eichin 3y ago
https://github.com/PowerShell/PowerShell/blob/master/LICENSE.txt https://github.com/PowerShell/PowerShell/blob/master/LICENSE... is the MIT license. (Microsoft supplies debs directly which may reduce the motivation for Debian to do so.) Oh, heh, also https://github.com/PowerShell/PowerShell/blob/master/docs/building/linux.md https://github.com/PowerShell/PowerShell/blob/master/docs/bu... the build script is written in PowerShell, so there's a bootstrapping problem :-) (Debian has solved those before of course, but with community sentiment like the above maybe noone is motivated to bother.)

usrbinbash 3y ago

> 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. What?

rvdginste 3y ago
> 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…
- usrbinbash 3y ago
  > 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.