[HN Gopher] Building the Future of the Command Line
___________________________________________________________________
Building the Future of the Command Line
Author : smartblondeva
Score : 5 points
Date : 2022-09-15 21:48 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| an1sotropy wrote:
| One thing not discussed are the libraries used for command-line
| parsing (parsing argv), and how that might get complicated by
| shells trying to make the command-line into something more than
| an array of strings.
|
| Having written a non-trivial command-line parser in C, and having
| used a bunch of them in other languages, it seems like this step
| could use some more standardization and maturation. What is the
| JSON of the command-line? What is the level of interoperability
| between how information is encoded on different tools' command-
| lines (think of ImageMagick "convert" versus "find": two
| different universes).
| rektide wrote:
| The command line ought hybridize some, please. Having better self
| describing interfaces, machine to machine capabilities... humans
| are awesome enouhh to whip up super wild magic on the fly
| ("spellcasting on the fly") but these same tools are much weirder
| to use as you descend into scripting, as you start bringing
| "real" programming languages in (which have their own alternate
| realities: "standard libraries").
|
| The command line should/ought bridge & integrate better. Making
| it more usable from these higher (more pre-baked/automated)
| levels is one side. And then reciprocally, how wonderful it would
| be to see execution flow expressed less in terms of stack traces
| & more in terms of networks of communicating processes. Create
| boundary layers, make the cli tools visible & known operations
| sequenced by (but still visible within) higher level systems.
|
| Cli on and on!!
___________________________________________________________________
(page generated 2022-09-15 23:01 UTC)