Why Microsoft open sourced PowerShell and ported it to Linux

Can someone explain to me why? The outputs are objects and that is cool for scripts, but the fact that every small thing is its own cmdlet is super annoying. I can do everything in Linux if I know 10 commands. In PS I would always have to look up everything.

the fact that every small thing is its own cmdlet is super annoying. I can do everything in Linux if I know 10 commands
That sounds more like a clash of cultures than a real problem. In Linux you need to know 10 options and possibly subcommands for each command. Naturally the same concept has different flags, and the same flag has different meanings in different commands. Is that really better?
If I recall the Verb-Noun idea is supposed to make it clear what is happening, take a look through stuff like the approved verbs for defining cmdlets. There's aliases and stuff for sure for example I think ls is an aliases for Get-ChildItem in PowerShell.
It's supposed to make it so you don't necessarily need to look things up, need to do something to an item? Well you can Copy, Remove, Rename, Move etc, and while yeah that's a super basic example that you know the equivalent linux commands for, the concept is supposed to apply everywhere. Now, whether or not people follow the guidelines is probably another story.
I don't really hate shell scripting, feel like they all have their place, complex stuff though is nicer in straight PowerShell than bash IMO, but I'm fine using either.
- The aliases are good for the most part, but curl is an alias for Invoke-Webrequest, even though the two are incompatible.
Same here. I keep hearing that Powershell is so good, but I have to look up every little thing. It's all too specific and you can't remember it all.
Maybe you're a bit more used to the linux stuff then.
https://lemm.ee/comment/20786033 -- I think powershell's syntax is far better than bash's. It feels more modern.

I wouldn't go that far

As much as I hate windows powershell is actually decent.
- The problem is that on Linux it competes with bash and dozens of way better terminals.
  
  We're not talking terminals, though, are we? You can run pwsh in dozens of terminals. As a shell, it's... Very decent.
  
  I've been a Linux sysadmin for decades and Windows for the year 8 years or so. I started using Windows with an air of contempt, and still do. I hate myself for saying this, but Powershell is better than bash. Bash is very limited if you consider only bash. For bash to be useful you need the entire GNU suite with grep, cut, awk etc.
  
  That's like saying that your car is very limited because you need cylinders, spark plugs, oil filters...
  Well yeah, you do and typically that comes with the car, just like grep comes with bash
  
  But that's almost never how a system is configured. The entire point is that bash, zsh, fish etc. can make use of those utilities. You don't need bash trying to reinvent everything. You don't want that. That's why changing shells is generally painless and a strength, not a weakness.
  
  But on windows it makes sense to have the stuff built in, because those utilities are not on windows.
  
  Yes, that's the point of the shell. It's the glue for all the little tools.
  
  So you’re saying Powershell doesn’t uphold Unix Philosophy and thus shouldn’t be used?
  
  PowerShell actually does uphold the Linux philosophy pretty well. Most functions are in modules that can be imported, disabled or swapped out as appropriate.
  
  PS looking good
  
  I hate to say it, but powershell is better than bash.

I'll take your word for it. I could never wrap my head around PowerShell back when I still had a Windows install. Whenever I could, I would use either the DOS prompt or WSL/Ubuntu. I may not be great at Bash or DOS but at least I'm not having to resort to cargo culting to do anything. Probably a sign I'm getting old.

there are other shells that have all the nice powershell things without the weird stuff (at least for not windows people), like nushell

although I wouldn't be surprised if powershell was the thing that started the trend of better shells

