Building the Future of the Command Line
github.com
Building the Future of the Command Line
1–10 of 75 posts
Re: Building the Future of the Command Line
#2The 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!!
Re: Building the Future of the Command Line
#3One 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 effectively 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 to me that this task would benefit from some more standardization and maturation. What is the JSON of the command-line? How can we do to increase the level of interoperability between how information is encoded on different tools' command-lines? e.g. think of ImageMagick "convert" versus "find" versus "ffmpeg": totally different universes, but all of them in their own way turn command-line arguments into mini-DSLs.
Re: Building the Future of the Command Line
#4One 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 effectively 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 to me that this task would benefit from some more standardization and maturation.…
I've always wondered about expanding stdin, stdout, stderr. Say, stdjson that doesn't get visually displayed, but can be piped (and would only be generated if it is needed on the pipe stream).
ls | cat With the direct ability to process in line:
ls -a | json.files[0].last_modified
I'd probably want multiple output formats (including s-expressions).
Re: Building the Future of the Command Line
#5One 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 effectively 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 to me that this task would benefit from some more standardization and maturation.…
Given the prevalence and longevity of GNU style short and long options, pretty much anything that doesn’t follow that is “out of compliance”.
However, you also called out some very specific commands that are that way for a reason. For example the order of options for ffmpeg matters very much, as that’s used to construct the processing pipeline. It does make sense for certain things to be custom, but that should only be done when there’s a good reason.
Re: Building the Future of the Command Line
#6The 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 com…
Amen. Offhand, can we start with e.g. a 2 or 3 window deal, in which there is a file manager and a document viewer that one can easily copy and paste from? There's stuff out there that sort of does this but it could be done MUCH better.
Re: Building the Future of the Command Line
#7One 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 effectively 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 to me that this task would benefit from some more standardization and maturation.…
In adition to stdin and stdout, I want datain and dataout pipes, for passing some standard format.
Re: Building the Future of the Command Line
#8One 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 effectively 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 to me that this task would benefit from some more standardization and maturation.…
It feels solved in raw Powershell functions, but running external CLI tools inevitably returns text and ruins the workflow.
"Crescendo" has been marketed as a solution and looks cool, but it means relearning the tool or documentation being less useful. The sheer amount of existing time people spent learning arcane git syntax means they're not going to switch to a hypothetical "New-GitCommit" function, even if it accepts arrays or PSCustomObject as input.
Re: Building the Future of the Command Line
#9Very well written article and very impressive magazine generally.
Re: Building the Future of the Command Line
#10One 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 effectively 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 to me that this task would benefit from some more standardization and maturation.…
I have a hard time imagining how we get out of the gravity well of CLI programs handling their own parsing.
A tool I write has a use-case for understanding the syntax of at least ~common CLI tools well enough to pick out args that will be other executables (sudo cat, find blah -exec...), so I have been idly pondering whether there's a humane, declarative, descriptive grammar that can express nearly all CLI interfaces.
It's probably not worth the work for my case, but it might get to be more tractable if it was also an input for better completion, help, linting, etc. tools.
Ideally something that drives enough all-around value that projects would start up streaming the grammars (and maybe adopting an associated parser?)