ls but 'The Unix Way'

What is The Unix Philosophy?

The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist, modular software development...

But in particular, Doug McIlroy, and later, Peter H. Salus, honed in on the following:

Unix provides for this methodology in several ways:

https://en.wikipedia.org/wiki/Unix_philosophy

Does 'ls' qualify?

ls is a particularly useful utility, but it falls short of the Unix path in many ways. Most eggregiously, it does two things: scan the filesystem collecting data, and display such data.

As a result, it has two distinct sets of flags that control it -- ones to deal with the filesystem, and ones that sort and otherwise format the display.

Over decades, many flags were added to allow ls to do an adequate job on both ends, but we lost in the process.

83 distinct flags or options are offered by GNU ls. I have a T-shirt with the summary of ls options, and it is a lot of text! Such complexity is directly resultant from the lack of domain separation between the distinct tasks the utility performs.

What's worse, is that ls is not really composable. There is nothing you could pipe in as a substitute for it directly hitting the filesystem. The output is human-readable, and cannot be externally manipulated easily with text tools.

How should it work?

Clearly, the functionality we regard as 'ls' should be performed by at least two programs: the file-system scanner and the formatter. The first should work much like ls today, but generate a standard textual output which can be further processed and displayed by standard unix utilities like awk...

The simplest way is to provide CSV data -- comma-separated fields containing name, size, type, permissions, etc. You could do JSON or XML, but it is an overkill and will add unnecessary overhead, as the fields are well-known and always identical in this case.

An experiment

I wrote a very primitive version to see what it's like. It just dumps the contents of a directory, like this:

Note that output is textual but not fully decoded -- things like how to display dates and users is up to the presentation program. But I did provide an -h (for 'human') option to make life easier in most common cases:

This is easier, but in some cases I can see the need for processing dates or whatnot, easier without the -h.

To make it more useful it should be piped into something that provides nicer output. Here it gets a little hairy:

OK, this looks kind of like 'ls -l', but the pipeline is a little painful-looking. We need to:

Also note that because of my shortcut of fixing the date format in the filesystem scanner we are now stuck with the wrong-looking date/time format. And that is why it should really be done at the output level!

Some Difficult Things

As is, I noticed some difficulties:

I should probably look at a few CSV-related utilities which will hopefull simplify dealing with the output of something like this.

Is it worth it?

Well, that was a lot of work to create a tiny subset of what ls does. But it feels a little more correct.

But having a filesystem scanner separate from the display allows for reuse -- things like find can be built around that.

Discuss on BBS

index

🏭 Fornax inside...

Proxied content from gemini://spell.mywire.org:1960/~stack/0257.gmi (external content)

Gemini request details:

Original URL
gemini://spell.mywire.org:1960/~stack/0257.gmi
Status code
Success
Meta
text/gemini
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.