-
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!
-
murex
A smarter shell and scripting environment with advanced features designed for usability, safety and productivity (eg smarter DevOps tooling)
-
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.
-
-
-
jc
CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Yes, those are all problems with bash and the state of the art.
The funny thing is that there about a dozen ways to spell it, like $(dirname $(readlink -f $0)). Since the shell itself doesn't provide this functionality, people come up with a lot of workarounds.
In Oil it will be "source $_this_dir/mylib.sh" for "relative imports".
https://github.com/oilshell/oil/issues/587
I solicit feedback on every Oil release, so let me know what you think of the fixes: http://www.oilshell.org/blog/tags.html?tag=oil-release#oil-r...
Dealing with filenames is fixed in Oil: http://www.oilshell.org/blog/2021/04/simple-word-eval.html and with QSN:
http://www.oilshell.org/blog/2020/10/osh-features.html#safe-...
Again, if you don't think this actually solves the problem, leave some feedback. Oil is the most bash-compatible shell by a mile, so you might need to use it someday :)
(The theory is that in MOST situations you don't get to choose your language, just like you didn't choose C, C++, or shell. It's all the inertia of compatibility.)
Oil has named parameters: http://www.oilshell.org/release/latest/doc/idioms.html#use-n...
I know about the long file list problem, but I don't think I've ever run into it, mainly because I use xargs, which batches up commands correctly. If there is some other situation where it comes up, I'm interested.
Insane combination of grep / awk / cut: Oil has eggex which compiles to ERE to help you write egrep and awk patterns: https://www.oilshell.org/release/0.8.11/doc/eggex.html
You get syntax errors when you write the pattern (at parse time), not when you run it.
Crucially, we don't "rewrite" grep and awk. We just make them easier to use (optionally). There is a smooth upgrade path and you can retain your knowledge while forgetting about some sharp edges.
> Personally I find it amazing that people invented this thing, then spent decades tripping on the same quoting and filename handling issues and not finding that to be a good reason to fix it.
Yes I quoted David Korn complaining about the quoting problem in the early 90's, which was closer to Unix's invention than we are to the early 90's.
https://www.oilshell.org/blog/2019/01/18.html#slogans-to-exp...
The reason we still have it is the inertia of compatibility, and the fact that nobody really owns shell. Even though people rightly complain about Google's web stewardship, HTML5 was a great improvement and cleanup. They paid people to fix HTML, and it worked to a large extent.
Some food for thought: A Generation Lost in the Bazaar https://queue.acm.org/detail.cfm?id=2349257
but in a way, pipelines are an alternative to subshells.[7] If you want passing values through the pipes to be as robust as passing them as arguments, you need structured pipelines.
You're right that if you are using a lot of external commands in a ‘raw’ way, you don't get to take much advantage of the structured pipeline. Imo PowerShell proves that in practice, if you have a big enough library ecosystem, you can leverage wrappers and ‘pure’ tools written in your shell language to get a pretty nice programming experience.
—
0: https://elv.sh/learn/unique-semantics.html#motivation
1: https://elv.sh/learn/effective-elvish.html#returning-values-...
2: https://murex.rocks/docs/user-guide/pipeline.html
3: https://docs.microsoft.com/en-us/powershell/module/microsoft...
4: https://docs.microsoft.com/en-us/powershell/module/microsoft...
5: https://github.com/elves/elvish/issues/1149#issuecomment-705...
6: https://www.nushell.sh/book/pipeline.html#basics
7: https://elv.sh/learn/effective-elvish.html#prefer-pipes-over...
Recently, I have been looking at the Factor language http://factorcode.org. I think I would like to have a shell based on that.
I'd like most programs to implement a JSON interface, given right flags. Or maybe the existence of some env var like $DEFAULT_OUTPUT=JSON
I like this approach:
https://github.com/kellyjonbrazil/jc
> CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts
I had a similar complaint so I wrote this in ruby https://github.com/nburns/utilities/blob/master/rson