Date: Tue, 16 May 2017 07:41:43 +0100
From: Stephane Chazelas <stephane.chaze...@gmail.com>
Message-ID: <20170516064143.ga3...@chaz.gmail.com>
| Or just write it as quote() (...) instead of quote() { ...;}
Yes, as you would have seen later, I mentioned that in a subsequent
message.
| That doesn't work properly in POSIX shells.
Hmm, yes you're right (I did say it might not be bug free and had not
been tested much) - but that's relatively easy to fix, and does not
need ...
| Here, I'd fire awk and quote more than one arg at a time:
Hmm - you're really aiming for maximum sluggishness... I could beat that
by just adding a couple of sleeps ...
And if I wanted slow, but not quite that slow, I'd much prefer sed to
awk for generic string processing - but (I assumed) that the aim here would
be to produce something quick enough to use frequently, and for most
relatively simple string processing, which doesn't need REs, what the
shell offers is just fine.
I deliberately did not do multiple arg quoting, as what you want in
that case depends upon the application, just quoting each separately
is not necessarily the desired result. And given the ability to quote
a single string, adding the mechanism to quote multiple strings is
not very hard ...(call the function over and over) and you get to
deal with the multiple results in whatever way your application needs.
WHat is clightly harder to fix, but can be done if you really wanted it,
is to omit redundant (quoting) 's in the result, so we don't end up
with stuff like
'a'\'''\'''\''b'
when
a\'\'\'b
is all that is really needed... If the aim is just, as was originally
stated (save & restore,) then it doesn't matter, but if you are ever
going to show the result to a human, it does.
| Using LC_ALL=C on the assumption that the encoding of ' (0x27 in
This is the shell, there is exactly one single quote character, and it
is that one. The data can be anything, the characters used in the
syntax elements cannot. Nor do non-ascii chars ever expand to anything
or have any meaning different from themselves as a data char.
If we start having shell parsing differently depending on what locale the
user happens to be using, we may as well all give up now, and go find
something else to do.
| Also note that if $IFS was previously unset upon calling your
| quote() (as is common when you want to restore splitting to its
| default behaviour), it would leave it assigned an empty value
| (which means "no splitting").
Yes, mentioned that in my following message too.
stephane.chaze...@gmail.com in another message said:
| No, the split+glob operator that is done upon unquoted parameter expansion
| (or command substitution or arithmetic expansion) is completely different
| from the shell syntax parsing. It is not affected by quotes.
I'm not sure what point you were making there, but all I was saying was
that in my original (test, not in the function) I did
y=$(quote $x)
(by accident, I normally quote everything.) That version doesn't
work properly at all - of course (depending upon what $x expands to
of course). When quoted ("$x") it does work. That is, when quoted
like this the value of $x is certainly a single arg to the quote
function, and any glob meta chars in it will just be themselves,
not expanded as file names, which the unquoted version would do.
kre
