From: L A Walsh <lkml@tlinx.org>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: is there a util, or can findmnt be enhanced...(RFE?)
Date: Mon, 15 Mar 2021 12:29:37 -0700 [thread overview]
Message-ID: <604FB5A1.3010404@tlinx.org> (raw)
In-Reply-To: <20210315110221.fpz66zkpwqp6ebva@ws.net.home>
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*!
😱
prev parent reply other threads:[~2021-03-15 19:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 20:44 is there a util, or can findmnt be enhanced...(RFE?) L A Walsh
2021-03-12 7:55 ` Karel Zak
2021-03-13 4:48 ` L A Walsh
2021-03-15 11:02 ` Karel Zak
2021-03-15 19:29 ` L A Walsh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=604FB5A1.3010404@tlinx.org \
--to=lkml@tlinx.org \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.