7

apt is the command that is being recommended by the Linux distributions. It provides the necessary option to manage the packages. It is easier to use with its fewer but easy to remember options.

As quoted in itsfoss.com

There is no reason to stick with apt-get unless you are going to do specific operations that utilize more features of apt-get.

  1. apt is a subset of apt-get and apt-cache commands providing necessary commands for package management
  2. while apt-get won’t be deprecated, as a regular user, you should start using apt more often

I get this error when I use apt in shell scripts whereas it does not happen when I use apt-get instead"

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

My questions are:

  1. Why doesn't apt have a stable CLI interface?
  2. How can I use apt with caution or safely?
  3. How can I disable this error message?

2 Answers 2

12

apt is the recommended command for interactive use by administrators, not for use in shell scripts.

This is addressed to a large extent in the apt manpage:

The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use.

All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well. apt(8) just changes the default value of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with some additional options enabled) in your scripts as they keep backward compatibility as much as possible.

Thus:

  1. apt doesn’t have a stable CLI interface to allow breaking changes, if they’re deemed beneficial.

  2. You can’t, the tool is explicitly not designed for this.

  3. Use apt-get or apt-cache in your scripts to avoid the error message.

0
3

Since apt-get already exists and there is no good reason to change its interface for scripts, apt was introduced specifically for direct interactive usage so it can be made as "friendly" as possible without having to care for complete backward compatibility. Thus you should use only apt-get in scripts to be safe against future interface changes.

OTOH, because apt is "friendly" by design, it should also be safe as long as you pay attention to what it is telling you.

I am guessing (but I have not tested this) that you can fool apt to think it is running interactively, and thus to suppress the warning, if you run it as a direct child of a login shell; to try it run something like sh -l -c "apt $ARGS".

3
  • 1
    The last paragraph is wrong. apt does not know or care if its parent is a login shell. Most people run it from a shell in a GUI terminal which is not a login shell, anyway. apt checks whether its standard output is a terminal. Jun 3, 2020 at 19:28
  • I did write I had not tested it :-P But if it really doesn't check anything beyond a tty on stdout, it won't detect "scriptness" as long as the script doesn't do anything to redirect stdout, right? Thanks for the correction in any case.
    – q.undertow
    Jun 3, 2020 at 20:08
  • 1
    Right. You can test it easily: sh -c 'apt list foo; echo no warning' vs apt list foo | cat Jun 3, 2020 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.