On 4/13/19 5:43 AM, Ralph Corderoy wrote:
Hi,
Due to bandwidth charges varying depending on the time of day, I've used at(1) in the past to `pacman -S' when I'm AFK. My recollection is something like this is sufficient; a `pacman -Syuw --noconfirm' will have run a little beforehand.
sudo -i at '04:45 tomorrow' <<<'pacman -Sw foo...'
Personally I don't recommend this, there are better ways to deal with bandwidth. For example, consider using this instead: https://github.com/eli-schwartz/dotfiles/blob/master/bin/cacheupdates It is like checkupdates in that it is safe to run at any time without running the risk of partial updates, but includes a -d option to also download them.
But that didn't work last night; it gave similar output to running in a TTY with EOF on stdin.
$ sudo -i pacman -Sw dbeaver </dev/null resolving dependencies... :: There are 3 providers available for java-runtime>=8: :: Repository extra 1) jre-openjdk 2) jre10-openjdk 3) jre8-openjdk
Enter a number (default=1): Package (5) New Version Net Change Download Size
extra/java-runtime-common 3-1 0.01 MiB extra/jre-openjdk 11.0.3.u4-1 0.52 MiB 0.17 MiB extra/jre-openjdk-headless 11.0.3.u4-1 156.57 MiB 29.18 MiB extra/libnet 1.1.6-3 0.34 MiB community/dbeaver 6.0.1-1 62.90 MiB 54.53 MiB
Total Download Size: 83.88 MiB
:: Proceed with download? [Y/n] $
Notice how the first prompt, that defaults to `1', seemed not to mind EOF and went with that default. The second prompt, to proceed with the download, also has a default, `Y', but EOF that time halts pacman. That seems inconsistent.
Skipping the first prompt doesn't bless the second one with the first's behaviour of continuing.
$ sudo -i pacman -Sw libnet </dev/null resolving dependencies...
Package (1) New Version Net Change Download Size
extra/libnet 1.1.6-3 0.34 MiB 0.09 MiB
Total Download Size: 0.09 MiB
:: Proceed with download? [Y/n] $ $ echo $? 1 $
Has this behaviour changed in the last few months? Or quite possibly my recollection is wrong.
pacman(1) has
--noconfirm Bypass any and all “Are you sure?” messages. It’s not a good idea to do this unless you want to run pacman from a script.
Given the first prompt isn't a simple binary choice of confirmation, the man page could do with being a bit more explicit, perhaps
The prompt is still displayed, but the default choice is always taken.
What else would "bypass any and all confirmation messages" mean? Note the flag is *not* named --yes which would indicate "accept any and all confirmation messages" (and indeed would not make sense in the context). I'm not averse to rewording the message, necessarily, but I thought its meaning was pretty clear already and even with the perspective of your confusion, I still am not clear how it would be interpreted incorrectly (although I'm willing to believe it could be interpreted as "I'm not sure what this means at all and need to ask the developers"). Also note that the behavior of pacman has always AFAIK been exactly how you see it now. It's also the exact same behavior if you press <ENTER> without specifying either "Y" or "n", that is to say --noconfirm pretends you just hit enter at every single prompt in order to select the default (capitalized) option or all for group selection. You may consider what the effects of sending a bytestream consisting of "nothing, followed by an EOF" would have in terms of attempting to read *meaningful content* from it for interactive prompt selection in a decidedly non-script-friendly way, but my advice is don't. If you want to script pacman, your reasonable choices are twofold: - use --noconfirm, always - use `yes y | pacman ...` to send explicit bytes to pacman, so you know what pacman will see Option #3 is to pacman -S pacutils and use the pacinstall/pacsync/pacremove utilities, which serve as alternative (non-pacman) frontends to the libalpm backend. Unlike the pacman utility, pacutils utilities are specifically designed in order to be script-friendly. -- Eli Schwartz Bug Wrangler and Trusted User