1. Create a Smart Selection with the regular expression "SC\d+"
2. Add an action to "Open URL...", with the URL "https://github.com/koalaman/shellcheck/wiki/\0" (\0 will be replaced with the matched regex)
3. Now holding down the command key will change any ShellCheck errors to be active http links.
ShellCheck recognizes three hashbangs, POSIX, BASH, and the Korn shell (as is explained in the manual page). I would argue and assert that BASH is the least relevant of the three.
I have occasionally needed to write to the POSIX standard, and remove advanced features from my scripts. This is most commonly needed for BusyBox (including Windows) and Ubuntu/Debian DASH. It is important to understand what is not in POSIX, for the time when an advanced shell isn't available. Please browse the POSIX definition, reported by a google of "POSIX shell":
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
The Korn shell lived and diverged for many years, beginning with ksh88 (issued before the first BASH release in 1989). David Korn retired, and AT&T was not pleased with ksh93 changes implemented by outsiders who impacted both compatibility and performance, and thus ksh93 was rewound.
Cygwin, notibly, only implements mksh for Windows. The mksh binary on all platforms is a fraction of the size of BASH (check the output of the "size" command if an "ls" does not persuade you).
However, the MirBSD Korn shell is one of the most lively shells for development activity, the latest release being in October of 2020. It is also on every Android phone (chosen as the system shell by Google), so its deployment is massive.
When I am purposely writing above the POSIX shell, I choose mksh from MirBSD as my standard. I do not think the BASH innovations to be well-thought.
Depends on how you call "relevant", but I disagree regardless. If you're writing a shell script, you either need to be hard-core portable, in which case POSIX is your only option, or you don't, in which case you're almost certainly targeting a GNU/Linux system with BASH installed. Of course, if you know that you're targeting a specific system with a specific shell installed then by all means; if I were primarily an OpenBSD dev, I'd happily use ksh. But in general, the (unix) world is always going to give you POSIX, and BASH is the second most widely available option. And bluntly, for all that I love shell, if you're trying to argue for the most elegant or sophisticated language, sh/BASH/ksh is irrelevant because all of them kinda suck outside of their niche.
I wrote it that way.
For myself, I write to the ksh93 standard, but reduced to mksh, because I desire functionality, but portability.
The question of s/BASH/bash is not relevant to me. The toolset is the question.
Noted again is that Cygwin only implements mksh, not ksh93. Write for what you have.
It would make me nothing but happy should "bash" adopt ksh syntax. Perhaps I should struggle to be sufficiently adept to submit patches.
The OpenBSD Korn shell is actively developed and there is a portable version of it available. The latest version which reflects the shell as available in OpenBSD 6.9 was released 3 days ago. https://github.com/ibara/oksh
This is one question upon which we agree.
https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003...
bash 5.0: https://www.osnews.com/story/129062/bash-5-0-released/ 2019-01-08
MirBSD Korn 2020:
Oct 31, 2020 mksh-R59c
May 16, 2020 mksh-R59b
Apr 14, 2020 mksh-R59
Mar 27, 2020 mksh-R58
Mar 1, 2019 mksh-R57> the MirBSD Korn shell is one of the most lively shells for development activity, the latest release being in October of 2020
I.e., you suggested the measure is release recency, not cadence. And after I pointed out that bash (sorry, BASH) has a more-recent release, you're moving the goalposts.
Anyways. It doesn't matter. Love the shell(s) you love; hate the shell(s) you hate. You don't need a quantitative basis. They can release as often or as rarely as they like with little impact on whether they're good shells or not.
Also: https://github.com/oilshell/oil/branches/all?query=release%2...
The reason that the POSIX shell is not Korn is the existence of Microsoft Xenix, where the maximum size of the code/text segment is 64k.
Debian chose the POSIX standard for precisely this reason: a minimal text segment.
One particular thing that I like about Korn is this:
function getv { nameref var="$1"; shift; print "$@"; read var; }
I will post some of my scripting that uses this feature if you have interest.
This is the most direct method.
https://www.linuxjournal.com/content/linux-filesystem-events...