coreutils
[Top][All Lists]
Advanced

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

Re: Coreutils enhancement: ls: add colorization of mountpoints


From: Parke
Subject: Re: Coreutils enhancement: ls: add colorization of mountpoints
Date: Tue, 17 Oct 2023 10:05:55 -0700

> On 10/16/23 16:50, Parke wrote:
> > I am contemplating extending ls so that mountpoints can be colorized
> > (via LS_COLORS).

On Tue, Oct 17, 2023 at 2:30 AM Rob Landley <rob@landley.net> wrote:
> But not -F ?

I had forgotten about -F, and I do not use -F.  I am indifferent as to
whether or not mountpoints receive a custom --classify indicator.  I
was not planning on implementing such an indicator.

> > I'm hoping that a mountpoint can be detected by comparing the st_dev
> > fields returned by calling stat() on a directory and on that
> > directory's parent.
>
> --bind mounts exist,

If bind mounts get their own st_dev device id (and they probably do?),
then they would be colored the same as mountpoints.  In my opinion,
this is expected and desired.

> following symlinks with -L could get weird...

Off the cuff, I'd say that the real (dereferenced) parent should be
checked.  (I.e. not the parent of the symlink.  This would result in
additional calls to stat().)

> Once upon a time you could chattr +i on ext2 to nail a file in place

Does chattr +i affect st_dev?  If not, then it is beyond the scope of
what I am proposing.

> Nobody ever said ls showed the full story, and trying to get it to do so is 
> both
> a can of worms and "now the simple posix tool exhibits complex non-obvious
> behavior when we ask simple questions"...

A fair point.  In the context of my personal workflows, being able to
always see Btrfs subvolumes and ZFS datasets (and bind mounts, and
other mountpoints as well) is valuable.

Cheers,

Parke



reply via email to

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