Rusty Russell wrote:
>    Yes, we've never had the ability to escape quotes (and you're the first to
> ask), so when I wrote this code I kept it simple.  You can have spaced out
> values, but you need to quote the whole thing "param=some value with spaces".
True, but that would leave quotes where they are instead of removing them.

>    We have to be careful not to break existing cmdlines tho: I don't know
> if anyone uses \ currently, but simply interpreting \" is probably safe.
Yes, the only way that compatibility seems to break is that now \" in a quoted
string is replaced by a single ".

> add_token is a weird name for this.  It actually mangles the argument, and it
> really should return the char *.
Fixed.

> How about something like:
> 	static unsigned int pull_token(char *args, const char *delim)
Fixed.

> Which unescapes and returns the length of the token, or zero if it simply
> swallowed delimeters?  Assuming it always nul terminates, then the caller can
> simply do:
> [...]
Fixed.

> Important cases to test are:
> 	x			param = "x", val = NULL
> 	x=			param = "x", val = ""
> 	x=y=1		param = "x", val = "y=1"
> 
> Plus all variations where x and y contain quotes.
Tested:

|param| => [param[(none)]]
|param=| => [param[]]
|param=value| => [param[value]]
|param=value=withequal | => [param[value=withequal]]
|param="value with spaces" | => [param[value with spaces]]
|param="value with spaces and quotes \"" | => [param[value with spaces and quotes "]]
|param=\"foo\" | => [param[\"foo" ]]
|"param = value" | => [param = value[(none)]]

> Cheers,
> Rusty.

Thanks for your kind feedback, I'm willing to put more effort into this when needed. I really
first wanted to check if patches for this are welcomed.

-- 
Mierswa, Daniel

If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do.
               --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22