Re: Fixing swap1_stop

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 15 Aug 2017 21:19:00 -0400
    From:        "Ian D. Leroux" <idleroux%fastmail.fm@localhost>
    Message-ID:  <20170815211900.e483cf4b0ec260b798d08b13%fastmail.fm@localhost>

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

To be able to mount back to current state after a reboot, or just as
a record of what was done.   And as a fairly clean way to be able to
extract any data from mount output.

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

Most other shells have it these days, and it is likely to be added to
posix, it is almost identical to '' quoting, except allows all the normal
C type escapes (\ sequences) to be used in the string (with the same meanings
they have in C) - so $'\n' is a newline char, and $'\u6666' is (perhaps,
I did not look it up) some unicode code point (in sh it would resolve to
the UTF8 (or perhaps current locale) representation.)

[Aside, usual shell word rules all apply of course, so things like
	"${VAR}"$'\n'"${OTHERVAR}"
makes one sh word with the expansions of two variables separated by a \n.]

  | 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.

Not really, to extract the mount info you are always going to need some
kind of sh code, the simplest would perhaps be if mount emitted sh type
assignment statements - but that starts getting very complicated (are the
var names fixed, or are they passed in to mount, for example).

  | 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".

The assumption was that was done before the mount function was defined
(if we, or anyone, had local functions, then this special mount function
would probably be local to a parse function.)

  | Both meanings must be simultaneously in scope

No, that's not needed, in general, but in cases where it is ...

  | (which you can probably do by always giving the
  | full path /sbin/mount when you mean the binary

That would just be "command mount" - the command command exists just for
this purpose.

Alternatively of course, the output could just have the "mount" word
omitted - that does make it easier to process, but not a lot, as
	sed 's/^/whatever /' | ...
is simple enough, so to execute the output as mount commands
	mount -p >file
(time passes)
	sed < file 's/^/mount /' | sh
works.

But that then gets harder to use the info in a script, you cannot just

	. file

and be able to get the data.

There is no real need for the command name emitted to be "mount" of course,
it could be "mounted" or "mnt" (or passed as an arg, as in "mount -p mnt")
and then used with

	mnt() { mount "$@" ; }

or whatever else is appropriate.

  | Could you explain why you prefer this output format?

It is the cleanest I can think of, and by definition is able to express
everything that the mount command can handle.

  | What problem do you hope that it solves?

All of them...   That is the point, if there is something that cannot be
done, then we would need a different approach.

  | As a solution to my problem
  | (stopping /etc/rc.d/swap1 from unmounting essential filesystems), it
  | smells over-complicated to me.

I like to find more general solutions, that are more likely to be more
useful for other purposes into the future, than just build things one
hack at a time whenever someone discovers a new need.

kre