Re: [Chicken-hackers] [patch] utils: qs not escaping pipes

[Michele La Monaca]

The provided patch is my attempt at improving qs. The new
backward-compatible signature is:

(define (qs str #!optional (platform (build-platform)) (escape-mode #f))

If escape-mode is false (default) qs acts in "quote-mode":
double-quotes for mingw32, single-quotes for other platforms.

> (display (qs "foo bar" 'not-mingw32))
'foo bar'

> (display (qs "foo bar" 'mingw32))
"foo bar"

if a single/double quote is present, it is escaped this way respectively:

> (display (qs "foo'bar" 'not-mingw32))
'foo'\''bar'

> (display (qs "foo\"bar" 'mingw32))
"foo"""bar"

If a '%' sign is present in mingw32 an exception is raised since
expansion of variables (e.g %PATH%) is not prevented by double-quotes.


In escape-mode strings are backslash-escaped (not-mingw32 platforms)
or caret-escaped (mingw32):

> (display (qs "foo&bar" 'not-mingw32 #t))
foo\&bar

> (display (qs "foo&bar" 'mingw32 #t))
foo^&bar

While backslash-escaping is equivalent to its corresponding quoting,
the same is not true for caret-escaping. Depending on the context one
is more appropriate than the other. AFAICT the "general" rule is to
use double-quoting for pathnames and caret-escaping for textual
strings. For example, caret-escaping is your friend when using the
echo command:

# echo ^%PATH^%
%PATH%

As regarding backslash-escaping I changed the list of escaped
characters in this way:

1) added the characters '|' '=' '^' ','
2) removed the charater '%'. I don't see a good reason to escape it. Am I wrong?
3) removed a non ASCII character (0xb4). Why it was there?

If you see missteps or ways to improve please raise your hands. As you
may guess, this is really a tricky subject.

Regards,
Michele


On Tue, Feb 19, 2013 at 11:07 PM, Michele La Monaca
<address@hidden> wrote:
> On Tue, Feb 19, 2013 at 10:09 PM, Peter Bex <address@hidden> wrote:
>> Why?  What does it buy us?  The only reason 'qs' is available is to
>> safely escape arbitrary strings for the shell.
>
> Suppose you want to implement some kind of command-line completion. In
> this case backslash-escaping is a better fit, I think.
>
>> I think the new version does a good job at this.
>>
>> Why should we provide a known-broken version?
>
> Backslash-escaping is not broken per se. Let's say it's more difficult
> to implement and the current implementation is not just there.
>
> Regards,
> Michele

0001-tentative-improved-qs-function.patch
Description: Binary data