From a48fc1d44b1252c2afce8b4388abcddb780b8899 Mon Sep 17 00:00:00 2001 From: Olof-Joachim Frahm Date: Thu, 20 Aug 2015 14:55:05 +0200 Subject: [PATCH] Add another unix shell post. --- limits-of-unix.post | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 limits-of-unix.post diff --git a/limits-of-unix.post b/limits-of-unix.post new file mode 100644 index 0000000..56f8a07 --- /dev/null +++ b/limits-of-unix.post @@ -0,0 +1,46 @@ +;;;;; +title: Limits of Unix shell +tags: unix +date: 2015-08-20 14:54:10 +format: md +;;;;; + +Let's go back to the GNU Coreutils list of tools. `ls` for example. Usually +the user will have set some alias to `ls` instead of the plain invocation, +either to enable highlighting (`--color`), sorting (`--sort`), or to add more +information than just the filenames (e.g. `--format`). There is even +integration with Emacs (`--dired`). + +The question then is: How much of the functionality of `ls` is actually +devoted to secondary formatting instead of listing files? And shouldn't this +functionality be moved into separate tools? Since output is intended for +multiple kinds of recipients, additional data creeps in and complicate tools a +lot. + +Alternatively, we could imagine using `ls` only to get unformatted and unsorted +output. Which would then be passed through to a `sort` command and a `fmt` +command of sorts. Of course this all takes some more time, re-parsing of +output etc., so it's understandable in the interest of performance not to do +this in the traditional Unix shell. + +However, let's assume a more sophisticated shell. Assuming `ls` is limited to +listing files, then the user will alias `ls` to a pipeline instead, namely +something akin to `ls | sort | fmt`. Then again, formatting is part of the +user interface, not the functionality, so it should rather be part of the +internal shell formatting, possibly exposed as separate filters as well. + +The *result* of `ls` is a (possibly nested) directory listing. Regardless of +post-processing, this "object" should still be available for further +investigation. Which means that while sorting may be applied destructively, +formatting may not, unless specifically requested, in which case the result +would be a kind of "formatted" object (text, GUI widget) instead. + +In other terms, the user should be able to refer to the last results +immediately, instead of rerunning the whole pipeline. E.g. coming from Common +Lisp, variables like `*` to `***` will store the last three results for +interactive use. In the shell then, `ls` would set `*` to the generated +directory listing; since the listing is also most likely printed to the screen, +the full listing will also be stored (in that object) to be used again if e.g. `*` +is requested again. Rerunning the command, on the other hand, will possibly +generate a different directory listing as files may have been changed, so there +*is* an immediate difference between the two forms. -- 1.7.10.4