Our great sponsors
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
Git
Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
No, I've been deep in the bash manual and source code during my work on https://www.oilshell.org, which basically reimplements a "cleaned up" spec-driven bash, as OSH.
But I also used bash for 15 years before that, and I never really used the manual either. I got by with a minimal / sane dialect, and I read a few books about Unix and one about POSIX shell.
The main recommendation I have for anyone who wants to learn bash is to learn Unix and C. Learning the underlying model explains many things, explains the bad error messages, and makes it easier to use.
https://www.oilshell.org/blog/2020/04/comics.html - Three Comics For Understanding Unix Shell
So yeah I don't think "learning shell" or "learning bash" is actually a great goal -- it's part of the operating SYSTEM, and you want to learn the OS, and its philosophy.
related - https://www.oilshell.org/blog/2021/01/philosophy-design.html - Unix Shell: Philosophy, Design, and FAQs
> An interactive shell can be a login-shell or a non-login-shell.
A shell can be login and non-interactive.
This happens e.g when starting a session from a X session manager. Subsequently a terminal such as Xterm starts non-login interactive sessions.
Similarly doing ssh starts a non-interactive login shell.
> However, bash behaves like an interactive non-login shell in this case and reads `bashrc`.
IIRC nope: distros such as Debian often have bashrc source bash profile (or the other way around, I can't recall) which has me irate to no end+. They even have some TTY dependent stuff in profile which spits out some error in some cases when no TTY is allocated because heh not interactive.
+ I took great length to have my rc and profile properly separated because it's that much faster not to source the unneeded stuff. https://github.com/lloeki/dotfiles
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/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.)
Yes, but you are referring to standalone scripts, not functions defined within a Bash script.
Compare for example the following helper code used for git command completion inside Bash and inside PowerShell.
Bash: https://github.com/git/git/blob/master/contrib/completion/gi...
PowerShell: https://github.com/dahlbyk/posh-git/blob/master/src/GitPromp...
I believe this is clean Bash code and clean PowerShell code, and a script with a certain complexity. The functions inside the Bash script are documented using comments, the ones inside the PowerShell script are documented using "structured comments" (similar to javadoc/xmldoc/...). The parameters of the functions inside the PowerShell script also contain metadata which is used to provide completion on the commandline and similar functionality as the command line flags you demonstrated.
I just learned about 'getopts' in Bash, which you can actually also use to implement parameters to a Bash function. So what you are showing on a script level, can also be applied for functions. Did not know about that.
Still, not saying PowerShell is better than Bash in a Linux context, but it seems a lot of Linux users have a gut reaction to right out reject PowerShell. I think it does have some advantages for certain use cases, like more complex scripts, a cross-platform context, ... and of course, for someone with a .NET background it's easier to program more complex things with it.