Good point. Exit codes can be difficult. A non-zero error value may not be an error; it could indicate a type of success or be a warning or a result of a calculation or any number of things depending on the application.
Good point. Exit codes can be difficult. A non-zero error value may not be an error; it could indicate a type of success or be a warning or a result of a calculation or any number of things depending on the application.
It’s some of the most cursed code I’ve ever worked with.
(God bless anyone who ever used this program and got a set fault or sigint or sighup and therefore a bizarre result.)
What is the decimal range of values used?
Then, I read the part about each digit of the decimal representation.
Now I may need to lie down for a spell.
Personally, I think Result types from Rust/Haskell/Swift make a lot of sense -- a program either succeeds with some output, or fails with an explanation of why. By default, pipes stop piping if one command fails.
Usually, this is what happens. Usually, the error-signalling return is accompanied by a message (posted to stderr).
> By default, pipes stop piping if one command fails
set -o pipefail[0]. https://www.austingroupbugs.net/view.php?id=789
[1]. https://lore.kernel.org/linux-dash/20200701015226.GA6839@gon...
Correct me if I'm wrong, but aren't exit codes an OS-level thing? That would be one hell of a redesign!
Not that I wouldn't absolutely love to have rich/structured return values, but that's already hard to do in a single-language system - even ignoring backwards compatibility, doing this in a traditional OS would require a level of cooperation I don't think the industry is capable of.
And there is in PowerShell - you can return arbitrary complex object.
As a Unix person my impression of PowerShell is that it’s more robust for scripting than the Unix shells, but that the Unix shells are more suitable for interactive use. And for anything of sufficient complexity and/or size I’d personally reach for either Python or I’d write a program in Rust.
I guess in the end it comes down to personal preference and what you are familiar with.
Incidentally, when I started at the university, when I was still using Windows, and PowerShell had recently come out I actually started with PowerShell and was getting comfortable with it. But we learned about Linux at the university and a friend I made at the university was showing me Linux stuff, and I started using Linux and FreeBSD instead of Windows. If it wasn’t for that then I’d probably have been a PowerShell person today.
There's enough aliases for bashisms that honestly, the largest hurdle to switching was "rm -r -Fo" rather than "rm -rf".
I continue to believe that within 10 years, Microsoft will have just switched entirely to Linux+WINE under the covers. :)
For example: Get-ChildItem was already aliased to both ls and gci on my system.
The best example of this I think is ConvertFrom-Json vs something like jq. Jq's syntax is extremely difficult to learn, but with powershell I just built upon the knowledge I already had and got to use the same commands I use everywhere else.
Its totally funny (and lame) that people complain about its verbosity since its not true (verbosity is optional) and that typically shows that person wasn't involved at learning it at all and thus can be ignored.
Furthermore, there is an alias naming standard in posh, besides having all linux like names, they are usually named by first letter of verb and first and second word letter of noun (Get-ChildItem => gci; Get-Service => gsv; )
Then we have a parameter aliases, just use any unique subset of the its name ( -Computer => -C or -Co or -Com ... )
You can also customize those names with proxy cmdlets.
All in all, almost 100% of the time PowerShell sentence is way shorter then equivalent bash sentence.