Re: Coreutils enhancement: ls: add colorization of mountpoints

[Rob Landley]

On 10/17/23 12:05, Parke wrote:
>> 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.

Which would be inconsistent behavior.

>> > 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.

They do not, but if it's a bind mount from a different filesystem you would
color it as a mount point, and if it's a bind mount from elsewhere within the
same filesystem you would not, introducing more inconsistent behavior.

>> 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().)

I haven't looked at coreutils' implementation (I'm generally relucatant to look
at GPLv3 source when maintaining a BSD licensed project) but in general -L
selects stat vs lstat so it only does a stat once, and under that implementation
wouldn't -L  make symlinks show up as mount points?

>> 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.

The issue has larger scope than you propose to address, true. Users would have
to understand what subset of the problem space your implementation addresses in
order to understand the tool's output. I.E. we'd have to know how the code is
written to use it.

Right now ls is reporting the readdir()/stat() output, with any overlays on that
being the user's problem. Inconsistently automating specific special cases on
top of that does not seem like it would make life simpler.

>> 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.

grep $PWD /proc/mounts

Rob

P.S. Yeah yeah, modulo percent escapes in proc strings mapping to the need to
quote $PWD... linux/fs/proc_namespace.c:show_vfs_mount() does seq_path_root(m,
&mnt_path, &p->root, " \t\n\\") which is a wrapper for mangle_path() in
linux/fs/seq_file.c which is doing:

                        *s++ = '\\';
                        *s++ = '0' + ((c & 0300) >> 6);
                        *s++ = '0' + ((c & 070) >> 3);
                        *s++ = '0' + (c & 07);

which implies you can just echo -e to get it back, so TECHNICALLY you may want a
small shell script:

awk '{print $2}' /proc/mounts | while read i; do echo -e "$i"; done | \
  grep -F "^$(readlink -f .)"

which seems most useful for piping the output into "xargs -d '\n' umount" since
"umount -R dir" isn't a thing. (Yet.)