[pacman-dev] Running pacman with at(1).

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20190413/0d75194b/attachment.sig>