Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fixing swap1_stop
On Wed, 16 Aug 2017 15:44:24 +0700 Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> | 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.)
Ok, but in that case I think that traditional single-quoting is
actually more suitable. If we $'' the filenames, then we have to make
sure that the filename contains no C-type escapes (or rather, we have
to re-escape all C-type escapes to cancel their meaning). '\v' may be
a stupid two-character name for a Unix directory, but it's a legal one
as far as I know, and it is not equivalent to $'\v' (single vertical
tab character, also legal, even more stupid). To say nothing of
$'\uXXXX' letting you inject arbitrary text into the output. Whereas
'' avoids all of that (except for an embedded single-quote character,
but shquote(3) already takes care of that case). And if we use your
suggestion for a parsing mechanism, then the (single-quoted) output
would get parsed following shell's normal argument-parsing quoting
conventions, so it should all work.
> | 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).
Following Christos' suggestion, the assignment statements are easy:
MY_MOUNTED_DEVICE=$(mount -F %d)
> [...]
>
> | (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.
Good point, thanks for reminding 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.
Fair enough. By contrast, I'm growing wary of designing solutions for
problems I've never seen and therefore don't understand.
I'll try implementing both schemes. Concrete working examples may help
the discussion.
--
IDL
Home |
Main Index |
Thread Index |
Old Index