61–70 of 168 posts
Earlier quoted context omitted.
The Unix shell operates on binary streams, not on text.
Ah, I thought this was about structured text (like JSON) vs. plain text -- binary content is a bigger issue!
Earlier quoted context omitted.
Define a standard format for describing command syntax. I'd suggest basing it on JSON, but you could use XML or Protobuf or Thrift or ASN.1 or Sexprs or whatever. Embed in executables a section containing the command syntax description object. Now when I type in a command, the shell finds the executable on the path, opens it, locates the command description syntax section (if present), and if found uses that to provi…
There isn't a 1:1 mapping of binaries to documentation or completion scripts. That idea won't work out. "Defining a standard format" hasn't been a successful practice in the Unix world. Many standards consist essentially of the bare minimum that everybody can agree with. Unix command-line interfaces are already structured (as a list of strings), and more structure would be hard to support at the binary level. There a…
Then you are essentially relying on the de-facto standard of not rolling your own argument parsing, as opposed to some product of a standards committee.
Earlier quoted context omitted.
Or the author justifiably thinks that a shell shouldn't support functions?
Why shouldn't it? The shell is arguably the most convenient way to interact with your system's programs, seconded only by something like Perl. That level of interaction ought to mean you can write functions such as for common tasks. Or should I now have to use Perl for that?
I would probably use Python, Go or Powershell.
Earlier quoted context omitted.
> like pipes that are essentially text-only Pipes work fine with binary data, you just need to be piping to a tool that works with binary data rather than text e.g. cat | openssl base64
The trouble with that example is that it could more simply be written: openssl base64 On the plus side, you do get a prize for suggesting it [1] Something involving bulk binary data moving over a pipe which isn't an indirect redirection would be: gzip somefile | ssh user@host "gunzip >somefile" Although, again, there's a perfectly good -c flag to SSH that would do the same thing. Probably the most common example of t…
Good catch! I actually use another command that generates binary output that I pipe to OpenSSL to convert to base64 but rather than type out the full command I thought 'what's the easiest way to get some binary data on stdout' and 'cat binaryfile' was it.
Earlier quoted context omitted.
The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…
Powershell does two things right: it uses structured output, and it separates producing the data from rendering the data. It also does one thing wrong: it uses objects (i.e. the stuff that carries behavior, not just state). This ties it to a particular object model, and the framework that supports that model. What's really needed is something simple that's data-centric, like JSON, but with a complete toolchain to def…
What would it be? Is there a real alternative to XML with those features out there? I don't think so.
When you would want to have the features of XML and would design it from scratch I'm quite sure it would have the complexity of XML again.
Usually implementing some functionality yields every time the same level of complexity regardless of how you implement it (given that none of the implementations isn't out right stupid of curse).
Earlier quoted context omitted.
My structured objects aren't your structured objects. In that use case why not use a dedicated program (like say ae python/js/clojure interpreter) to handle more complex pipes and keep the shell level primitves... Well, primitive. Text is compatible with all systems, past and present, and can be used to model more complex objects. Let's not add features to the core on a "why not" please.
The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…
Being able to do arithmetic right in the shell is handy.
$ echo test 1 + 2>err
Or what if there are files with these names?
$ cp /bin/grep 42
$ 42 + 1
Earlier quoted context omitted.
The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…
I lean towards wanting all my tools to support at least one common structured format (and JSON generally would seem the best supported) these days. It'd be great if there was a "standard" environment variable to toggle JSON input/output on for apps. If you did that, then e.g. a "structured" shell could just default to turning that on, and try detecting JSON on output and offering according additional functionality. T…
Earlier quoted context omitted.
My structured objects aren't your structured objects. In that use case why not use a dedicated program (like say ae python/js/clojure interpreter) to handle more complex pipes and keep the shell level primitves... Well, primitive. Text is compatible with all systems, past and present, and can be used to model more complex objects. Let's not add features to the core on a "why not" please.
The so-called "plain text formats" are also just representations of complex objects. Often these formats are ad-hoc and hard to parse correctly. Multiple text files in a file system hierarchy (e.g. /etc) are also just nested structures. So in principle, treating those as complex object structures is the right way to go. Also, I believe this is the idea behind D-Bus and similar modern Unix developments. However, what'…
Start with record based streams first. Text streams requires [buggy] parsing to be implemented everywhere. It should be possible to have escaped record formats that allow the right side of the pipe to use AWK style $1, $2, $3, etc.
After removing the need to parse the fields, the next priority, imo, would be to introduce integral types so the actual data itself doesn't need to be parsed. u32 on the LHS can just be 4 bytes and then read out on the RHS as 4 bytes. This could save a lot of overhead when processing large files.
Only then would I want to get into hierarchies, product types, sum types, etc.
Something that's been capturing my imagination recently is sshing into a machine, pushing an appropriate shell binary to /tmp, and then executing it. If you have an exotic preference for shell (or vim config, or whatever), we've presumably generally got sufficient bandwidth these days to do a virtually instant user-space install and execution, no?