Re: is there a util, or can findmnt be enhanced...(RFE?)

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

 



Sorry, thought this was something simple, but when I thought
about it I ended up with a few more details 😓

On 2021/03/15 04:02, Karel Zak wrote:
 On Fri, Mar 12, 2021 at 08:48:39PM -0800, L A Walsh wrote:
> Why does it
> produce no output when a non-mount-point is entered?  I.e. -- is that
> behavior something that is currently relied upon?

 Do you mean the default output (when --target is not specified)?

 The problem is that findmnt follows mount(8) behavior when search for
 filesystem. It means you do not have to be explicit and you can use
 source as well as target...
---
 Note: commenting from mount manpage:

|   For more robust and customizable output  use  findmnt(8),  espe-
|   cially  in  your  scripts.   Note that control characters in the
|   mountpoint name are replaced with '?'.
---
 I.e. "findmnt" was created because the behavior of 'mount' was
lacking. 😉   In 'mount', if you give a non-mount point, you get
mount's idea of useful:

 mount: /dev/sda: can't find in /etc/fstab
 mount /home/karel: can't find in /etc/fstab

 Since findmnt was created because the output of 'mount' is
lacking, findmnt shouldn't need to push off output to another
util because it, itself is lacking! 😟

Ex:
 $ findmnt --target /dev/sda3
 TARGET SOURCE   FSTYPE   OPTIONS
/dev devtmpfs devtmpfs
rw,nosuid,noexec,size=8144964k,nr_inodes=2036241,mode=755,inode64
----
   1st comment: unix philosophy, less is more: findmnt should only
list headers when asked for them.  Two reasons:  Since the output
doesn't fit on 1 line, it will be wrapped and will be confusing
for interactive use, and for script use -- they don't need it and
can adjust output for exactly what they want.  Usually, headers
need removing so data fields can be processed.

   2nd comment -- options should remain optional and not
listed by default (use --verbose to display all options).

   2a) default options should be suppressed by default (else
--expand-defaults could be used if really needed).  At most, display
'default' for an actual mountpoint (+ deltas from default)

  3rd comment -- don't truncate by default, but do allow
field width specifiers (%.20SOURCE\t %.30TARGET...).  To
truncate, maybe have -w[maxwidth], with default being screen
width if to tty?


 now try to imagine --target is the default, you will get always any
 answer for arbitrary path ... IMHO very confusing for many users.
---
 Honestly, isn't the default output likely confusing for many
users?  😉  Alternatively,

if device w/mount point, show:

# findmnt /dev/sdb
/dev/sdb1   [not] mounted on  /boot
# findmnt /boot
/dev/sdb1   [not] mounted on  /boot

(i.e. ^^ keep same behavior of allowing dev or /mntpnt)

if device w/no mountpoint in /etc/fstab, then same as 'mount':

# findmnt /dev/sda
findmnt: /dev/sda: can't find in /etc/fstab

if not device and not mountpoint (I'm not 100% certain about
the exact text, but something like):

# findmnt /boot/sbin/v86d
sbin/v86d   in /boot      (/dev/sdb1)
 -or-
/boot/[sbin/v86d]   on    /dev/sdb1

Or if format specified, for above 2:
# findmnt --format "%-40SUBPATH in TARGET\t(SOURCE)
# findmnt --format "TARGET/[SUBPATH]\ton\tSOURCE"


Having 'no output' for the default, is also a bit
confusing for users



 I have doubts we can change this default behavior due to backward
 compatibility (yes, the proper way how to use findmnt in scripts is to
 use --target, --sources or --mountpoint, but people do not use it
 ...).
---
 That's just the thing... who/what could be relying on "no output"?



 It would be probably better to introduce a small new util "path2fs" to
 get mountpoint (or source), but without any other findmnt functionality.
---
See comment about why findmnt was needed in the 1st place... 😁


 We have mountpoint(1), but it returns TRUE/FALSE if the given path is
 a mountpoint.
---

 Ya, sorta unrelated, but that's where "no output" might be
expected since it's only used for its return value, but I can't
see how findmnt would be similarly used...

*cheers*!
😱





[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux