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.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, 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 f00feba3 for ; Wed, 26 Jun 2019 01:13:21 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 3825B9BDDF; Wed, 26 Jun 2019 11:13:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8C9129BD79; Wed, 26 Jun 2019 11:13:07 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=algebras-org.20150623.gappssmtp.com header.i=@algebras-org.20150623.gappssmtp.com header.b="1xHl/eLV"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9A26B9BD79; Wed, 26 Jun 2019 11:13:05 +1000 (AEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by minnie.tuhs.org (Postfix) with ESMTPS id CE6AE9BD16 for ; Wed, 26 Jun 2019 11:13:01 +1000 (AEST) Received: by mail-io1-f68.google.com with SMTP id h6so1369222ioh.3 for ; Tue, 25 Jun 2019 18:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=B2/n97NodfKpESRpRRkRXhYleHsU0vEuJCuxh9RbEhE=; b=1xHl/eLVmtnM+lqEsI40oQVi58TitBE0ntE+D1WeyV5oG5Jfg9bHmFqFm0x4wl/iSP W2NNPJJ3/SPGcb1UWW24hV8FKoi6pezLtkHQbDm+dCBfLPJog6gdO53GKmsy+vVSderi mNx2YRaUAFgcvnIQwnGJ0yLRITEmGEMVhNharlIKY9Cmo9h5CYcpjMAXEI/9KtuKK4Bn lynETgUHhAMZg91r94lHpz0h4VD0Wr/v+4QdsACCcrSsSHjU9GkaI5KM/6ah6kd2kqBm bwmWHSFlQ9T3aBpomQ7awXfNPVQsaxdqCkNxb6RR81HBHPwAOTuqfvtYmXNTWq+b/i6v YZtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=B2/n97NodfKpESRpRRkRXhYleHsU0vEuJCuxh9RbEhE=; b=YhmCYmS0NmLwb/+wzyhr6xdTtt78IrgI5RvJvZmU3f7O6KQKTiUEsz1ugaIcadbT8z shJJhVW1fyaP+2eaERmBmbwONxb/Onse97MRstNZ6n88AaFhW4hlulSDN+tCfcAQDoYZ FtsG0QwT2gINg9n2x+P3AjHwlZ/BTWLA+3KqDyG0UtcyKIb7XugNah1bhK4hYHRF0J0D /ys82a7xTEDiQuxTe8smwHZRB4uByJh+zjF+fNAe0OSID5W5hCCfJGUnwr78uey9+VRS BQoQkVrj8PubZCwihaT/qmJ6Jtiz9zzYolAsBMtW5IHZDq5HjRkYTEtBO1skuvR408JS OJ8g== X-Gm-Message-State: APjAAAUiTFyyYoTlZ8P52sqYbUvn1W0mZOxSIZ0eTnCpNYqhGZRPdNg8 WYbLluneUtBNl8f1j8e66HzFkyKWkSOsbUFH9+KTVghiXHY= X-Google-Smtp-Source: APXvYqye0GZcXD9Friwy8AJOxBSvi44b471dstGXRed2tEOtJabrWrQO0RRJxlyEkr1WUB9SmmBbwNQRmZbGdkScMxw= X-Received: by 2002:a5d:885a:: with SMTP id t26mr1803010ios.218.1561511580933; Tue, 25 Jun 2019 18:13:00 -0700 (PDT) MIME-Version: 1.0 References: <1561491205.19116.for-standards-violators@oclsc.org> <20190626004603.GG925@mcvoy.com> In-Reply-To: From: George Michaelson Date: Wed, 26 Jun 2019 11:12:49 +1000 Message-ID: To: The Eunuchs Hysterical Society Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane") 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" The lack of consistency in what you can READ in /proc makes it hard to believe its useful in the "wide" -but I am sure specific things get benefit from it, as an abstraction which makes code simple because "its a file" if you're WRITING into things in /proc, I think you own the pain be it an ioctl() or anything else. I see occasional shell scripts about turning on and off meta-state for SCSI or SAS as "cat 0 > /dev/somedir/some-model-of-abstraction/some-disk" and while I applaud, I also wince. So easy to go wrong.. As a long-term user and non-developer, I'm sort of half a believer, half not. Maybe if it had emerged before the great Schism(s) it would be more normal? sane? understandable? -G On Wed, Jun 26, 2019 at 11:04 AM ron minnich wrote: > > On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy wrote: > > > > I'm curious what Rob and others think of the Linux /proc. It's string > > based and it seems like it is more like /whatever_you_might_want. > > it's very handy but quite difficult to work with programatically. The > output is convenient for humans to parse, not very nice for programs > to parse. > > /proc on linux has no real standard way of outputting things. You get > tables, tuples, and lists and some stuff I can't classify > (/proc/execdomains, /proc/devices); and, in some cases, some files > give you more than one type of thing. Units are not clear for many > tables. > > /proc on linux has far more than just process information, including > stuff that has nothing to do with processes (51 things on my current > linux, e.g. /proc/mounts). > > Things are in many cases not self-describing, though lots of /proc > have this issue. > > I do recall (possibly wrongly) at some point in the 2000s there was an > effort to stop putting stuff in /proc, but rather in /sys, but that > seems to have not worked out. /proc is just too convenient a place, > and by convention, lots of stuff lands there. > > While I was at LANL we did experiment with having /proc come out as > s-expressions, which were nicely self describing, composable, easily > parsed and operated on, and almost universally disliked b/c humans > don't read s-expressions that easily. So that ended. > > We've been reimplementing Unix commands in Go for about 8 years now > and dealing with all the variance in /proc on linux was a headache. > You pretty much need a different function for every file in /proc. > > And all that said, it's handy, so hard to complain about too much.