Darshit Shah <[email protected]> writes: > This patch has a couple of deficiencies that need to be addressed. > > 1. The point of the --show-progress switch is to override all other > settings and display a progress bar on screen. This patch does not > take into consideration the --show-progress switch.
True, I did not know about that switch. The condition is easily adjusted. > 2. After this patch, Wget will *never* display a progress bar if it is > invoked from a shell script / another C program. This not only changes > the default behaviour, it is also not something we want. Running the > Perl / Python tests singularly will display this effect. With this > patch in the next release, there will be way too many people > complaining about a missing progress bar. > > From `man tcgetpgrp`: > > The function tcgetpgrp() returns the process group ID of the > foreground process group on the terminal associated to fd, which must > be the controlling terminal of the calling process. > > But, when wget is invoked from within a shell script, its pid != ppid > This causes progress bar to disappear. Indeed. A better test is getpgid(0) == tcgetpgrp(2). This seems to work for interactive shells and scripts as well (backgrounding the script will turn off the progress-bar). > If someone wants to background a Wget process, let them use SIGHUP to handle > it. The problem is that one cannot easily foreground it then again, because the input stays in the file. Also, from a user-experience point of view, this is clumsy. > There is also Giuseppe's response on the mailing list which is present > in the links provided by Noel Koethe. We should not change the default > behaviour of Wget. Especially one which helps identify a very common > mistake by many people. The other output of wget is still printed, so this mistake will be noticed. > Since the patch in its current form causes more problems than it > solves, I'm reverting it right now. We can discuss an alternative > strategy here and if it works, a new patch can be applied later. Please try above proposal. Thanks, -- Christian Neukirchen <[email protected]> http://chneukirchen.org
