A buglet in GET

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Nathaniel Good: "redirect, cookies and all that jazz"
• Previous message: Christoph Wernli: "Re: libwww in home directory"

This hasn't been a big enough problem for me to trace it all the way
and provide a patch, but I thought you guys might want to look into
fixing it if it's easy.

If you give credentials for a FTP URL in the URL, but the credentials
result in "login denied", then GET will ask you interactively for a
username/password. However, if you put the credentials into a -C
option and they fail, then it will not try to get the password from
you interactively. This behavior is confusing -- it should not ask for
the user and password if you already gave it, even if you gave it via
the URL instead of via -C. Having it read from stdin in the middle of
a script when the username/password is wrong is reall
inconvenient. I'd hate to have to follow every use of GET with
"< /dev/null" forever more. :)

Example:

	GET ftp://fakeuser:fakepass@ftp.webtv.net/foo.txt
		(fails login, asks for password)

	GET -C fakeuser:fakepass ftp://ftp.webtv.net/foo.txt
		(fails login, immeditely fails with error message)

Also, if the "get a user/password" code in GET is hit for a FTP URL,
then $realm is not set right, resulting in a Perl warning for using an
undefined variable. that should be easy to fix, I think, by making the
format of the print statement conditional on (defined($realm)).

Thanks for a cool tool. We use it every day here, for monitoring,
automating CGI apps, automated fetching, and other minor miracles. :)

-- 
Jeff R. Allen                   |   jra@corp.webtv.net (work)
WebTV Networks, Inc.            |   jeff.allen@acm.org (personal)
Service Operations Toolsmith    |   http://www.webtv.net

• Next message: Nathaniel Good: "redirect, cookies and all that jazz"
• Previous message: Christoph Wernli: "Re: libwww in home directory"