At present you can't use a username that contains a colon - it's a known limitation that has partially been discussed in the past.
I believe, and I could be wrong here, that a password can contain a colon.
The last discussion was December 2013, relating to some changes I had made roughly this time last year where I added options support in --user and broke passwords containing semi-colons. As such the following thread may be of interest:
...where Daniel and I discussed adding separate command line arguments so we can specify the username and password individually thus allowing such characters in each.
Your bug reported has reminded me that we still haven't done this so I will add it to my to do list for the next release.
Kind Regards
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps we can hijack the --pass argument for this? If the username or password contains a colon, you have to use --user and --pass separately. Then we can use colons in the --user argument.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
my primary complaint was the lack of documentation. whatever you do (even if nothing), please document the available options in curl(1).
the suggestion from Daniel to put them in the url is workable but complicates my code, prompting deliberations to move away from curl to something else.
Linus Nielsen's comment re --pass is almost attractive but i'm suspicious of changing the grammar of an existing option (the interpretation of --user optarg changes with the absence/presence of --pass).
i would deprecate (not remove!) --user in favor of a new option, let's say --login. keep --user as is, return ; into the password character set, whatever. --user shapeshifts too much, i can't really use it in my code with user-supplied strings. it is broken, i don't want to use it at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm hoping to implement this, this weekend and was wondering:
1) --password is quite an obvious long option to use for password but do we need a short option? Unfortunately, -p and -P are already taken!
2) Do we need another option for the user? --username and --login are options but could we put some logic that if --user and --password are specified then it doesn't need to search for the password in --user (like Linus suggested) ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IMO you cannot fix breakage stemming from --user being too "clever" by adding more "cleverness" to it. as a user i would prefer a clean break from the status quo; i'd rather have my curl-based tools complain about unknown option if curl is too old rather than do unexpected things when they get the "right" inputs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As Daniel has updated the man pages and my discussion regarding new command line arguments is a different, although related issue, I'm marking the report as fixed and will carry on the discussion on the mailing lists.
Kind Regards
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
At present you can't use a username that contains a colon - it's a known limitation that has partially been discussed in the past.
I believe, and I could be wrong here, that a password can contain a colon.
The last discussion was December 2013, relating to some changes I had made roughly this time last year where I added options support in --user and broke passwords containing semi-colons. As such the following thread may be of interest:
http://curl.haxx.se/mail/lib-2013-12/0056.html
...where Daniel and I discussed adding separate command line arguments so we can specify the username and password individually thus allowing such characters in each.
Your bug reported has reminded me that we still haven't done this so I will add it to my to do list for the next release.
Kind Regards
Steve
At the moment you can provide the user name with colons embedded in the URL if the colons are URL-encoded:
http://user:password@example.com/
Perhaps we can hijack the --pass argument for this? If the username or password contains a colon, you have to use --user and --pass separately. Then we can use colons in the --user argument.
my primary complaint was the lack of documentation. whatever you do (even if nothing), please document the available options in curl(1).
the suggestion from Daniel to put them in the url is workable but complicates my code, prompting deliberations to move away from curl to something else.
Linus Nielsen's comment re
--passis almost attractive but i'm suspicious of changing the grammar of an existing option (the interpretation of--useroptarg changes with the absence/presence of--pass).i would deprecate (not remove!)
--userin favor of a new option, let's say--login. keep--useras is, return;into the password character set, whatever.--usershapeshifts too much, i can't really use it in my code with user-supplied strings. it is broken, i don't want to use it at all.I clarified --user's inability to accept colon in the user name in the docs just now.
--pass can't be (ab)used for this easily, since --user and --pass is already a perfectly viable combination.
Two new separate command line options for user and password is probably the best way, and at the same time deprecate --user.
Hi Guys,
I'm hoping to implement this, this weekend and was wondering:
1) --password is quite an obvious long option to use for password but do we need a short option? Unfortunately, -p and -P are already taken!
2) Do we need another option for the user? --username and --login are options but could we put some logic that if --user and --password are specified then it doesn't need to search for the password in --user (like Linus suggested) ?
Steve,
IMO you cannot fix breakage stemming from
--userbeing too "clever" by adding more "cleverness" to it. as a user i would prefer a clean break from the status quo; i'd rather have my curl-based tools complain about unknown option if curl is too old rather than do unexpected things when they get the "right" inputs.Dear all,
As Daniel has updated the man pages and my discussion regarding new command line arguments is a different, although related issue, I'm marking the report as fixed and will carry on the discussion on the mailing lists.
Kind Regards
Steve