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

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

[L A Walsh]

I see 'findmnt' shows a mount if you specify the mount point.

Given the name, I was surprised it didn't already do
this: I was wondering if it could find
the mount point of a file or pathname I give to it?

So if I am in /home/cache/suse, and type:

>  findmnt .

it would tell me something like:

/home[cache/suse] /dev/Space/Home

meaning:
MNTPOINT[offset_path]  <device>

Thanks!

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

[Karel Zak]

On Thu, Mar 11, 2021 at 12:44:01PM -0800, L A Walsh wrote:
> I see 'findmnt' shows a mount if you specify the mount point.
> 
> Given the name, I was surprised it didn't already do
> this: I was wondering if it could find
> the mount point of a file or pathname I give to it?
> 
> So if I am in /home/cache/suse, and type:
> 
> >  findmnt .
> 
> it would tell me something like:
> 
> /home[cache/suse] /dev/Space/Home
> 
> meaning:
> MNTPOINT[offset_path]  <device>


 $ pwd
 /home/projects/util-linux

 $ findmnt --target .
 TARGET SOURCE         FSTYPE OPTIONS
 /home  /dev/nvme0n1p2 ext4   rw,relatime


 man page:

     -T, --target path
              Define the mount target.  If path is not a mountpoint
              file or directory, then findmnt checks the path elements
              in reverse order to get the mountpoint (this feature is
              supported only when searching in  kernel  files  and
              unsup‐ ported  for  --fstab).  It's recommended to use
              the option --mountpoint when checks of path elements are
              unwanted and path is a strictly specified mountpoint.


 I'll prove the beginning of the man page to make this feature more
 obvious.

   Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[L A Walsh]

On 2021/03/11 23:55, Karel Zak wrote:
> $ pwd
>  /home/projects/util-linux
>
>  $ findmnt --target .
>  TARGET SOURCE         FSTYPE OPTIONS
>  /home  /dev/nvme0n1p2 ext4   rw,relatime
>   
----
    Hmmm.  Didn't know about that.  Thanks for the info!  Why does it
produce no output when a non-mount-point is entered?  I.e. -- is that
behavior something that is currently relied upon?

     If not, maybe it could give some indication about an associated mount
of the path that was entered (vs. giving no output)?

    I admit to the desire to have the default case have something do 
something
that is more generally useful, but if people are relying on the empty
output as being a useful indicator of a non-mount-point, wouldn't want to
disrupt that. 

    Either way, thanks!

-linda

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

[Karel Zak]

On Fri, Mar 12, 2021 at 08:48:39PM -0800, L A Walsh wrote:
> On 2021/03/11 23:55, Karel Zak wrote:
> > $ pwd
> >  /home/projects/util-linux
> > 
> >  $ findmnt --target .
> >  TARGET SOURCE         FSTYPE OPTIONS
> >  /home  /dev/nvme0n1p2 ext4   rw,relatime
> ----
>    Hmmm.  Didn't know about that.  Thanks for the info!  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:

 $ findmnt /dev/sda2
 TARGET SOURCE    FSTYPE OPTIONS
 /boot  /dev/sda2 ext4   rw,relatime

 $ findmnt /boot
 TARGET SOURCE    FSTYPE OPTIONS
 /boot  /dev/sda2 ext4   rw,relatime


and if you try it with device which is not mounted

 $ findmnt /dev/sda3

you get nothing, but the same situation with --target:

 $ findmnt --target /dev/sda3
 TARGET SOURCE   FSTYPE   OPTIONS
 /dev   devtmpfs devtmpfs rw,nosuid,noexec,size=8144964k,nr_inodes=2036241,mode=755,inode64

now try to imagine --target is the default, you will get always any
answer for arbitrary path ... IMHO very confusing for many 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
...).

It would be probably better to introduce a small new util "path2fs" to
get mountpoint (or source), but without any other findmnt functionality.

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

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[L A Walsh]

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*!
😱