only use -q flag with wget when in batch mode

[leamas]

merged 3974132

[aspiers]

Sorry, but I can't follow your logic here at all. You say "no user should be forced to have progress reports in their output unless they have requested it explicitly" but your code already gives progress reports without the user requesting it, e.g.

$ ./configure
Checking build and support dependencies
    ldconfig:... ldconfig (GNU libc) 2.17 (ok)
    python: Python 2.7.3 (ok)
    wget: GNU Wget 1.14 built on linux-gnu. (ok)
    zenity: ...(ok)
    ar: GNU ar (GNU Binutils; openSUSE 12.3) 2.23.1 (ok)
    lsb_release: trying -i: Distributor ID: openSUSE project (ok)
    make: GNU Make 3.82 (ok)
    install: install (GNU coreutils) 8.17 (ok)
    desktop-file-validate: (ok)
    gtk-update-icon-cache: (ok)
    update-desktop-database: (ok)
Determining distro:... openSUSE project
Determining version:... 0.9.1.55.gbdd3b79.203
Determining arch:... amd64
Determine .deb file...spotify-client_0.9.1.55.gbdd3b79.203-1_amd64.deb
Determine permissions for shared libs (SO_PERMS)...755
Configuration paths:
      PATH:  /home/adam/music/bin:/usr/NX/bin:/opt/kde3/bin:/home/adam/SUSE/bin:/home/adam/bin:/home/adam/local/bin:/usr/local/bin:/usr/X11R6/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/adam/.rvm/bin
    prefix:  /usr/local
    bindir:  /usr/local/bin
    libdir:  /usr/local/lib
    datadir: /usr/local/share
    mandir:  /usr/local/share/man
Writing Makefile
Writing spotify.desktop
Writing spotify.bash

and also

$ make install DESTDIR=test
ar x spotify-client_0.9.1.55.gbdd3b79.203-1_amd64.deb
tar xzf data.tar.gz
cp -ar ./opt/spotify/spotify-client/*  test/usr/local/share/spotify-client
mv test/usr/local/share/spotify-client/libcef.so test/usr/local/lib/spotify-client
mv test/usr/local/share/spotify-client/spotify test/usr/local/lib/spotify-client
cd test/usr/local/lib/spotify-client;           \
ln -sf ../../share/spotify-client/*.pak    .;     \
ln -sf ../../share/spotify-client/locales  .;     \
ln -sf ../../share/spotify-client/Data     .;     \
ln -sf ../../share/spotify-client/licenses.xhtml .;
[ -n "" ] && cp -a  test/usr/local/share/spotify-client || :
./spotify: /usr/lib64/libcrypto.so.0.9.8: no version information available (required by ./spotify)
./spotify: /usr/lib64/libssl.so.0.9.8: no version information available (required by ./spotify)
INFO: resolving libnss3.so.1d as " /usr/lib64/libnss3.so"
INFO: resolving libnssutil3.so.1d as " /usr/lib64/libnssutil3.so"
INFO: resolving libsmime3.so.1d as " /usr/lib64/libsmime3.so"
INFO: resolving libplc4.so.0d as " /usr/lib64/libplc4.so"
INFO: resolving libnspr4.so.0d as " /usr/lib64/libnspr4.so"
cd  test/usr/local/lib/spotify-client; \
    mv spotify spotify-bin; \
    ln -s . spotify
sed -i spotify.bash -e '/^spotify=/s/spotify$/spotify-bin/'
install -m 755 -pD spotify.bash test/usr/local/bin/spotify
install -m 644 -pD spotify.1 test/usr/local/share/man/man1/spotify.1
Installing icons in test/usr/local/share/icons/hicolor
[ -d test/usr/local/share/applications ] ||                      \
    mkdir  test/usr/local/share/applications
desktop-file-install --dir test/usr/local/share/applications     \
    spotify.desktop
[ "openSUSE project" = 'Ubuntu' ] && chmod 755                            \
    test/usr/local/share/applications/spotify.desktop  || :
chmod 755 \
    $( find test/usr/local/lib/spotify-client -name '*.so*' -writable)
cp Makefile test/usr/local/share/spotify-client
cp README.md  test/usr/local/share/spotify-client

If that's not a progress report then I don't know what is! But there's absolutely nothing wrong with that! In interactive usage, showing progress to the user is exactly the right thing to do, otherwise they can't tell whether the program is behaving correctly or has just frozen. I can't understand how that could be construed remotely unhelpful, or as obscuring anything, given there is already at least over 60 lines of verbose technical output (which most users won't understand), and I'm only proposing another 10 or so (which most users will - download progress bars are self-explanatory).

In contrast, when running in batch mode, i.e. when the user is not following the live output, then yes I totally agree that download progress bars are inappropriate, because the terminal sequences required to render them would totally mess up the log files, and in batch mode noone cares about throughput speeds or ETAs anyway.

So it makes perfect sense to hide the download progress in batch mode, and to show it in interactive mode. And thanks to the -t test we can easily automate that without any need for extra arguments etc. This is widely known design pattern amongst UNIX CLI tools (for example git uses it to determine when to use a pager and colour).

[leamas]

Long story short: this is not git or some other CLI tool. It's a Makefile.

No new arguments really IMHO. I suggest that we agree on to disagree about this particular matter.

[aspiers]

Users don't care whether it's a Makefile or a piece of COBOL, they only notice the end experience. I guess I have to give up now, but it's a shame because I can't understand your position at all and now I never will because you didn't explain it. I care a lot about the experience the users get, so this means I'll probably have to make opensuse-spotify-installer use a fork of spotify-make :(

[leamas]

Bottom line: my only objection is that this behaviour should be triggered by a command line option, not being implicit. It does not affect the users of the install-spotify.sh script. If you feel that this justifies a fork... well, let's have a night's sleep on that :)

[aspiers]

I'd much prefer not to fork, even if it's a friendly one :-) I'm open to being convinced that implicit is not the way, could you provide a use case where it doesn't work?

[leamas]

There is no more input on this. Nor is there any other input on the output being too dense. Closing, please feel free to reopen if you feel it's justified.