Re: Fixing swap1_stop

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

On Tue, 15 Aug 2017 16:20:41 +0700 Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
>   | Any preferences for a conveniently-parseable format?
> 
> I'd prefer to omit sh commands that will cause the mount to be
> performed, so that the filesystem returns to its current state.

What's the use-case for this?  If I want the filesystem to be mounted
in its current state, I do nothing.

>   | That would look like:
>   | 
>   | '/dev/wd0a' '/' ffs synchronous local
>   | 'tmpfs' '/var/shm' tmpfs nosuid local
>   | 
>   | That's directly parseable in shell
> 
> How?   What sh code would you use to read that and make it useful,

My mistake.  I thought that "read" follows the usual shell quoting
rules.  It doesn't, so this won't work as well as I'd hoped.

> and don't forget the case where the device or mount point contains a
> ' or a newline char.

I hadn't (in the sense that shquote(3) deals with both of these cases),
but I (and shquote(3)) assume the usual shell quoting rules (where single quotes
can protect newlines), which won't work with read.

> I'd prefer
> 
> 	mount -t ffs -o synch,local $'/dev/wd0a' $'/'
> 
> (where the quoting can be omitted when, as here, it is not needed),
> but this would require $'' support in sh first (we want that rather
> than just '' quoting so weird chars, like newlines and single quotes,
> can be included without making life difficult).

I've never seen $', what is its intended meaning?

> Then if you want to perform the mount, you just run that line as a sh
> script.
>
> On the other hand, if you want to find what is mounted where, you
> first just define
> 
> 	mount()
> 	{
> 		shift $(($# - 2 ))
> 		DEVICE="$1"
> 		MOUNTPOINT="$2"
> 	}

This feels backwards to me.  It seems to be optimized for making it
easy to run a mount command that does nothing, whereas actually
extracting information about the existing mounts (which, to my mind, is
the main use-case for this feature) now requires you to redefine a
basic command and do a dance.  The dance is, incidentally, a bit more
complicated than you show since we still need to be able to run
"mount -p" in order to generate the output which will then be executed
using your new, different, meaning for "mount".  Both meanings must be
simultaneously in scope (which you can probably do by always giving the
full path /sbin/mount when you mean the binary and the bare command
name when you mean the shell function, but that clashes with the
typical styles of the rc.d scripts).

Could you explain why you prefer this output format?  What problem do
you hope that it solves?  As a solution to my problem
(stopping /etc/rc.d/swap1 from unmounting essential filesystems), it
smells over-complicated to me.

-- IDL