Our great sponsors
-
-
ble.sh
Bash Line Editor―a line editor written in pure Bash with syntax highlighting, auto suggestions, vim modes, etc. for Bash interactive sessions.
> bash is far behind concerning interactivity.
Is it really? Projects like ble.sh [1] seem to pull off advanced features like syntax highlighting and enhanced completion with pure bash without the need for reimplementing a whole shell from the ground up.
-
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.
-
Have you made use of tools like babelfish? https://github.com/bouk/babelfish
-
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!
This project looks very young. It might evolve into a contender but even the document on Bash compatibility just says "TODO" and frankly Bash compatibility is going to be a multi-year project on its own.
For anyone after an upgrade path from Bash/Zsh then Oil shell is a lot more mature: https://www.oilshell.org/
-
The name sounds very similar to Nushell[1], also written in Rust, but more mature and recognizable
-
-
There is also https://github.com/nixpulvis/oursh which wants to be POSIX compatible with its own extensions. Actually I would prefer if a new shell focuses on bash compatibility.
If features are integrated, then I would probably want to have something about error handling because it is difficult to get right in bash even with shellcheck¹ and gets just worse when things run in parallel.
-
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.
-
There is also https://github.com/nixpulvis/oursh which wants to be POSIX compatible with its own extensions. Actually I would prefer if a new shell focuses on bash compatibility.
If features are integrated, then I would probably want to have something about error handling because it is difficult to get right in bash even with shellcheck¹ and gets just worse when things run in parallel.
-
or use a function. But the above example doesn't actually work, because unfortunately Fish has a deeper defect than a syntactical discrepancy here, and job control is not implemented for Fish functions, see https://github.com/fish-shell/fish-shell/issues/238 and the Fish manual's section on job control https://fishshell.com/docs/current/language.html?job-control.... But again, this is not a syntax issue but a job control issue, a defect in the implementation rather than the design of the syntax.
Finally:
> For any shell wannabe, there is a very large part of the syntax used by ksh/zsh/bash that can be changed without problems, e.g. conditional structures, loops, variable and function definitions, various kinds of parameter expansions and expressions and so on.
