[Bug-wget] Bug Track
Hi, I am a student who would like to contribute to GNU Project. I'm very passionate about GNU organization and would like to dedicate some time everyday for GNU. It was mentioned that I have to send an email to this address before diving into Bugs. I would look into the bugs and hopefully, I would be able to help. I don't have much programming experience and I know things will be difficult for me but it is my passion for GNU and it's philosophy that drives me. Thank you. Contact: Email: tush...@fedoraproject.org IRC: tusharkumar signature.asc Description: This is a digitally signed message part
Re: [Bug-wget] Timeouts need 'page' and 'byte' options
> Have you looked at whether netcat might be a better fit for your needs than > wget in this instance? netcat isn't aware of html, response codes, etc at that layer so it wouldn't work. There is no reason users should have to write their own parser and complete tool when wget does that. > another option would be to use the "timeout" program from coreutils, it > should be available by default on any GNU/Linux distro: > $ timeout DURATION wget .. > you can also specify the signal to send to the process. As before, external process monitors do not work with recursive wget page by page, nor do they capture server response status, partial pages, etc. Nor should non Linux users have to install Linux. The proper place for these two timeout and byte count options is in wget.
Re: [Bug-wget] wget
On Oct 18, 2014 6:43 AM, "Bryan Baas" wrote: > > Hi, > > I was wondering about the command output of wget. I used a Java Runtime > exec and, although the wget process ended with a 0 completion code, the > results appeared in the error stream and not the output stream. Hi! It should be noted that "standard error" is rather misleadingly named. By long-standing convention, it is generally where all logging and informational messages are meant to go. Standard output is (supposed to be) reserved for actual program output, suitable for potential piping to the stdin of another program. HTH, -mjc
Re: [Bug-wget] wget
Hi, Bryan Am 18.10.2014 21:43 schrieb "Bryan Baas" : > > Hi, > > I was wondering about the command output of wget. I used a Java Runtime > exec and, although the wget process ended with a 0 completion code, the > results appeared in the error stream and not the output stream. > > As a further test, I executed the same command at the command line and > redirected output to a file using the > operator. Upon completion the > file was empty, but the results scrolled down the screen. This had me > thinking that the wget command itself is directing its regular output to > sderr instead of stdout. Yes, that is the expected. It is possible to set the output file to stdout with "-O -" in which case you do not want to see output of wget itself and the file content mangled together. > > The results of the wget command, from what I could tell, weren't error > conditions but regular output from a successful execution. > I think it is a convention that debug, informational, error, verbose output of unix programs be written to stderr. However, the choice of redirecting stderr to whatever file descriptor users prefer is always available. regards. yousong > Your feedback would be appreciated. > > regards, > > > -- > Bryan Baas > Weyco IT > x1808 > 414 241 0499 (cell) >
[Bug-wget] wget
Hi, I was wondering about the command output of wget. I used a Java Runtime exec and, although the wget process ended with a 0 completion code, the results appeared in the error stream and not the output stream. As a further test, I executed the same command at the command line and redirected output to a file using the > operator. Upon completion the file was empty, but the results scrolled down the screen. This had me thinking that the wget command itself is directing its regular output to sderr instead of stdout. The results of the wget command, from what I could tell, weren't error conditions but regular output from a successful execution. Your feedback would be appreciated. regards, -- Bryan Baas Weyco IT x1808 414 241 0499 (cell)
