Our great sponsors
-
-
libxo
The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.
-
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.
-
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.
> Every option doubles the amount of testing required to exhaustively test the program.
True, but pairwise-independent combinatorial testing provides almost-exhaustive coverage with non-exponential growth in test cases: https://github.com/microsoft/pict
For completions, as part of the Oil shell design space exploration, @chubot proposed a protocol he called Shellac, see: https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos...
> In our timeline, maybe some file format could be standardized that describes the particular inputs and options a command takes, and e.g. shells would hook into it. Kind of like header files, but distributed either in a community repository or by each of the tools themselves.
This sort of sounds like what we're working on at Fig. We've defined a declarative standard for specifying the inputs to a CLI tool and have a community repo with all supported tools: https://github.com/withfig/autocomplete
Disclosure: I'm one of the founders
Yes, there's stuff that you can't get just from parsing the man page too, but it's a huge help. I know it's not done every startup, I have running that as part of my "update everything" script.