bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 5/8] builtins/source: parse the -i option


From: Martin D Kealey
Subject: Re: [PATCH v2 5/8] builtins/source: parse the -i option
Date: Wed, 22 May 2024 10:49:35 +1200

On Tue, 21 May 2024 at 03:44, Chet Ramey <chet.ramey@case.edu> wrote:

> On 5/17/24 1:15 PM, Robert Elz wrote:
>
> >    | If `nosort' means no sorting, there is no imposed ordering, and
> ascending
> >    | and descending are meaningless.
> >
> > Sure, but directory order, and reverse directory order aren't (and that's
> > just a difference between the order in which you create the list as each
> > new dirent is read from the directory - does it go at the head or tail).
>
> That's changing from one random order to another.
>

In the *general* case yes, the order should be treated as random.
For example, readdir on a Linux ext4 fs returns directory entries in
pseudo-random order; this is necessary to allow successive readdir calls to
traverse a large directory, without skipping or repeating an existing
entries, and without locking (so allowing additions, removals, and
renamings to continue). (Connected to this, file positions returned by
lseek(dir_fd, 0, SEEK_CUR) are pseudorandom numbers identifying the next
directory entry to be fetched, not an indication of bytes read so far.)

But it's not *always* random.
For example, readdir on Linux's /proc/$pid/fd returns filedescriptors in
ascending numerical order; likewise readdir on /proc returns process IDs in
ascending numerical order (preceded by a bunch of other stuff, in an order
that's well-defined in the kernel though perhaps not obvious to most users).
Reversing those could be useful to some people.

-Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]