[TUHS] History of cal(1)?

[Dan Cross via TUHS]

[Honoring wkt's recent request for this discussion to migrate to COFF,
sending TUHS to Bcc]

While this discussion moves to COFF, there is a Unix tie-in
specifically with respect to the empty-file `true`: Gerard Holzmann
wrote a nice article about this several years ago in the "Reliable
Code" column of IEEE Software, titled, "Code Inflation". It's not
long, and it's a very fun read. Themes he explores may resonate well
with the average TUHS reader:
https://spinroot.com/gerard/pdf/Code_Inflation.pdf

As an aside, the implementation of `true` as an empty file relies on a
quirk of `sh` to work: `sh` would try to invoke a program via `exec`,
and if that failed, would then try to interpret it as a shell script.
Since a zero-byte file is not a valid binary executable for invocation
via `exec`, this would fail; the shell would then try to interpret it,
do nothing (as there was nothing to do), and exit with its default
value (0), indicating success.  But a side-effect of this is that one
cannot directly `exec` true and expect success; the result is an
error.  "Why would anyone want to do that, anyway?" Good question; I
suspect they wouldn't in the normal case. But I can imagine someone
linking `true` to something they expect to succeed to, or specifying
it as an argument to something in lieu of another command they didn't
want to bother with (perhaps an editor or something).

Perhaps `true` should be, `#!/bin/sh` and nothing else, but `exec`
support for invoking interpreters via the `#!` syntax came in 4.1BSD,
well after zero-byte `/bin/true`.

A random thought: some versions of UFS have support for something they
call "fast symlinks".  Symbolic links, of course, are just files that
contain a string naming some other file, and if a pathname has a
component naming a symlink when walked by `namei`, that string is
substituted for the name of the symlink.  But often these names are
very short, and recall that the `inode` contains some space for disk
block addresses (60 bytes in UFS on 4.1C, but this got bigger in later
versions).  The idea with fast symlinks is that, if the target file
name of a symlink is short enough, the system can just store it in the
space that would normally be used for block addresses; there's no need
to allocate a separate fragment from a disk block, let alone bear the
cost of allocating a buffer and fetching a block from disk, if a short
name can be written directly into the inode.

I don't think anyone ever gave serious thought to generalizing this
facility for very small files, but in principle, one could store their
contents in a similar manner (think of all those random little files
that just have a pid in them or something).  In that case, one wonders
what the smallest executable binary implementing `_exit(0)` is.  Some
folks have played around with hacks and gotten very small files
indeed: less than 120 bytes for ELF files, for example, and with
a.out, it would have been even smaller. So, it raises the question:
could one have written a hyper-size optimized version of `true` that
generated a very, very small executable binary that was embedded
directly into its inode in the form of one of these hypothetical short
files, but still executable? I suspect the answer is "yes".

For the record, I don't think this would have any _practical_ utility,
and putting effort into such a thing for real work would be about as
useful as adding a `--false` flag to `true`. But it would be a neat
hack.

On Thu, Sep 25, 2025 at 11:32 PM segaloco via TUHS <tuhs at tuhs.org> wrote:
> On Thursday, September 25th, 2025 at 20:18, Warner Losh via TUHS <tuhs at tuhs.org> wrote:
> > On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS tuhs at tuhs.org wrote:
> >
> > > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS <
> > > tuhs at tuhs.org> wrote:
> > >
> > > > > Heck; at one time the "true" command was a Shell script with a huge
> > > > > copyright notice, followed by... nothing... (The "false" script
> > > > > actually had "exit 1" at the end.)
> > > >
> > > > From http://web.42.net/true.html
> > >
> > > ==========================================================================
> > >
> > > > cat /bin/true
> > > >
> > > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
> > > > # All Rights Reserved
> > > >
> > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
> > > > # The copyright notice above does not evidence any
> > > > # actual or intended publication of such source code.
> > > >
> > > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
> > > >
> > > > I'm not sure what I like most. The fact that they're claiming strict
> > > > copyright on a file that is all comments? The fact that they're up to
> > > > version 1.6 of all-comments, after five years of development? Or the fact
> > > > that the GNU version had to be rewritten (due to the above copyright),
> > > > and
> > > > thus actually offers three times as much functionality?
> > >
> > > ==========================================================================
> > >
> > > > -Jason
> > >
> > > So assuming the whole text of the program after the copyright statement
> > > itself as well as the source control statements is truly AT&T
> > > property...does that mean AT&T lays copyright to the empty file? I jest
> > > but it is an interesting suggestion.
> >
> > I think this credits too much intentionality... but you can't copyright
> > nothing, despite the claims here. There's no creative content.
> >
> > Also, we all know this was done by the sed-o-matic on every file without
> > thinking. So from that perspective, it's not additive to nothing...

I suspect the answer to the original question is "no", as it's really
copyrighting nothing, and ... what would that mean?  Can I claim
copyright over the empty set in mathematics?  Surely there must be a
thing in order to claim copyright over that thing; copyrighting the
absence of a thing makes no sense, and we're back to this notion that
you can't copyright an idea.

This feels like one of those weird "physical reality meets the law"
things, like trying to pass a law banning meteor showers or something
goofy like that.

> I meant more along the lines of a specific disk, a physical instance.  Barring some ability to pursue damages on theft or something, imagine for instance using copyright law to prohibit distribution of some snapshot of a filesystem header, on the grounds that even the directory information has been claimed as under copyright by the owner of that physical piece of media.  Indeed this is in the weeds but just felt like an amusing parallel to the idea of copyrighting an empty file.  It's a construct more than it is original, intentional content.  To oversimplify it, could the output from ls(1) in a directory be copyrighted by the person who happened to type "ls"?

Huh. I don't know about a superblock, but it seems unlikely: a
superblock changes all the time during the course of normal operation.
To what would the copyright apply, other than the SB's state at a
specific instance in time? How is that different than, say, trying to
copyright the position of a flywheel in some mechanical engine at a
specific moment in time?

But it is an interesting question.  IIRC Oracle's licensing terms for
its database product are sort of weird in this regard: they license
for a physical processor, and this has given folks all sorts of
headaches when considering virtualized environments.  A question that
has been raised is whether it's a violation of the licensing terms to
migrate the VM running an instance of Oracle to a separate physical
machine, or even snapshot the VM's (memory) state and write it to a
separate machine, then copy it back and resume it (even if the
snapshot doesn't run).

Questions like that make me glad I'm not a lawyer.

        - Dan C.