Re: Fixing swap1_stop

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

On Tue, 15 Aug 2017 02:11:37 -0400 christos%zoulas.com@localhost (Christos
Zoulas) wrote:

> On Aug 14, 10:50am, idleroux%fastmail.fm@localhost ("Ian D. Leroux") wrote:
> -- Subject: Re: Fixing swap1_stop
> 
> | Any preferences for a conveniently-parseable format?  My first
> | instinct is to simply drop the spacer words ("on", "type"),
> | systematically shquote() the device and mount-point and
> | space-separate the flags.  That would look like:
> | 
> | '/dev/wd0a' '/' ffs synchronous local
> | 'tmpfs' '/var/shm' tmpfs nosuid local
> 
> The flags can be complicated (see source code)
> 
> | That's directly parseable in shell (first three fields are device,
> | mount point and fstype, any leftovers are individual flags) and
> | doesn't require the design of another date-style formatting
> | language.  Are there other, better ideas?
> 
> We can specify a format with % escapes for each field...

I was hoping to avoid being guilty of yet another printf-style
mini-language.  But I don't currently have any better ideas, so let's
work this one out.  The filesystem, mount point and device get an
escape each (say %f, %m and %d respectively).  How should the flags be
handled?  One escape for the whole comma-separate flag string (as in
the current output)?  That's easy to implement and manageable to work
with, since the flag names are well-behaved single words that are not
under user control, so they could be parsed with shell globs, something
like:

FLAGS=$(mount -F '%F')
case $FLAGS in
*local*) # do local filesystem stuff 
	;;
*nosuid*)
	;;
esac

Alternatively, each flag could get its own % escape (perhaps one that
expands to "yes" or "no"), but that makes it harder to write a format
string that reproduces the default output.

I don't currently have a use for extracting the flag information (since
my immediate interest is just in getting a reliable mount point name),
so I'm not sure which format is most useful in practice.

--
IDL