The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: norman@oclsc.org (Norman Wilson)
To: tuhs@tuhs.org
Subject: Re: [TUHS] A question about ls(1)
Date: Sun, 28 Apr 2019 12:54:52 -0400 (EDT)	[thread overview]
Message-ID: <20190428165452.9BB414422F@lignose.oclsc.org> (raw)

Bakul Shah:

  This could've been avoided if there was a convention about
  where to store per user per app settings & possibly state. On
  one of my Unix machines I have over 200 dotfiles.

====

Some, I think including Ken and Dennis, might have argued
that real UNIX programs aren't complex enough to need
lots of configuration files.

Agree with it or not, that likely explains why the Research
stream never supplied a better convention about where to
store such files.  I do remember some general debate in the
community (e.g. on netnews) about the matter back in the
early 1980s.  One suggestion I recall was to move all the
files to subdirectory `$HOME/...'.  Personally I think
$HOME/conf would have been better (though I lean toward
the view that very few programs should need such files
anyway).

But by then BSD had spread the convention of leaving
`hidden' files in $HOME had spread too far to call
back.  It wouldn't surprise me if some at Berkeley
would rather have moved to a cleaner convention, just
as the silly uucp-baud-rate flags were removed from
wc, but the cat was already out of the bag and too
hard to stuff back in.

On the Ubuntu Linux systems I help run these days, there
is a directory $HOME/.config.  The tree within has 192
directories and 187 regular files.  I have no idea what
all those files are for, but from the names, most are
from programs I may have run once years ago to test
something, or from programs I run occasionally but
have no context I care about saving.  The whole tree
occupies almost six megabytes, which seems small
by current standards, but (as those on this list
certainly know) in the early 1980s it was possible
to run a complete multi-user UNIX system comfortably
from a single 2.5MB RK05 disk.

Norman Wilson
Toronto ON

             reply	other threads:[~2019-04-28 16:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 16:54 Norman Wilson [this message]
2019-04-28 19:45 ` Jon Forrest
2019-04-28 20:00   ` Bakul Shah
2019-04-29 18:05     ` Michael Kjörling
2019-04-29 20:37       ` Warner Losh
2019-04-29 20:44       ` Christopher Browne
2019-04-30  6:44         ` Michael Kjörling
2019-04-30  7:24           ` Kurt H Maier
2019-04-30 10:35             ` Wesley Parish
2019-04-29 22:32       ` Bakul Shah
2019-04-30 11:52         ` Theodore Ts'o
2019-04-28 22:16   ` Thoma Paulsen
2019-04-29  0:53     ` John P. Linderman
  -- strict thread matches above, loose matches on Subject: below --
2019-04-27 23:03 Noel Chiappa
2019-04-27 20:11 Norman Wilson
2019-04-27 14:16 Anthony Martin
2019-04-27 15:38 ` Warner Losh
2019-04-27 15:42   ` Larry McVoy
2019-04-28 23:59   ` Warner Losh
2019-04-28 11:47 ` Dan Cross
2019-04-28 12:00   ` arnold
2019-04-28 14:44   ` jcs
2019-04-28 16:15   ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190428165452.9BB414422F@lignose.oclsc.org \
    --to=norman@oclsc.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).