Daniel,

> > Because of this, I tried to store this markup in a file instead, and pass
> > this file as the argument to -F:
> >
> > $ curl (url) -F mydata=<./thefile.txt
>
> This probably gets weird since the < letter is treated special by the shell.
> Try putting that whole argument within quotes.

aaah that did the job. thanks :-)

speaking of special shell characters and quoting strings and such, actually I
also have another problem which I couldn't solve yet also kinda related to this,
maybe you know the solution here as well:

I want to pass data arguments to curl using a bash variable instead of supplying
them explicitly. So I defined a variable, like this:

DOCDATA='-F "title=Hello World!" -F "body=Content goes here."'

however, when I now invoke curl with that variable as an argument, like this:
curl (url) $DOCDATA

then I will get curl errors:

Connection #0 to host localhost left intact
* gethostbyname(2) failed for World!"
* Couldn't resolve host 'World!"'
* Closing connection #1
curl: (6) Couldn't resolve host 'World!"'
* gethostbyname(2) failed for goes
* Couldn't resolve host 'goes'
* Closing connection #1
curl: (6) Couldn't resolve host 'goes'
* gethostbyname(2) failed for here."
* Couldn't resolve host 'here."'
* Closing connection #1
curl: (6) Couldn't resolve host 'here."'
* Closing connection #0

it seems that somehow the string gets broken up, but shouldn't enclosing it in
single quotation marks simply pass it to curl as-is, without breaking it up or
interpreting anything inside it?

The odd thing is, when I echo $DOCDATA and copy the output to curl as a direct
argument, then it works!

> > Now I don't get this error anymore, but the temporary file cURL creates
> > for uploading (why does it create temporary files from my input file
> > anyway instead of reading directly from it?)
>
> curl doesn't create a temporary file and it never did.
>

yeah I just figured out it's not curl creating that file but the Apache Commons
FileUpload library I use on the server side to handle multipart requests.

okay , thanks Daniel!
Received on 2008-03-25