neulab/tldr huggingface dataset:
-F, --no-refresh Disable auto-refresh for the repository.
-p, --priority positive-integer Set the priority of the repository. Priority of 1 is the highest, the higher the number the lower the priority. -p 0 will set the priority back to the default (99). Packages from repositories with higher priority will be preferred even in case there is a higher installable version available in the repository with a lower priority.
-k, --keep-packages Enable RPM files caching for the repository.
-K, --no-keep-packages Disable RPM files caching.
-g, --gpgcheck Enable GPG check for this repository. The behavior as described in section GPG checks.
--gpgcheck-strict Enable strict GPG check for this repository. Even packages from signed repositories need a valid GPG signature and using unsigned packages must be confirmed.
--gpgcheck-allow-unsigned Short hand for --gpgcheck-allow-unsigned-repo --gpgcheck-allow-unsigned-package
--gpgcheck-allow-unsigned-repo Enable GPG check but allow the repository metadata to be unsigned.
--gpgcheck-allow-unsigned-package Enable GPG check but allow installing unsigned packages from this repository.
-G, --no-gpgcheck Disable GPG check for this repository.
Disabling GPG checks is not recommended. Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise.
--default-gpgcheck Use the global GPG check settings defined in /etc/zypp/zypp.conf. This is the default.
Unless you have modified your zypp.conf settings, this is the same as --gpgcheck, the behavior as described in section GPG checks.
$ zypper ar -c -n 'Packman 11.1 repo' http://packman.iu-bremen.de/suse/11.1 packman Add a HTTP repository, probe it, name it Packman 11.1 repo, and use packman as alias.
$ zypper ar https://download.opensuse.org/repositories/zypp:/svn/openSUSE_Factory/zypp:svn.repo
$ zypper ar myreposbackup.repo Add repositories from a .repo file.
removerepo (rr) [options] alias|name|#|URI... Delete repositories specified by aliases, names, numbers, URIs or one of the aggregate options.
--loose-auth Ignore user authentication data in the URI
--loose-query Ignore query string in the URI
-a, --all Apply changes to all repositories.
-l, --local Apply changes to all local repositories.
-t, --remote Apply changes to all remote repositories (http/https/ftp).
-m, --medium-type type Apply changes to repositories of specified type. The type corresponds to the repository URI scheme identifier like http, dvd, etc. You can find complete list of valid types at http://en.opensuse.org/openSUSE:Libzypp_URIs.
repos (lr) [options] [repo]... List all defined repositories or show detailed information about those specified as arguments
The following data can be printed for each repository found on the system: # (repository number), Alias (unique identifier), Name, Enabled (whether the repository is enabled), GPG Check (whether GPG check for repository metadata (r) and/or downloaded rpm packages (p) is enabled), Refresh (whether auto-refresh is enabled for the repository), Priority, Type (repository meta-data type: rpm-md, yast2, plaindir). Which of the data is shown is determined by command line options listed below and the main.repoListColumns setting from zypper.conf. By default, #, Alias, Name, Enabled, GPG Check and Refresh is shown.
Repository number is a unique identifier of the repository in current set of repositories. If you add, remove or change a repository, the numbers may change. Keep that in mind when using the numbers with the repository handling commands. On the other hand, using the alias instead of the number is always safe.
To show detailed information about specific repositories, specify them as arguments, either by alias, name, number from simple zypper lr, or by URI; e.g. fB zypper lr factory, or zypper lr 2.
-e, --export FILE.repo|- This option causes zypper to write repository definition of all defined repositories into a single file in repo file format. If - is specified instead of a file name, the repositories will be written to the standard output.
-a, --alias Add alias column to the output.
-n, --name Add name column to the output.
-u, --uri Add base URI column to the output.
-p, --priority Add repository priority column to the output.
-r, --refresh Add the autorefresh column to the output.
-d, --details Show more information like URI, priority, type, etc.
-E, --show-enabled-only Show enabled repositories only.
-U, --sort-by-uri Add base URI column and sort the list it.
-P, --sort-by-priority Add repository priority column and sort the list by it.
-A, --sort-by-alias Sort the list by alias.
-N, --sort-by-name Sort the list by name.
$ zypper repos -e myreposbackup.repo Backup your repository setup:
$ zypper lr -pu List repositories with their URIs and priorities:
renamerepo (nr) alias|name|#|URI new-alias Assign new alias to the repository specified by alias, name, number, or URI.
$ zypper nr 8 myrepo Rename repository number 8 to myrepo (useful if the repo has some dreadful alias which is not usable on the command line).
modifyrepo (mr) options alias|name|#|URI...
modifyrepo (mr) options --all|--remote|--local|--medium-type Modify properties of repositories specified by alias, name, number, or URI or one of the aggregate options.
-n, --name name Set a descriptive name for the repository.
-e, --enable Enable the repository.
-d, --disable Disable the repository.
-f, --refresh (legacy: -r) Enable auto-refresh for the repository.
-F, --no-refresh (legacy: -R) Disable auto-refresh for the repository.
-k, --keep-packages Enable RPM files caching.
$ zypper mr -kt Enable keeping of packages for all remote repositories.
$ zypper mr -er updates Enable repository updates and switch on autorefresh for the repo.
$ zypper mr -da Disable all repositories.
refresh (ref) [alias|name|#|URI]... Refresh repositories specified by their alias, name, number, or URI. If no repositories are specified, all enabled repositories will be refreshed.
-f, --force Force a complete refresh of specified repositories. This option will cause both the download of raw metadata and parsing of the metadata to be forced even if everything indicates a refresh is not needed.
-b, --force-build Force only reparsing of cached metadata and rebuilding of the database. Raw metadata download will not be forced.
-d, --force-download Force only download of current copy of repository metadata. Parsing and rebuild of the database will not be forced.
-B, --build-only Only parse the metadata and build the database, don’t download raw metadata into the cache. This will enable you to repair damaged database from cached data without accessing network at all.
-D, --download-only Only download the raw metadata, don’t parse it or build the database.
-s, --services Refresh also services before refreshing repositories.
clean (cc) [options] [alias|name|#|URI]... Clean the local caches for all known or specified repositories. By default, only caches of downloaded packages are cleaned.
-m, --metadata Clean repository metadata cache instead of package cache.
-M, --raw-metadata Clean repository raw metadata cache instead of package cache.
-a, --all Clean both repository metadata and package caches.
Service Management The services, addservice, removeservice, modifyservice, and refresh-services commands serve for manipulating services. A service is specified by its URI and needs to have a unique alias defined (among both services and repositories).
Standalone repositories (not belonging to any service) are treated like services, too. The ls command will list them, ms command will modify them, etc. Repository specific options, like --keep-packages are not available here, though. You can use repository handling commands to manipulate them.
addservice (as) [options] URI alias Adds a service specified by URI to the system. The alias must be unique and serves to identify the service.
Newly added services are not refreshed automatically. Use the refresh-services command to refresh them. Zypper does not access the service URI when adding the service, so the type of the services is unknown until it is refreshed.
-n, --name name Specify descriptive name for the service.
-e, --enable Enable the service (this is the default).
-d, --disable Add the service as disabled.
-f, --refresh Enable auto-refresh of the service.
-F, --no-refresh Disable auto-refresh of the service.
removeservice (rs) [options] alias|name|#|URI... Remove specified service from the system. Removing a service will also remove of all of its repositories.
--loose-auth Ignore user authentication data in the URI.
--loose-query Ignore query string in the URI.
modifyservice (ms) options alias|name|#|URI
modifyservice (ms) options --all|--remote|--local|--medium-type Modify properties of specified services.
Common Options These options are common to all types of services and repositories.
-n, --name name Set a descriptive name for the service.
-e, --enable Enable a disabled service.
-d, --disable Disable the service (but don’t remove it).
-f, --refresh  (legacy: -r) Enable auto-refresh of the service.
-F, --no-refresh  (legacy: -R) Disable auto-refresh of the service.
-a, --all Apply changes to all services.
-l, --local Apply changes to all local services.
-t, --remote Apply changes to all remote services.
-m, --medium-type type Apply changes to services of specified type.
RIS Service Specific Options These options are ignored by services other than Repository Index Services.
-i, --ar-to-enable alias Schedule an RIS service repository to be enabled at next service refresh.
-I, --ar-to-disable alias Schedule an RIS service repository to be disabled at next service refresh.
-j, --rr-to-enable alias Remove a RIS service repository to enable.
-J, --rr-to-disable alias Remove a RIS service repository to disable.
-k, --cl-to-enable Clear the list of RIS repositories to enable.
-K, --cl-to-disable Clear the list of RIS repositories to disable.
services (ls) [options] List services defined on the system.
-u, --uri Show also base URI of repositories.
-p, --priority Show also repository priority.
-d, --details Show more information like URI, priority, type.
-r, --with-repos Show also repositories belonging to the services.
-P, --sort-by-priority Sort the list by repository priority.
-E, --show-enabled-only Show enabled services only. If used together with --with-repos a disabled services owning (manually) enabled repositories are shown as well.
-U, --sort-by-uri Sort the list by URI.
refresh-services (refs) [options] alias|name|#|URI... Refreshing a service means executing the service’s special task.
RIS services add, remove, or modify repositories on your system based on current content of the repository index. A differing enabled/disabled state caused by manually calling modify-repo on a service repository however will not be reverted unless the --restore-status option is used, or the repository index explicitly requests the change.
Services only manage defined repositories, they do not refresh them. To refresh also repositories, use --with-repos option or the refresh command.
-f, --force Force a complete refresh of specified services. This option will cause both the download of raw metadata and parsing of the metadata to be forced even if everything indicates a refresh is not needed.
-r, --with-repos Refresh also the service repositories.
-R, --restore-status Also restore service repositories enabled/disabled state to the repository index default. Useful after you manually changed some service repositories enabled state.
Package Locks Management Package locks serve the purpose of preventing changes to the set of installed packages on the system. The locks are stored in form of a query in /etc/zypp/locks file (see also locks(5)). Packages matching this query are then forbidden to change their installed status; an installed package can’t be removed or upgraded, not installed package can’t be installed. When requesting to install, upgrade or remove such locked package, you will get a dependency problem dialog.
locks (ll) List currently active package locks.
-m, --matches Show the number of resolvables matched by each lock. This option requires loading the repositories.
-s, --solvables List the resolvables matched by each lock. This option requires loading the repositories.
addlock (al) [options] package-name... Add a package lock. Specify packages to lock by exact name or by a glob pattern using * and ? wildcard characters.
-r, --repo alias|name|#|URI Restrict the lock to the specified repository.
-t, --type type Lock only packages of specified type (default: package). See section Package Types for list of available package types.
removelock (rl) [options] lock-number|package-name... Remove specified package lock. Specify the lock to remove by its number obtained with zypper locks or by the package name.
-t, --type type Restrict the lock to packages of specified type (default: package). See section Package Types for list of available package types.
cleanlocks (cl) Remove unused locks.
This command looks for locks that do not currently (with regard to repositories used) lock any package and for each such lock it asks user whether to remove it.
Locale Management These commands give information about requested locales and the possibility to manage those. A locale is defined by a language code. For many packages there are locale dependent packages available which provide translations or dictionaries. To get these installed, the locale for the desired language must be marked as requested by the package manager library.
locales (lloc) [OPTIONS] [LOCALE] ... List requested locales. Called without argument, lists the locales which are already marked as requested. Specifying certain locale(s) prints information only for this(these).
-a, --all List all available locales.
-p, --packages Show corresponding packages.
addlocale (aloc) [OPTIONS] <LOCALE> ... Add specified locale(s) to the list of requested locales..
-n, --no-packages Do not install corresponding packages.
removelocale (rloc) [OPTIONS] <LOCALE> ... Remove specified locale(s) from the list of requested locales..
-n, --no-packages Do not remove corresponding packages.
$ zypper locales List requested locales.
$ zypper locales --packages de en Get the lists of packages which are available for de and en (exact match).
$ zypper locales en_ Get all locales with lang code en that have their own country code, excluding the fallback en.
$ zypper locales en* Get all locales with lang code en with or without country code.
$ zypper aloc --packages de_CH Request de_CH and install language dependent packages.
Other Commands versioncmp (vcmp) version1 version2 Compare the versions supplied as arguments and tell whether version1 is older or newer than version2 or the two version strings match.
The default output is in human-friendly form. If --terse global option is used, the result is an integer number, negative/positive if version1 is older/newer than version2, zero if they match.
-m, --match Takes missing release number as any release.
$ zypper vcmp -m 0.15.3 0.15.3-2 0.15.3 matches 0.15.3-2
$ zypper vcmp 0.15.3 0.15.3-2 0.15.3 is older than 0.15.3-2
targetos (tos) Shows the ID string of the target operating system. The string has a form of distroname-architecture. The string is determined by libzypp, the distroname is read from (current-rootdir)/etc/products.d/baseproduct and the architecture is determined from uname and CPU flags.
licenses Prints a report about licenses and EULA’s of installed packages to standard output.
First, a list of all packages and their licenses and/or EULAs is shown. This is followed by a summary, including the total number of installed packages, the number of installed packages with EULAs that required a confirmation from the user. Since the EULAs are not stored on the system and can only be read from repository metadata, the summary includes also the number of installed packages that have their counterpart in repositories. The report ends with a list of all licenses uses by the installed packages.
This command can be useful for companies redistributing a custom distribution (like appliances) to figure out what licenses they are bound by.
download [OPTIONS] Download rpms specified on the commandline to a local directory.
Per default packages are downloaded to the libzypp package cache (/var/cache/zypp/packages; for non-root users $XDG_CACHE_HOME/zypp/packages), but this can be changed by using the global --pkg-cache-dir option.
Parsable XML-output produced by zypper --xmlout will include a <download-result> node for each package zypper tried to download. Upon success the location of the downloaded package is found in the path attribute of the <localfile> subnode (xpath: download-result/localpath@path):
<download-result> <solvable> <kind>package</kind> <name>zypper</name> <edition epoch="0" version="1.9.17" release="26.1"/> <arch>x86_64</arch> <repository name="repo-oss-update (13.1)" alias="openSUSE:repo-oss-update"/> </solvable> <localfile path="/var/cache/zypp/pac.../zypper-1.9.17-26.1.x86_64.rpm"/> </download-result>
--all-matches Download all versions matching the commandline arguments. Otherwise only the best version of each matching package is downloaded.
--dry-run Don’t download any package, just report what would be done.
--from alias|name|#|URI Select packages from the specified repository only. This option can be used multiple times.
source-download [OPTIONS] Download source rpms for all installed packages to a local directory.
-d, --directory dir Download all source rpms to this directory. Default is /var/cache/zypper/source-download.
--delete Delete extraneous source rpms in the local directory. This is the default.
--no-delete Do not delete extraneous source rpms.
--status Don’t download any source rpms, but show which source rpms are missing or extraneous.
ps [OPTIONS] After each upgrade or removal of packages, there may be running processes on the system which continue to use meanwhile deleted files. zypper ps lists all processes using deleted files, together with the corresponding files, and a service name hint, in case it’s a known service. This gives a hint which services may need to be restarted after an update. Usually programs which continue to use deleted shared libraries. The list contains the following information:
PID ID of the process
PPID ID of the parent process
UID ID of the user running the process
Login Login name of the user running the process
Command Command used to execute the process
Service Service name, if command is associated with a system service
Files The list of the deleted files
-s, --short Create a short table not showing the deleted files. Given twice, show only processes which are associated with a system service. Given three times, list the associated system service names only.
--print format For each associated system service print format on the standard output, followed by a newline. Any %s directive in format is replaced by the system service name.
-d, --debugFile filename Output a file with all proc entries that make it into the final set of used open files. This can be submitted as additional information in a bug report.
$ zypper ps -ss Show only processes associated with a system service.
$ zypper ps -sss Short for zypper ps --print "%s"; list services which might need a restart.
$ zypper ps --print "systemctl status %s" Let zypper print the commands to retrieve status information for services which might need a restart.
needs-rebooting Checks if the reboot-needed flag was set by a previous update or install of a core library or service.
The reboot-needed flag is set if a package that provides installhint(reboot-needed) is updated or installed. Additionally there is a predefined list (/etc/zypp/needreboot) of well-known packages which cause the reboot-needed flag being set unconditionally. Exit code ZYPPER_EXIT_INF_REBOOT_NEEDED indicates that a reboot is needed, otherwise the exit code is set to ZYPPER_EXIT_OK.
Subcommands subcommand Lists available subcommands in /usr/lib/zypper/commands and from elsewhere on your $PATH. See section SUBCOMMANDS for details.
-h, --help Help. If a command is specified together with --help option, command specific help is displayed.
-V, --version Print zypper version number and exit.
-c, --config file Use the specified zypper config file instead of the default zypper.conf. Other command line options specified together with --config and having their counterpart in the zypper config file are still preferred.
The order of preference with --config is as follows:
1. Command line options
2. --config file
3. [/etc/zypp/zypp.conf] (system-wide defaults for all libzypp based applications)
Note Use and location of the system-wide /etc/zypp/zypp.conf can not be changed this way. It’s mentioned here just because some zypper command line options allow one to overwrite system-wide defaults defined in zypp.conf.
See also FILES section for more information.
-v, --verbose Increase verbosity. For debugging output specify this option twice.
-q, --quiet Suppress normal output. Brief (esp. result notification) messages and error messages will still be printed, though. If used together with conflicting --verbose option, the --verbose option takes preference.
--color, --no-color Whether to use colors in output if tty supports it. For details see the [color] section in zypper.conf.
-A, --no-abbrev Do not abbreviate text in tables. By default zypper will try to abbreviate texts in some columns so that the table fits the width of the screen. If you need to see the whole text, use this option.
-t, --terse Terse output for machine consumption. Implies --no-abbrev and --no-color.
-s, --table-style integer Choose among different predefined line drawing character sets to use when drawing a table. The table style is identified by an integer number. Style 0 is the default, styles 1-9 use combinations of different box drawing characters whose shape may depend on the font the terminal is using. Style 10 separates columns by a colon and style 11 draws no lines at all.
-n, --non-interactive Switches to non-interactive mode. In this mode zypper doesn’t ask user to type answers to various prompts, but uses default answers automatically. Those default answers also depend on other options like --no-gpg-checks or --ignore-unknown.
--non-interactive-include-reboot-patches In non-interactive mode do not skip patches which have the rebootSuggested-flag set. Otherwise these patches are considered to be interactive, like patches including a licenses or some message to confirm. NOTE: This option does not turn on non-interactive mode.
-x, --xmlout Switches to XML output. This option is useful for scripts or graphical frontends using zypper.
-i, --ignore-unknown Ignore unknown packages. This option is useful for scripts, because when installing in --non-interactive mode zypper expects each command line argument to match at least one known package. Unknown names or globbing expressions with no match are treated as an error unless this option is used.
-D, --reposd-dir dir Use the specified directory to look for the repository definition (.repo) files. The default value is /etc/zypp/repos.d.
-C, --cache-dir dir Use an alternative root directory for all caches. The default value is /var/cache/zypp.
--raw-cache-dir dir Use the specified directory for storing raw copies of repository metadata files. The default value is /var/cache/zypp/raw.
--solv-cache-dir dir Use the specified directory to store the repository metadata cache database files (solv files). The default value is /var/cache/zypp/solv.
--pkg-cache-dir dir Use the specified directory for storing rpm packages downloaded from repositories (see addrepo --keep-packages). The default value is /var/cache/zypp/packages. + Packages are stored in subdirectories named after the repositories alias and using the same path as on the repositories medium.
--userdata string User data is expected to be a simple string without special chars or embedded newlines and may serve as transaction id. It will be written to all install history log entries created throughout this specific zypper call. It will also be passed on to zypp plugins executed during commit. This will enable e.g. a btrfs plugin to tag created snapshots with this string. For zypper itself this string has no special meaning.
--no-gpg-checks Ignore GPG check failures and continue. If a GPG issue occurs when using this option zypper prints and logs a warning and automatically continues without interrupting the operation. Use this option with caution, as you can easily overlook security problems by using it. (see section GPG checks)
--gpg-auto-import-keys If new repository signing key is found, do not ask what to do; trust and import it automatically. This option causes that the new key is imported also in non-interactive mode, where it would otherwise got rejected.
-p, --plus-repo URI Use an additional repository for this operation. The repository aliased tmp# and named by the specified URI will be added for this operation and removed at the end. You can specify this option multiple times.
--plus-content tag Additionally use disabled repositories denoted by tag for this operation. If tag matches a repositories alias, name or URL, or is a keyword defined in the repositories metadata, the repository will be temporarily enabled for this operation. The repository will then be refreshed and used according to the commands rules. You can specify this option multiple times.
If a disabled repositories metadata are not available in the local cache, they will be downloaded to scan for matching keywords. Otherwise the keyword scan will use the metadata available in the local cache. Only if used together with the refresh command, a keyword scan will refresh all disabled repositories.
To refresh all disabled repositories metadata: zypper --plus-content '' ref
To include a disabled repository repo-debug in a search: zypper --plus-content repo-debug search ...
To search only in a disabled repository repo-debug: zypper --plus-content repo-debug search -r repo-debug ...
To enable all repos providing the debug keyword: zypper in --plus-content debug some -debuginfo or -debugsource package
--disable-repositories Do not read metadata from repositories. This option will prevent loading of packages from repositories, thus making zypper work only with the installed packages (if --disable-system-resolvables was not specified).
--no-refresh Do not auto-refresh repositories (ignore the auto-refresh setting). Useful to save time when doing operations like search, if there is not a need to have a completely up to date metadata.
--no-cd Ignore CD/DVD repositories. When this option is specified, zypper acts as if the CD/DVD repositories were not defined at all.
--no-remote Ignore remote repositories like http, ftp, smb and similar. This makes using zypper easier when being offline. When this option is specified, zypper acts as if the remote repositories were not defined at all.
--releasever version For the current command set the value of the $releasever repository variable to version. This can be used to switch to new distribution repositories when performing a distribution upgrade. See the dist-upgrade (dup) command and section Repository Management for more details about using the $releasever repository variable.
Target Options:
-R, --root dir Operates on a different root directory. This option influences the location of the repos.d directory and the metadata cache directory and also causes rpm to be run with the --root option to do the actual installation or removal of packages. See also the FILES section.
--installroot dir Behaves like --root but shares the repositories with the host system.
--disable-system-resolvables This option serves mainly for testing purposes. It will cause zypper to act as if there were no packages installed in the system. Use with caution as you can damage your system using this option.
Zypper subcommands are inspired by git(1). Subcommands are standalone executables that live in the zypper_execdir (/usr/lib/zypper/commands). For subcommands zypper provides a wrapper that knows where the subcommands live, and runs them by passing command options and arguments to them. If a subcommand is not found in the zypper_execdir, the wrapper will look in the rest of your $PATH for it. Thus, it’s possible to write local zypper extensions that don’t live in system space.
This is how to add your own subcommand zypper mytask:
•   The executable must be named zypper-mytask.
•   The executable must be located your $PATH.
•   A manpage for zypper-mytask should be provided and explaining the commands options and return values. It will be shown when calling zypper help mytask.
•   Zypper built-in commands take precedence over subcommands with the same name.
•   It’s fine to call zypper or use libzypp from within your subcommand.
You can use the built-in zypper subcommand command to get a list of all subcommands in zypper_execdir and from elsewhere on your $PATH.
Using zypper global-options together with subcommands, as well as executing subcommands in zypper shell is currently not supported.
/etc/zypp/zypper.conf, $HOME/.zypper.conf Global (system-wide) and user’s configuration file for zypper. These files are read when zypper starts up and --config option is not used.
User’s settings are preferred over global settings. Similarly, command line options override the settings in either of these files. To sum it up, the order of preference is as follows (from highest to lowest):
2. $HOME/.zypper.conf
3. /etc/zypp/zypper.conf
4. [/etc/zypp/zypp.conf] (system-wide defaults for all libzypp based applications)
See the comments in /etc/zypp/zypper.conf for a list and description of available options.
Note The system-wide /etc/zypp/zypp.conf is mentioned here just because some zypper command line options allow one to overwrite system-wide defaults defined there. zypp.conf and zypper.conf have different content and serve different purpose.
/etc/zypp/zypp.conf ZYpp configuration file affecting all libzypp based applications. See the comments in the file for description of configurable properties. Many locations of files and directories listed in this section are configurable via zypp.conf. The location for this file itself can be redefined only by setting $ZYPP_CONF in the environment.
/etc/zypp/locks File with package lock definitions, see locks(5) manual page for details. The package lock commands (addlock, removelock, etc.) can be used to manipulate this file.
This file is used by all ZYpp-based applications.
/etc/zypp/repos.d Directory containing repository definition (*.repo) files. You can use the Repository Management commands to manipulate these files, or you can edit them yourself. In either case, after doing the modifications, executing *zypper refresh* is strongly recommended.
You can use the --reposd-dir global option to use an alternative directory for this purpose or the --root option to make this directory relative to the specified root directory.
This directory is used by all ZYpp-based applications.
/etc/zypp/services.d Directory containing service definition (*.service) files. You can use the Service Management Commands to manipulate these files, or you can edit them yourself. Running *zypper refs* is recommended after modifications have been done.
/usr/lib/zypper/commands System directory containing zypper extensions (see section SUBCOMMANDS)
/var/cache/zypp/raw Directory for storing raw metadata contained in repositories. Use the --raw-cache-dir global option to use an alternative directory for this purpose or the --root option to make this directory relative to the specified root directory.
/var/cache/zypp/solv Directory containing preparsed metadata in form of solv files.
/var/cache/zypp/packages If keeppackages property is set for a repository (see the modifyrepo command), all the RPM file downloaded during installation will be kept here. See also the clean command for cleaning these cache directories.
/var/log/zypper.log Zypper log file. It should be attached to all bugreports. (see also zypper-log(8)).
/var/log/zypper.solverTestCase Solver testcase created by using the --debug-solver option.
/var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss Solver testcase auto created when performing a zypper dup.
/var/log/zypp/history Installation history log.
~/.zypper_history Command history for the zypper shell (see the shell command).
/etc/zypp/needreboot File with a list of packages that will set the reboot-needed flag when installed or upgraded.
/etc/zypp/needreboot.d Directory that can be used to define packages that trigger the reboot-needed flag by adding additional files containing the required package names.
There are several exit codes defined for zypper built-in commands for use e.g. within scripts. These codes are defined in header file src/zypper-main.h found in zypper source package. Codes below 100 denote an error, codes above 100 provide a specific information, 0 represents a normal successful run. Following is a list of these codes with descriptions:
0 - ZYPPER_EXIT_OK Successful run of zypper with no special info.
1 - ZYPPER_EXIT_ERR_BUG Unexpected situation occurred, probably caused by a bug.
2 - ZYPPER_EXIT_ERR_SYNTAX zypper was invoked with an invalid command or option, or a bad syntax.
3 - ZYPPER_EXIT_ERR_INVALID_ARGS Some of provided arguments were invalid. E.g. an invalid URI was provided to the addrepo command.
4 - ZYPPER_EXIT_ERR_ZYPP A problem is reported by ZYPP library.
5 - ZYPPER_EXIT_ERR_PRIVILEGES User invoking zypper has insufficient privileges for specified operation.
6 - ZYPPER_EXIT_NO_REPOS No repositories are defined.
7 - ZYPPER_EXIT_ZYPP_LOCKED The ZYPP library is locked, e.g. packagekit is running.
8 - ZYPPER_EXIT_ERR_COMMIT An error occurred during installation or removal of packages. You may run zypper verify to repair any dependency problems.
100 - ZYPPER_EXIT_INF_UPDATE_NEEDED Returned by the patch-check command if there are patches available for installation.
101 - ZYPPER_EXIT_INF_SEC_UPDATE_NEEDED Returned by the patch-check command if there are security patches available for installation.
102 - ZYPPER_EXIT_INF_REBOOT_NEEDED Returned after a successful installation of a patch which requires reboot of computer.
103 - ZYPPER_EXIT_INF_RESTART_NEEDED Returned after a successful installation of a patch which requires restart of the package manager itself. This means that one of patches to be installed affects the package manager itself and the command used (e.g. zypper update) needs to be executed once again to install any remaining patches.
104 - ZYPPER_EXIT_INF_CAP_NOT_FOUND Returned by the install and the remove command in case any of the arguments does not match any of the available (or installed) package names or other capabilities.
105 - ZYPPER_EXIT_ON_SIGNAL Returned upon exiting after receiving a SIGINT or SIGTERM.
106 - ZYPPER_EXIT_INF_REPOS_SKIPPED Some repository had to be disabled temporarily because it failed to refresh. You should check your repository configuration (e.g. zypper ref -f).
107 - ZYPPER_EXIT_INF_RPM_SCRIPT_FAILED Installation basically succeeded, but some of the packages %post install scripts returned an error. These packages were successfully unpacked to disk and are registered in the rpm database, but due to the failed install script they may not work as expected. The failed scripts output might reveal what actually went wrong. Any scripts output is also logged to /var/log/zypp/history.
Zypper subcommands (see section SUBCOMMANDS) may return different codes which should be described in the commands man page. Call zypper help subcommand to see the subcommands man page if one is provided.
https://github.com/openSUSE/zypper
The zypper project was started by Martin Vidner, Jan Kupec, Michael Andres, Duncan Mac-Vicar Prett, Josef Reidinger and Stanislav Visnovsky. Many people have later contributed to it.
locks(5), zypper-log(8), YaST2(8)
_EXIT(2)                    Linux Programmer's Manual                   _EXIT(2)
_exit, _Exit - terminate the calling process
noreturn void _exit(int status);
#include <stdlib.h>
noreturn void _Exit(int status);
_Exit(): _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L
_exit() terminates the calling process "immediately".  Any open file descriptors belonging to the process are closed.  Any children of the process are inherited by init(1) (or by the nearest "subreaper" process as defined through the use of the prctl(2) PR_SET_CHILD_SUBREAPER operation).  The process's parent is sent a SIGCHLD signal.
The value status & 0xFF is returned to the parent process as the process's exit status, and can be collected by the parent using one of the wait(2) family of calls.
The function _Exit() is equivalent to _exit().
These functions do not return.
POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.  The function _Exit() was introduced by C99.
For a discussion on the effects of an exit, the transmission of exit status, zombie processes, signals sent, and so on, see exit(3).
The function _exit() is like exit(3), but does not call any functions registered with atexit(3) or on_exit(3).  Open stdio(3) streams are not flushed.  On the other hand, _exit() does close open file descriptors, and this may cause an unknown delay, waiting for pending output to finish.  If the delay is undesired, it may be useful to call functions like tcflush(3) before calling _exit().  Whether any pending I/O is canceled, and which pending I/O may be canceled upon _exit(), is implementation-dependent.
C library/kernel differences In glibc up to version 2.3, the _exit() wrapper function invoked the kernel system call of the same name.  Since glibc 2.3, the wrapper function invokes exit_group(2), in order to terminate all of the threads in a process.
The raw _exit() system call terminates only the calling thread, and actions such as reparenting child processes or sending SIGCHLD to the parent process are performed only if this is the last thread in the thread group.
execve(2), exit_group(2), fork(2), kill(2), wait(2), wait4(2), waitpid(2), atexit(3), exit(3), on_exit(3), termios(3)
ZMORE(1)                     General Commands Manual                    ZMORE(1)
zmore - file perusal filter for crt viewing of compressed text
zmore [ name ...  ]
The zmore command is a filter which allows examination of compressed or plain text files one screenful at a time on a soft-copy terminal.  The zmore command works on files compressed with compress, pack or gzip, and also on uncompressed files.  If a file does not exist, zmore looks for a file of the same name with the addition of a .gz, .z or .Z suffix.
The zmore command normally pauses after each screenful, printing --More-- at the bottom of the screen.  If the user then types a carriage return, one more line is displayed.  If the user hits a space, another screenful is displayed.  Other possibilities are enumerated later.
The zmore command looks in the file /etc/termcap to determine terminal characteristics, and to determine the default window size.  On a terminal capable of displaying 24 lines, the default window size is 22 lines.  To use a pager other than the default more, set environment variable PAGER to the name of the desired program, such as less.
Other sequences which may be typed when zmore pauses, and their effects, are as follows (i is an optional integer argument, defaulting to 1) :
i<space> display i more lines, (or another screenful if no argument is given)
^D     display 11 more lines (a ``scroll'').  If i is given, then the scroll size is set to i.
d      same as ^D (control-D)
iz     same as typing a space except that i, if present, becomes the new window size.
is     skip i lines and print a screenful of lines
if     skip i screenfuls and print a screenful of lines
q or Q Quit.
=      Display the current line number.
i/expr search for the i-th occurrence of the regular expression expr. The user's erase and kill characters may be used to edit the regular expression.  Erasing back past the first column cancels the search command.
in     search for the i-th occurrence of the last regular expression entered.
!command invoke a shell with command.  The character `!' in "command" is replaced with the previous shell command.  The sequence "\!" is replaced by "!".
:q or :Q Quit (same as q or Q).
.      (dot) repeat the previous command.
The commands take effect immediately, i.e., it is not necessary to type a carriage return.  Up to the time when the command character itself is given, the user may hit the line kill character to cancel the numerical argument being formed.  In addition, the user may hit the erase character to redisplay the --More-- message.
At any time when output is being sent to the terminal, the user can hit the quit key (normally control-\).  The zmore command will stop sending output, and will display the usual --More-- prompt.  The user may then enter one of the above commands in the normal manner.  Unfortunately, some output is lost when this is done, due to the fact that any characters waiting in the terminal's output queue are flushed when the quit signal occurs.
The terminal is set to noecho mode by this program so that the output can be continuous.  What you type will thus not show on your terminal, except for the / and !  commands.
If the standard output is not a teletype, then zmore acts just like zcat, except that a header is printed before each file if there is more than one file.
/etc/termcap Terminal data base
more(1), gzip(1), zdiff(1), zgrep(1), znew(1), zforce(1), gzexe(1)
SHELLCHECK(1)                                                      SHELLCHECK(1)
shellcheck - Shell script analysis tool
shellcheck [OPTIONS...] FILES...
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
ShellCheck gives shell specific advice.  Consider this line:
(( area = 3.14*r*r ))
• For scripts starting with #!/bin/sh (or when using -s sh), ShellCheck will warn that (( .. )) is not POSIX compliant (similar to checkbashisms).
• For scripts starting with #!/bin/bash (or using -s bash), ShellCheck will warn that decimals are not supported.
• For scripts starting with #!/bin/ksh (or using -s ksh), ShellCheck will not warn at all, as ksh supports decimals in arithmetic contexts.
-a, --check-sourced Emit warnings in sourced files.  Normally, shellcheck will only warn about issues in the specified files.  With this option, any issues in sourced files will also be reported.
-C[WHEN], --color[=WHEN] For TTY output, enable colors always, never or auto.  The default is auto.  --color without an argument is equivalent to --color=always.
-i CODE1[,CODE2...], --include=CODE1[,CODE2...] Explicitly include only the specified codes in the report. Subsequent -i options are cumulative, but all the codes can be specified at once, comma-separated as a single argument.  Include options override any provided exclude options.
-e CODE1[,CODE2...], --exclude=CODE1[,CODE2...] Explicitly exclude the specified codes from the report. Subsequent -e options are cumulative, but all the codes can be specified at once, comma-separated as a single argument.
-f FORMAT, --format=FORMAT Specify the output format of shellcheck, which prints its results in the standard output.  Subsequent -f options are ignored, see FORMATS below for more information.
--list-optional Output a list of known optional checks.  These can be enabled with -o flags or enable directives.
--norc Don't try to look for .shellcheckrc configuration files.
-o NAME1[,NAME2...], --enable=NAME1[,NAME2...] Enable optional checks.  The special name all enables all of them. Subsequent -o options accumulate.  This is equivalent to specifying enable directives.
-P SOURCEPATH, --source-path=SOURCEPATH Specify paths to search for sourced files, separated by : on Unix and ; on Windows.  This is equivalent to specifying search-path directives.
-s shell, --shell=shell Specify Bourne shell dialect.  Valid values are sh, bash, dash and ksh.  The default is to deduce the shell from the file's shell directive, shebang, or .bash/.bats/.dash/.ksh extension, in that order.  sh refers to POSIX sh (not the system's), and will warn of portability issues.
-S SEVERITY, --severity=severity Specify minimum severity of errors to consider.  Valid values in order of severity are error, warning, info and style.  The default is style.
-W NUM, --wiki-link-count=NUM For TTY output, show NUM wiki links to more information about mentioned warnings.  Set to 0 to disable them entirely.
-x, --external-sources Follow source statements even when the file is not specified as input.  By default, shellcheck will only follow files specified on the command line (plus /dev/null).  This option allows following any file the script may source.
FILES... One or more script files to check, or "-" for standard input.
tty    Plain text, human readable output.  This is the default.
gcc    GCC compatible output.  Useful for editors that support compiling and showing syntax errors.
For example, in Vim, :set makeprg=shellcheck\ -f\ gcc\ % will allow using :make to check the script, and :cnext to jump to the next error.
<file>:<line>:<column>: <type>: <message>
checkstyle Checkstyle compatible XML output.  Supported directly or through plugins by many IDEs and build monitoring systems.
<?xml version='1.0' encoding='UTF-8'?> <checkstyle version='4.3'> <file name='file'> <error line='line' column='column' severity='severity' message='message' source='ShellCheck.SC####' /> ... </file> ... </checkstyle>
diff   Auto-fixes in unified diff format.  Can be piped to git apply or patch -p1 to automatically apply fixes.
--- a/test.sh +++ b/test.sh @@ -2,6 +2,6 @@ ## Example of a broken script. for f in $(ls *.m3u) do -  grep -qi hq.*mp3 $f \ +  grep -qi hq.*mp3 "$f" \ && echo -e 'Playlist $f contains a HQ file in mp3 format' done
json1  Json is a popular serialization format that is more suitable for web applications.  ShellCheck's json is compact and contains only the bare minimum.  Tabs are counted as 1 character.
{ comments: [ { "file": "filename", "line": lineNumber, "column": columnNumber, "level": "severitylevel", "code": errorCode, "message": "warning message" }, ... ] }
json   This is a legacy version of the json1 format.  It's a raw array of comments, and all offsets have a tab stop of 8.
quiet  Suppress all normal output.  Exit with zero if no issues are found, otherwise exit with one.  Stops processing after the first issue.
ShellCheck directives can be specified as comments in the shell script. If they appear before the first command, they are considered file-wide. Otherwise, they apply to the immediately following command or block:
# shellcheck key=value key=value command-or-structure
For example, to suppress SC2035 about using ./*.jpg:
# shellcheck disable=SC2035 echo "Files: " *.jpg
To tell ShellCheck where to look for an otherwise dynamically determined file:
# shellcheck source=./lib.sh source "$(find_install_dir)/lib.sh"
Here a shell brace group is used to suppress a warning on multiple lines:
# shellcheck disable=SC2016 { echo 'Modifying $PATH' echo 'PATH=foo:$PATH' >> ~/.bashrc }
Valid keys are:
disable Disables a comma separated list of error codes for the following command.  The command can be a simple command like echo foo, or a compound command like a function definition, subshell block or loop.  A range can be be specified with a dash, e.g. disable=SC3000-SC4000 to exclude 3xxx.
enable Enable an optional check by name, as listed with --list-optional. Only file-wide enable directives are considered.
source Overrides the filename included by a source/.  statement.  This can be used to tell shellcheck where to look for a file whose name is determined at runtime, or to skip a source by telling it to use /dev/null.
source-path Add a directory to the search path for source/.  statements (by default, only ShellCheck's working directory is included). Absolute paths will also be rooted in these paths.  The special path SCRIPTDIR can be used to specify the currently checked script's directory, as in source-path=SCRIPTDIR or source- path=SCRIPTDIR/../libs.  Multiple paths accumulate, and -P takes precedence over them.
shell  Overrides the shell detected from the shebang.  This is useful for files meant to be included (and thus lacking a shebang), or possibly as a more targeted alternative to 'disable=SC2039'.