From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6817 invoked from network); 7 Jun 2021 23:51:49 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 7 Jun 2021 23:51:49 -0000 Received: from MTA-10-1.privateemail.com ([68.65.122.30]) by 1ess; Mon Jun 7 19:46:38 -0400 2021 Received: from MTA-10.privateemail.com (localhost [127.0.0.1]) by MTA-10.privateemail.com (Postfix) with ESMTP id 05734600DC for <9front@9front.org>; Mon, 7 Jun 2021 19:46:34 -0400 (EDT) Received: from localhost (unknown [10.20.151.227]) by MTA-10.privateemail.com (Postfix) with ESMTPA id 2C6F2600BD for <9front@9front.org>; Mon, 7 Jun 2021 19:46:33 -0400 (EDT) Date: Mon, 7 Jun 2021 16:46:21 -0700 From: Anthony Martin To: 9front@9front.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: mobile scale-out dependency realtime browser STM locator Subject: Re: [9front] /proc/n/fd format clarification Reply-To: 9front@9front.org Precedence: bulk binary cat once said: > A format that seems to have fixed width fields, but actually doesn't, > > [...] > > Either way, I do think the documentation should be clearer about this. Fixed width fields are called out explicitly in the manuals whenever they're used, as in draw(3), Each client of the device connects by opening /dev/draw/new and reading 12 strings, each 11 characters wide followed by a blank: or acme(4), When read, it returns the value of the address that would next be read or written through the data file, formatted as 2 decimal numbers m and n, each formatted in 11 characters plus a blank. or font(6), Each number is right-justified and blank padded in 11 chara- cters, followed by a blank. and so on. Assuming something that isn't actually written down in the documentation is not a good idea. > What I would do is keep the qid version as decimal (for backward > compatibility), but simply pad it enough (10 spaces) so it's fixed > width, like the rest of the fields. This would mean you wouldn't have > to read through the whole file to get the filename. This still wouldn't work since the third field, the type, is a single UTF-8 encoded Unicode rune which is not a fixed width. Cheers, Anthony