Hrvoje Niksic <[EMAIL PROTECTED]> writes:
> Henrik van Ginhoven <[EMAIL PROTECTED]> writes:
>
> > Great, it's downloading - and wget is smart enough to at least hide
> > your password from the output.. though wget *is* masking it with as
> > many x's as there are letters in the password, which in my opition
> > isn't a good thing,
>
> You're right. It's just one of those things that "seemed like a good
> idea at the time".
>
> > it would be better if it just changd it to (literal)
> > username:[EMAIL PROTECTED]/foobar
>
> Or, maybe we could always use three x's (literally).
I think it'd make a lot more sense to use "<password>" (angle brackets are
the usual signifier of a name that's meant to be taken as a variable, not a
literal, in ASCII). I'll take a look at this.
> I used to oppose these, but as time goes by, I am beginning to see
> their use. In fact, I think they should be on by default. My biggest
> concern used to be that they would fail to function in background (via
> the shell or explicitly with `-b'), but that's not so much of a
> problem, since that can be tested, I think.
I think that check's somewhat non-trivial. Easy if you don't have a
controlling terminal (e.g. called from cron), but if you do (e.g. run with
'&' in shell), don't you have to walk process info structures to try to
guess if an ancestor was a shell and if so, if you're in a different process
group than it? And that check will fail if the shell in question is one
without job control, like Bourne.
I guess you might be able to set up signal handling to catch SIGTTIN, and if
it happens, to not really stop but instead set a timeout alarm() and start
sleep()ing, waiting for the user to send a SIGCONT by foregrounding the
process. If he/she didn't fg in time, you would give up on that URL. At
that point you could either continue processing, and do the same timeout
deal next time you require a password, or you could go into a "batch mode"
where you never ask for passwords. You could also do the latter after some
set number of failures of the user to fail to input a password.
If there were those kind of timeout shenanigans going on, you'd want to have
a commandline option that could force batch mode. *Only* having that batch
mode flag (and not implementing the above) checks would be a good start, if
we making querying for a password the default.
I dunno, though, wget is heavily advertised (on the webpage and elsewhere)
as a non-interactive downloading tool. Perhaps given this, and the
complications of the above issues, it makes more sense to keep the default
mode non-interactive, and only ask for a password if --prompt-for-password
or whatever was given. People who use wget from the commandline can set up
aliases so they'll always be prompted for a password, if they so desire.
> > Oh? you still reading? hah, alright - I do have a question about
> > wget as well, I don't know if this is a bug or a feature so I never
> > tried to fix it myself: If you have downloaded something and then
> > try to download it again with -c, wget will overwrite the existing
> > file and start all over instead of (what I'd think would be the most
> > logical) aborting the download while stating something like "wget
> > can't resume the download because the file is already fully
> > downloaded".
>
> Hmm. I think you're write. I'll put this on the TODO list.
It would appear you forgot to do this, Hrvoje. I'll do it right now.
---------------------------------------------------------------
Dan Harkless | To help prevent SPAM contamination,
GNU Wget co-maintainer | please do not mention this email
http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
