11–20 of 75 posts
This trend of "new modern shells" that runs and start as slow as some javascript code (powershell) needs to stop
People forgot what shells are for, and what scripting is for
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 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).
Additionally, as JSON is text, you can use awk/sed/grep and so on.
Earlier quoted context omitted.
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).
You can always just use JQ. Additionally, as JSON is text, you can use awk/sed/grep and so on.
"your server needs a GPU and an i5 to use our shell, as it provides a graphical interface and some shader animation because that's what attract the money people, they want shiny stuff y'know" This trend of "new modern shells" that runs and start as slow as some javascript code (powershell) needs to stop People forgot what shells are for, and what scripting is for
Earlier quoted context omitted.
You can always just use JQ. Additionally, as JSON is text, you can use awk/sed/grep and so on.
The intent is that standard tools would output alternative formats.
I think stdjson is insane yet awesome to ponder.
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 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…
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 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.…
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 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).
int main(int argc, char *argv[], char *envp[], JSON *json)
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 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).
Earlier quoted context omitted.
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…
You might find http://docopt.org/ to be of interest. (It's available in many languages https://github.com/docopt ).