From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] /proc/n/fd format clarification
Date: Mon, 07 Jun 2021 19:37:57 -0400 [thread overview]
Message-ID: <9A682C8A911A12EA44029E0FA2C19F60@eigenstate.org> (raw)
In-Reply-To: <CAHtSCHK8NdHbajVDRMTXLgXRbhsBTT8JYo=gTi_9mdDMdchCWg@mail.gmail.com>
Quoth binary cat <dogedoge61@gmail.com>:
> > I suspect version numbers never go up much in practice.
>
> Sometimes they don't, but they do quite often.
> Every directory I checked had at least one file with a qid version over 9.
> /env was over 1000.
>
> A format that seems to have fixed width fields,
> but actually doesn't, seems like a bad idea.
> I guess it's ok for /proc/n/fd, since the first line will always be
> variable length,
> but it seems problematic for /fd/nctl.
>
> It makes it seem like you could read data from a fixed offset instead
> of parsing the whole file,
> which will work most of the time, but will break if you open a file
> that has been edited too much.
> Imagine a script that works the first 9 times, then breaks. Not a good look.
Do you assume all integers are formatted with
exactly the required number of digits, or are
qids somehow special to you?
> 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.
>
> Either way, I do think the documentation should be clearer about this.
If I get a patch, I don't have objections to
applying it.
next prev parent reply other threads:[~2021-06-07 23:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-05 13:26 binary cat
2021-06-05 21:04 ` [9front] " Anthony Martin
2021-06-05 21:58 ` [9front] " nicolagi
2021-06-07 17:16 ` binary cat
2021-06-07 23:37 ` ori [this message]
2021-06-07 23:46 ` Anthony Martin
2021-06-09 21:24 ` binary cat
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=9A682C8A911A12EA44029E0FA2C19F60@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.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).