Random question for everyone from a bit of a noob. When I'm using Powershell (PS) in windows I can start to type the name of a built in command or one I have added to PATH and then press tab to auto complete the command. That part works the same in my Linux terminal.
What I can also do after I have typed that command into PS is start to type a file name that exists in the directory that PS is working in and then press tab to auto complete or cycle through the files that match and it even formats the name of the file correctly (meaning if it has a space in the name it will wrap the name in quotes so that it is understood by the commands they are fed to). This auto completing of file names even works on files that were created after the PS window was opened. This functionality doesn't seem to exist by default in any distro I have used. Is it possible to do this in the Linux terminal?
Although I have done some distro hopping, most of them have ultimately been Ubuntu based. Currently running Kubuntu.
- By default Bash will auto complete filenames (In fact, in 25 years, i can't remember the time bash didn't). Sometimes, there are autocomplete 'helpers' that try to be overly smart (ie, only autocompleting files that have the right extension, which can interfere when you are doing creative things with mis-named file). However, in Powershell, cmdlets declare a type for each of their parameters, which lets powershell autocomplete the right type of item, which can make it a bit more magical and reliable.
- I mean, I'm not a big fan of bash, the most likely default shell, so my advice would be to explore some alternate shells.
  I am a little surprised completions aren't working in bash by default, but yeah idk if it's possible to get the cycling through suggestions. double tap tab and it should at least list the options though.
  I'd recommend you hop between some shells and see what you like. most distros tend to keep the default shell pretty vanilla, the most change you'll get is maybe zsh with some nicer defauls.
  nushell is great and would be my first recommendation. everything is structured like powershell, but way less verbose and more emphasis on integrating the existing cli ecosystem than pwsh's commandlets for everything.
  fish or oh-my-zsh are things other people recommend. you don't get structured data but they do give a better completion experience and other nice things
  I want to like xonsh, and used it for a few years, but it has the same problems pwsh has with separate ecosystems of structured commands and unstructured text. if you're a python person though I'd consider it too though.
TIL. Looks like I will be installing Nushell. This is neat. Especially how everything returns the final value.

Slow as shit though.

The blue powershell window is for me, but running powershell.exe in conhost, or windows terminal is fast enough.
- What do you mean? If you run powershell directly it opens up either in conhost or Windows Terminal, depending on whatever is your default, doesn't it? Unless you mean PowerShell ISE or whatever it's called.
  
  I mean running it directly shows up in the ugly blue window, and that's slower in my experience.

No grep though as far as I could find... There was a similar cmdlet IIRC, but it was extremely limited and didn't work well (this was years ago though)

undefined

Select-String
It’s really useful too. You can either pipe in text or for example Get-ChildItem a directory of files and it will parse them all. As usual it returns a helpful object with properties like line number.
The idea with powershell isn't to be a text parser - so grep doesn't really work. When you pass things through pipes, it's a full object with multiple properties, and those you can filter with either simple expressions like select-object [-property] or with more complex expressions: https://4sysops.com/archives/add-a-calculated-property-with-select-object-in-powershell/
- Fair, but very very very often (unless you are a full time daily user of the commandlet and all objects you may run into or have a photographic memory) you don't know the actual specific property or object exact verbatim and have to rely on a very quick search to remember that one object you used 3 months ago once that you need now for example. Or you want to see where/if something is referenced in another subset of programs like a specific IP, another program, a resource taken up, etc...
  That is mostly what grep is used for: discovery and reference, which powershell I don't think has a substitute for so instead you have to sort through documentation and forums.
  
  Not trying to be difficult, but that's what get-member is for - it'll dump all the properties for a given object.
  I get it - it's way different from bash - speaking as someone who has been using Linux since Debian Hamm. Side note, net installers over dialup really sucked.
  I was originally forced to use powershell when I joined up with a virtualization team for work and they used PowerCLI.
  It was bonkers how easy it was to get reproducible scripts bundled up for the more junior engineers.

mind telling me why?

i thought it's just another terminal.

I can maybe chime in since I've used both. Basic operations like if statements, arithmetic and loops are a lot closer to what you'd expect on PS. The barrier to programming in bash vs PS is IMO a bit higher because bash heavily uses symbols for everything. This does make PS way more verbose but more easy to wrap your head around it when unfamiliar with the syntax.
I prefer bash but for anything bigger than 5 lines I prefer proper scripting language like python or js and making an alias for "node path/to/js/script.js" and using execSync("program param1 param2") to run shell commands.
Long story short, I prefer bash because it's built in and I know it better than PS, I expect PS guys to feel the same way.
Its a completely different shell, not just another terminal emulator.
Its more readable, and its syntax is less arcane than bash.
For example, a script to get the first line of a file and its lenght in bash is:
bash

