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
signature.asc
Description: OpenPGP digital signature
