limits-of-unix.post

   1 ;;;;;
   2 title: Limits of Unix shell
   3 tags: unix
   4 date: 2015-08-20 14:54:10
   5 format: md
   6 ;;;;;
   7
   8 Let's go back to the GNU Coreutils list of tools.  `ls` for example.  Usually
   9 the user will have set some alias to `ls` instead of the plain invocation,
  10 either to enable highlighting (`--color`), sorting (`--sort`), or to add more
  11 information than just the filenames (e.g. `--format`).  There is even
  12 integration with Emacs (`--dired`).
  13
  14 The question then is:  How much of the functionality of `ls` is actually
  15 devoted to secondary formatting instead of listing files?  And shouldn't this
  16 functionality be moved into separate tools?  Since output is intended for
  17 multiple kinds of recipients, additional data creeps in and complicate tools a
  18 lot.
  19
  20 Alternatively, we could imagine using `ls` only to get unformatted and unsorted
  21 output.  Which would then be passed through to a `sort` command and a `fmt`
  22 command of sorts.  Of course this all takes some more time, re-parsing of
  23 output etc., so it's understandable in the interest of performance not to do
  24 this in the traditional Unix shell.
  25
  26 However, let's assume a more sophisticated shell.  Assuming `ls` is limited to
  27 listing files, then the user will alias `ls` to a pipeline instead, namely
  28 something akin to `ls | sort | fmt`.  Then again, formatting is part of the
  29 user interface, not the functionality, so it should rather be part of the
  30 internal shell formatting, possibly exposed as separate filters as well.
  31
  32 The *result* of `ls` is a (possibly nested) directory listing.  Regardless of
  33 post-processing, this "object" should still be available for further
  34 investigation.  Which means that while sorting may be applied destructively,
  35 formatting may not, unless specifically requested, in which case the result
  36 would be a kind of "formatted" object (text, GUI widget) instead.
  37
  38 In other terms, the user should be able to refer to the last results
  39 immediately, instead of rerunning the whole pipeline.  E.g. coming from Common
  40 Lisp, variables like `*` to `***` will store the last three results for
  41 interactive use.  In the shell then, `ls` would set `*` to the generated
  42 directory listing; since the listing is also most likely printed to the screen,
  43 the full listing will also be stored (in that object) to be used again if e.g.
  44 `*` is requested again.  Rerunning the command, on the other hand, will
  45 possibly generate a different directory listing as files may have been changed,
  46 so there *is* an immediate difference between the two forms.
  47
  48 # Examples
  49
  50 The pipeline `ls | wc -l` is (at least for me) often used to get the number of
  51 files in the (current) directory.  Unfortunately there is no direct way to get
  52 this number directly except to enumerate the entries in a directory (under
  53 Linux that is).