#!/bin/bash if [ "$#" -ne 1 ]; then echo "Usage: $0 filename" exit 1 fi filename="$1" if [ ! -r "$filename" ]; then echo "File '$filename' does not exist or is not readable." exit 1 fi read -r first_line < "$filename" echo "First line: $first_line" length=${#first_line} echo "Length of first line: $length"
There is so much I hate about this, like using a semicolon after the if condition, and ending it in fi.
Versus the powershell version:
powershell

param ( [Parameter(Mandatory = $true)] [string]$FilePath ) if (-not (Test-Path -Path $FilePath)) { Write-Error "File '$FilePath' does not exist." exit 1 } try { $firstLine = Get-Content -Path $FilePath -TotalCount 1 } catch { Write-Error "Could not read from file '$FilePath'." exit 1 } Write-Output "First line: $firstLine" $lineLength = $firstLine.Length Write-Output "Length of first line: $lineLength"
It feels more modern.
- bash scripting is not intended to perform all of your logic in the scripting language, it's intended to call out to other programs which perform specific tasks. The entire POSIX command set is your bash scripting language.
  Your script is a simple one-liner if you know some simple commands:
  undefined
  
  $ head -n 1 /usr/share/dict/words | tee /dev/stderr | tr -d '\n' | wc -c A 1
  
  Bash one liners are one is the most fun things in programming.
  
  bash scripting is not intended to perform all of your logic in the scripting language
  Maybe not all, but it's definitely intended to do some, and it's really bad at it.
  
  It works fine for what it is. Bash is just a shell while Powershell is more of a scripting language.
  I think a better comparison would be Python vs Powershell.
  
  It doesn't work fine for what it is. People use Bash for scripting all the time and it's full of footguns and gotchas. Powershell is just an attempt at a sane shell. It's not meant to be a full general purpose language like Python; it doesn't make sense to equate them.
  Personally I don't really like the style of Powershell. The structured data is very obviously a good thing but I don't really like the syntax. Nushell seems a lot nicer IMO.
  
  I can do that as well:
  undefined
  
  $l = Get-Content "example.txt" -TotalCount 1; Write-Output $l; ($l.TrimEnd("`r", "`n")).Length
  There's a condensed version using aliases then:
  undefined
  
  $l = gc 'example.txt' -TotalCount 1; $l; ($l.TrimEnd("`r", "`n")).Length
  I still think it has a better syntax than bash.
