Speediest response as ever Niphlod!
Yes I understand your point. The reason it is currently like this is
because if I use your suggestion (which I obviously had originally)
{"id": 1, "method": "savemessage", "params": { "*message*":
"variableholdingmessage", "*uid*" : "variableholdingmail"}}
I get message and uid as the values in the DB. So I switched them.
{"id": 1, "method": "savemessage", "params": { "variableholdingmessage":
"mymessage", "variableholdinguid" : "myemail@localhost"}}
The result means that variableholdingmessage is saved as the message and
not the expected "mymessage". Exactly the same for uid.
re: PS -- haha yes I know. I did try it with single quotes and it crapped
out?? So just kept the doubles. It's not that bad!
re: PS2 -- have you any recommendations to solve this special character
potential problem?
On 14 November 2012 15:04, Niphlod <niph...@gmail.com> wrote:
> you are using the wrong order....you have to send something like
>
> {"id": 1, "method": "savemessage", "params": { "*message*":
> "variableholdingmessage", "*uid*" : "variableholdingmail"}}
>
> *message* and *uid* are the named parameters to your function def
> savemessage(*message, uid*)
> and instead you are composing
>
> {"id": 1, "method": "savemessage", "params": { "variableholdingmessage":
> "mymessage", "variableholdinguid" : "myemail@localhost"}}
>
> PS: you are using probably the overcomplicated quoting style ever :P
> try with this
>
> -d '{"id": 1, "method": "savemessage", "params": { "message": "'$message'",
> "uid" : "'$uid'"}}' $url
>
> PS2: relying on a vanilla bash variable for passing around json parameters
> is a bad idea. What if your message includes a ' symbol ? e.g. "Let's
> rock".... The json equivalent is "Let\'s rock"...
>
>
>
> --
>
>
>
>
--
