Re: [Bug-wget] Feature: Disabling progress bar when wget is backgrounded

[Christian Neukirchen]

Darshit Shah <address@hidden> 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  <address@hidden>  http://chneukirchen.org