- oh, so it's it's own language too.
  I only use it to access WSL (don't judge me)
  
  Did you mean WSL? I mostly use it for that too because lua development on windows is ass.
  
  yhea, sorry.
  
  If you are on Windows test out either Git bash or Msys2
  Much better experience
- That semicolon is the same use in both languages, why the hangup? It's a way to put separate commands on the same line.
  PowerShell tried to build everything around the verb-noun command naming structure, which improves readability.
  What'd the semicolon ever do to you?
  
  After the if condition. No other language does that, so it feels unecessary.
  
  It is unnecessary. It's only needed when you keep them on the same line. E.g.:
  if [ "$variable" == "value" ]
  then
  echo "Condition is true"
  fi
  That ; can be used anywhere in bash or powershell for the same effect
  
  I know, but not all languages require it.
  For example, lua does the following:
  lua
  
  if true then print("hello") end hello
  but this also works:
  lua
  
  if true then print("hello") hello
  
  It sounds like the main point of confusion for you with semicolons, especially in bash and its if/then statements, isn't about their general readability but more about their role in defining what counts as a complete statement or command, and when they are required versus optional.
  You're right that bash requires a semicolon (or a newline) after the if condition before the then keyword if they are on the same line. This is because then is considered a separate 'command' or keyword that follows the if condition and its associated [ ] or (( )) test.
  A newline serves the same purpose as a semicolon.
  In contrast, languages like Lua, Python, or PowerShell often have syntax where then (or its equivalent) is intrinsically linked to the if and doesn't require a separator between the condition and the block opening keyword, even on the same line. They typically use newlines or specific block delimiters (like end in Lua, indentation in Python, or curly braces {} in PowerShell) to define the scope of the if statement.
  While the semicolon's general use is to put multiple commands on one line, its mandatory placement after the if condition before then in bash when on the same line is a specific syntactic requirement of bash to separate those two distinct logical parts of the if construct. Many other languages simply define if condition then block as a single syntactic unit, hence no semicolon is needed there.
  
  I wouldn't call it confusion, more just ick. I don't really like it.
  
  I can understand that. There are several expression 'rules' that don't feel right to me.
  As a wonder, what's your 'first' language? Did you like it?
  I'd guess that might influence your preferences.
  I started with (iirc, in order) batch, bash, python, powershell, go, typescript, rust.
  I'm not putting all the 'markup' languages in there.
  
  I started with (in order, give or take one or two): python, javascript, lua, c, bash, powershell
- I don’t think PowerShell syntax makes sense at all. It certainly doesn’t feel “more modern” to me.
  undefined
  
  param ( [Parameter(Mandatory = $true)] [string]$FilePath )
  param() sorta makes sense, but why are there two single element arrays inside it? Could each array have different contents? Presumably the first is a list of params and the second a list of types + variable names. Why not pair the parameter definitions with their types?
  Are there other properties inside Parameter that you could set?
  Why $true instead of true or True? Doesn’t $ denote a variable name?
  TitleCase keywords are annoying. Since you declared FilePath, could it at least be lowercase? Or is $FilePath special in some way that makes tab completion work better, and specifically look for filenames?
  Are you missing a comma between param’s parameters, or do PowerShell functions not use commas?
  undefined
  
  if (-not (Test-Path -Path $FilePath)) { Write-Error "File '$FilePath' does not exist." exit 1 }
  Why -not? I’d expect to see ! or even Not, which would be consistent with the established language pattern. not would make sense if lowercase were used for logic operators, like true, but even it uses a $ prefix…
  Title-Dash-Case is even more obnoxious than TitleCase.
  Why is this version of a function (Test-Path) using -Path to set the path property, but the version in the previous block, Parameter, just set it inside the parentheses? For consistency, shouldn’t this also be Test-Path(Path = $FilePath)? Or alternatively, above, why isn’t it Parameter -Mandatory True? And why is it single dashes rather than the double dashes for named args that’s a common cli convention?
  undefined
  
  try { $firstLine = Get-Content -Path $FilePath -TotalCount 1 }
  At least the try catch syntax makes sense to me.
  Why is this variable in camelCase when the previous one was in TitleCase?
  Why is the function in Title-Dash-Case but one of its properties (TotalCount) is in TitleCase?
  Why is the property name “TotalCount” when something like “LineCount” would make more sense? Or even to put it in a line-based mode with one property and then to set that value in another, e.g., $firstLine = Get-Content(Path = $filePath, Mode = Line, Count = 1)? If Get-Content is always line-based, why isn’t it called Read-Lines?
  undefined
  
  catch { Write-Error "Could not read from file '$FilePath'." exit 1 }
  Is Write-Error a dedicated function to log an error? Why isn’t it just Write with an Error property? Does it log a stack trace?
  Why is exit lower case? Is it because lower case is used for control flow?
  undefined
  
  Write-Output "First line: $firstLine" $lineLength = $firstLine.Length Write-Output "Length of first line: $lineLength"
  Feels like that should be String-Length $line tbh
  Worse than anything above, as far as I can tell, the official documentation doesn’t even explain the syntax or the design choices behind their weird choices - or maybe it does and I just can’t find it thanks to using a Microsoft site on mobile.
  The bash script makes sense to me, and while there’s a ton I hate about bash, at least it doesn’t use Title-Dash-Case. Its syntax may use symbols instead of words, but most of those symbols are part of a well-documented standard (or for bash specific ones, they extend the standard in an intuitive, still documented way). Needing to read the documentation doesn’t make it arcane; not being well documented in the first place, on the other hand, does. (To be clear, I’m not saying that PowerShell isn’t well documented, but the way that Microsoft documents things does not make sense to me, so I can’t say that it’s well documented, either.)
  I’ll put up with a semicolon or line break being needed between if and then if it means I don’t ever have to Do-This -In $powerShell
  If I want to do something complicated, I’m probably going to use some other language instead of Bash, and as far as I can tell, I’d need to do the same with PowerShell, even if I were comfortable using it.

It's the Ansible of shells. Slow, clunky, unsuitable for Unix.