All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Xose Vazquez Perez <xose.vazquez@gmail.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH v2 3/5] libmultipath: config parser: Allow '"' in strings
Date: Fri, 23 Mar 2018 18:40:15 +0100	[thread overview]
Message-ID: <1521826815.13100.67.camel@suse.com> (raw)
In-Reply-To: <e505286a-9dbf-969a-f638-7de33262067c@gmail.com>

On Fr, 2018-03-23 at 17:59 +0100, Xose Vazquez Perez wrote:
> On 03/08/2018 12:26 AM, Martin Wilck wrote:
> 
> > We have seen model strings lile '2.5" SSD' which can't be parsed
> > by the current config parser. This patch fixes this by allowing
> > '""' to represent a double quote character inside a a string.
> > The above model string could now be entered in the config file like
> > this:
> > 
> > blacklist {
> > 	  vendor SomeCorp
> > 	  product "2.5"" SSD"
> > }
> 
> 
> Could this work in the first place?
> 
>           product "2.5\" SSD"

I'm not sure what you mean. For the current code, the answer is "no".
The parser doesn't treat '\' special in any way. For the parser, the
result of the above is the tuple ['product', '2.5\', 'SSD']. The config
file parser would discard the last tuple element (the cli command
parser takes more than 2 tuple elements, but not the config file
parser). The regexp parser would bail out on the lone backslash in
'2.5\'.

If you meant to say that, instead of using '""', I could have changed
the parser to use '\"' to represent a single double-quote character,
yes, that would have been possible, at the cost of a much bigger and
more error-prone rewrite of the parsing code.

Moreover, I think using '\"' has an addtional disadvantage compared to
'""'. As you know, the values for many options are regular expressions,
and the backslash has special meaning in regexps. Figuring out the
correct number of backslashes for complex regexps is hard anyway, and
if we give '\' special meaning in the option parser, too, we'd treat it
specially on two separate layers, making it even harder for users. The
double-quote character, OTOH, has no special meaning in regexps, so
that the two quoting mechanisms on the two layers are orthogonal.

Regards
Martin

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2018-03-23 17:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 23:26 [PATCH v2 0/5] Fixes for config file parsing Martin Wilck
2018-03-07 23:26 ` [PATCH v2 1/5] tests: add unit tests for config file parser Martin Wilck
2018-03-07 23:26 ` [PATCH v2 2/5] libmultipath: config parser: don't strip whitepace between quotes Martin Wilck
2018-03-07 23:26 ` [PATCH v2 3/5] libmultipath: config parser: Allow '"' in strings Martin Wilck
2018-03-23 16:59   ` Xose Vazquez Perez
2018-03-23 17:40     ` Martin Wilck [this message]
2018-03-07 23:26 ` [PATCH v2 4/5] libmultipath: config parser: fix corner case for double quotes Martin Wilck
2018-03-07 23:26 ` [PATCH v2 5/5] multipath.conf(5): improve syntax documentation Martin Wilck
2018-03-14 17:41 ` [PATCH v2 0/5] Fixes for config file parsing Benjamin Marzinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1521826815.13100.67.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=dm-devel@redhat.com \
    --cc=xose.vazquez@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.