Hacker News new | comments | show | ask | jobs | submit login

The first thing to realise is that the existing UNIX data processing tools deal fall into two categories - those that process (including generate or consume) an ordered sequence of text records (eg. sort, comm, uniq, awk, sed, grep, tr, cut, find, xargs, ls...) , and those that process arbitrary binary data (cat, dd). Most fall into the first category.

Now, while it might make sense to use a better interchange format than "newline-separated text" for those ordered text records, I don't think that adding other arbitrary data types is particularly useful, unless a way can be found to make these arbitrary data types self-describing. This is because there's little to no commonality in the types of processing that you do on different data types: the article shows the example of "cat termkit.png", but what does it mean to concatenate two images ("cat foo.png bar.gif"), or concatenate an image with a text file? Making some assumptions, we can certainly define arguably useful semantics for those, but what does it mean to "sort" an image?

And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?




And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?

Progressive enhancement. You get magic for the obvious things and standard behavior for the non-obvious. I still want the power and flexibility of my vanilla terminal, but I want it to do more when it can.

I want to open up a remote terminal to another server, on the other side of the planet, and do a "cat foo.png" so that I can see it. Better yet, I want to do an "ls -la" and have it show me the standard output, plus all the thumbnails of the images in the folder. I want to do a ton of other stuff too. At the same time, if load up some esoteric weird 30-year-old thing I found on the internet that I just compiled ... well, I expect that to work too. That's a must.

Of course, wanting and having are two different things.


I don't know that we have to make the commands themselves data-aware. The UNIX philosophy is that everything is a stream of bytes and you build on from there. After all, we have plenty of command-line tools for audio, video, structured text, archives, etc.

This tool could simplify cognitive load in two ways. One is by helping you visualize a given stream - untangling the mess of text, data, and what-have-you, perhaps scanning for known headers and letting you drill down on individual components.

Another is by helping you composite functions to operate on data. Say I have a video stream, and I want to extract every third frame, scale and quantize them, and convert to an animated gif. Quick, what's the syntax? Yargh, man page hell. 20 minutes later, I've got it, but it wasn't any fun, and some of the commands weren't stdout-friendly so I couldn't apply pipes that way I wanted.

I'd love a better way to explore functions available to me perhaps based on data type (e.g. Image* -> Image) and even browse and preview user-contributed transformations. There was a Haskell shell that went in this direction, although Haskell is sort of the opposite of UNIX so not sure this is part of the plan ;) 




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: