I will give Microsoft credit that Powershell is a very pleasant to use shell language. There are a few quirks, but I encounter them a lot more rarely than in POSIX shells.
That said, my brain does still think in POSIX scripting, so it always takes me a little while to get back in the swing of Powershell.
and the result was the file content visible on screen. Then you were happy with your code and you put it in a function for reuse:
function test {
get-content file.txt
}
and now there's no output. PowerShell pipeline is not stdout, get-content doesn't display anything on screen, only the output formatters at the end of the pipeline do. If the function has no output by default then you would see nothing. That would be an annoying behaviour the other way. In PS, braces {} make anonymous codeblocks and they're used often, e.g. in code like
# square the first 5 numbers
1..5 | foreach { $_ * $_ }
# rename some files
Get-ChildItem | where { $_.Name -notmatch '[0-9]' } | Rename-Item -NewName { $_.Name + "2" }
That would be really annoying if you always had to 'return' results out of scriptblocks. And it would be annoying if scriptblocks in functions behaved differently to scriptblocks in filterscripts or calculated properties.
Do you have any examples? This doesn't sound familiar.
Dictionaries are often used for return values, as they can be cast to PSCustomObject for a quick way to make objects for the pipeline. But in that use case they aren't passed in, and that's not anything to do with the `return` keyword or all output from all commands becoming function output.
That is... not the way I generally work around it or see it.
Normally you just use Write-Host when you need it and otherwise just collect return values inside the function by assigning them to variables.
It's basically solved if you never call a command without storing the return value somewhere. Which is not optimal in a scripting language where you just want to get things done, but it's not the end of the world.
My biggest issue with PowerShell is the lack of a good, web-indexed, resource for exposing what SHOULD be expected in a normal operating environment. It makes looking for features that are expected in a standard library just not worth the effort. By comparison every other language I like programming in actually has a very strong set of documentation in an easily found repository.
What do you mean by "a normal operating environment"?
Different versions of Windows came with different versions of PowerShell. Some can be patched to have the newer language features (Windows Management Framework 5.1 can be installed on Windows 7), but that won't bring in all the same cmdlets as Windows 10 has, because there aren't the required internals in Windows 7.
If you have different things installed (Hyper-V, ActiveDirectory, any big Windows role/feature) you'll have different modules available, and if you install things like RSAT (Remote Server Administration Tools) then you'll get server management cmdlets on workstation operating systems.
It's not so much like you download Python 3.6 and get one standard library everywhere, its origins are more in "companies managing their own Windows server estate", so your environment is not standard, it's whatever environment you have.
The standard library, though, is mostly .Net, so depending on your Windows and PS version, it's ".Net Framework 4.5" (or 3.5 or etc.) for .Net framework library features accessed directly from PS.
I was going to agree entirely as I had been mucking with Powershell ISE and was surprised that it didn't have their normal standard of documentation, but I did find an okay reference online.[1]
Looking more, it's kind of bad, because they break the sections in the reference up by the modules, and it's utterly mysterious what the modules are for. I mean, they all seem to be for doing incredibly obscure stuff in Windows, which I'm sure is useful, but I can't figure out obvious things like the syntax or types.
This may be because the intended audience is liable to just copy and paste stuff and hammer away it until it works...
That said, my brain does still think in POSIX scripting, so it always takes me a little while to get back in the swing of Powershell.