From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 57e8ea07 for ; Mon, 29 Apr 2019 18:14:45 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5BD0E9B61C; Tue, 30 Apr 2019 04:14:44 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 7E334948F1; Tue, 30 Apr 2019 04:14:14 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9116D948F1; Tue, 30 Apr 2019 04:14:11 +1000 (AEST) X-Greylist: delayed 524 seconds by postgrey-1.36 at minnie.tuhs.org; Tue, 30 Apr 2019 04:14:10 AEST Received: from ste-pvt-msa2.bahnhof.se (ste-pvt-msa2.bahnhof.se [213.80.101.71]) by minnie.tuhs.org (Postfix) with ESMTPS id 76FCE948F0 for ; Tue, 30 Apr 2019 04:14:10 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id BE0733F7C1 for ; Mon, 29 Apr 2019 20:05:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDpgkMTcf4vh for ; Mon, 29 Apr 2019 20:05:14 +0200 (CEST) Received: from h-174-65.A328.priv.bahnhof.se (h-174-65.A328.priv.bahnhof.se [81.170.174.65]) (Authenticated sender: mc179410) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 682793F7BA for ; Mon, 29 Apr 2019 20:05:14 +0200 (CEST) Received: from h-174-65.A328.priv.bahnhof.se (localhost [127.0.0.1]) by h-174-65.A328.priv.bahnhof.se (Postfix) with ESMTPS id 0B5462E55C7 for ; Mon, 29 Apr 2019 20:05:14 +0200 (CEST) Date: Mon, 29 Apr 2019 18:05:12 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: tuhs@minnie.tuhs.org Message-ID: <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> References: <20190428165452.9BB414422F@lignose.oclsc.org> <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [TUHS] A question about ls(1) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 28 Apr 2019 13:00 -0700, from bakul@bitblocks.com (Bakul Shah): > IMHO separate files are fine but it would've been nice to > a) have a place other than $HOME to store these files and XDG already does that. At least Norman already mentioned ~/.config in this thread. https://www.freedesktop.org/wiki/Software/xdg-user-dirs/ Not sure how common that is on non-Linux systems, but it seems pretty common on modern Linux distributions. My workstation Debian system has a staggering 3467 files in that directory, spread around 444 directories (75 directories directly under ~/.config). Plus another 142 dot-directories and 66 dotfiles in ~/. Now, ~/.config typically uses multiple files per application, and at a glance there's some stuff there that could definitely go, but I still shudder to think of having all of those directly under ~/, so it's clearly doing _some_ good in that regard. And that's to not even begin to talk about all the stuff you'll find in /etc on a modern Linux system. > b) a standardized plain text format I'm not sure about that; different applications have very different needs, and trying to shoehorn one into another would be ugly; quite possibly even more ugly than just having different formats. Imagine trying to write mail sorting recipies (think procmail) in a file with the same format as that of one holding word processor settings or an image metadata store. I guess that's half-way tolerable on Windows because next to nobody edits the settings directly anyway, but on a system where many such files are sometimes, or often, edited directly by the user, it might well hinder more than it helps. I guess you _could_ go with something like XML or JSON, but that's a bit like saying "all cars should have an engine and a refillable fuel store", in that it doesn't actually standardize anything _meaningful_ (in both of those cases, the magic is in the schema, not the format). Lists of examples not intended to be exhaustive. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor)