scl man page
scl — Setup and run software from Software Collection environment
scl enable|run <collection1> [<collection2> ...] <command> [-x|--exec]
scl load|unload <collection1> [<collection2> ...]
scl list-packages <collection>
scl register <path>
scl deregister <collection> [-f|--force]
scl man <collection>
This manual page documents scl, a program which is an utility for running software packaged as a Software Collection.
scl utility allows to execute an application which is not located in the filesystem root hierarchy but is present in an alternative location. This application can still use and benefit from software installed in the root filesystem. In order to let an application be visible to the system one has to use scl utility as an interface.
- enable, run <collection1> [<collection2> ...] <command> [-x|--exec]
Run <command> within the environment of the given collections. Each collection contains a module file that defines how collection modifies the environment. First the environment is modified according to module files of the given collections and then <command> is executed. Control is returned back to the caller with the original environment as soon as the <command> finishes. If <command> is '-' (dash) then it is read from the standard input.
If --exec is specified then function exec() will be used for command execution otherwise function system() will be used.
Note: if you use <command> consisting of multiple arguments, you either need to use quotes or the -- command separator. Everything that follows the separator will be considered a command or its argument.
Note: some commands modify user environment in some way. Those commands may potentially break SCLs, as their activation also usually depends on env. modification as well. Typical examples of such commands are su and sudo. Every collection modifies the environment differently, thus more details may be found in the documentation of the particular collection.
- load <collection1> [<collection2> ...]
Load the given collections into current shell. The environment of current shell is modified according to module files of the collections.
- unload <collection1> [<collection2> ...]
Unload the given collections from current shell. The environment of current shell is returned back to the state before loading the collections.
Lists all installed Software Collections on the system.
- list-packages <collection1> <collection2> ...
If a collection name is specified then list of installed packages belonging to the collection is listed.
- register <path>
If <path> leads to valid SCL file structure, scl will register that as a SCL. <path> directory needs to contain module file and root directory, to be considered valid SCL. <path> needs to be an absolute path to the collection location.
- deregister <collection> [-f|--force]
<collection> will no longer be considered SCL. If the <collection> was installed locally, then the use of --force is needed.i
- man <collection>
Show manual page for <collection>.
- scl enable example 'less --version'
runs command 'less --version' in the environment with collection 'example' enabled
- scl load foo bar
Load foo and bar Software Collections into current shell
- scl unload foo bar
Unload foo and bar Software Collections from current shell
- cat my_command | scl enable baz -
run set of commands listed in my_command file in the environment with baz Software Collection enabled
- scl list-collections
list all installed collections
- scl list-packages example
list all packages within example collection
- scl register /foo/bar
registers new collection with a name bar
- scl deregister bar --force
forces the deregistration of collection bar
- A wrapper script must use proper quoting or command separator like in the
#!/bin/bash COMMAND="ruby $(printf "%q " "$@")" scl enable ruby193 "$COMMAND" # or scl enable ruby193 -- $COMMAND
scl was written by Jindrich Novy <email@example.com> and Jan Zeleny <firstname.lastname@example.org>.