Commands and aliases


When installing a snap, you’re often installing an application. If an application uses a GUI, it will be integrated into your desktop environment and it can be launched just like any other GUI application.

But applications installed from a snap can also be run from the command line, regardless of whether they’re GUI-based or terminal-based.

The following sections describe how to work with such snap applications.

Running applications

As covered in Getting started, a snap’s installed application(s) can be found under /snap/bin, and subsequently, often added to $PATH. This makes commands directly accessible from the command line.

If executing a command directly doesn’t work, try prefixing it with the /snap/bin path:

$ /snap/bin/vlc

Adding /snap/bin to your default $PATH makes running snaps that don’t automatically add themselves more convenient.

ⓘ A few Linux distributions use a path of /var/lib/snapd/snap/bin instead of the standard /snap/bin. You may need to experiment and update your path accordingly.

Application commands

The output to snap info lists the applications a snap makes available beneath the commands: section:

$ snap info vlc
name:      vlc
summary:   The ultimate media player
  - vlc

To avoid the potential conflict of snaps exposing applications with the same name, every snap has a namespace reserved for itself. The namespace uses the following syntax:

  • <snap name>
  • <snap name>.<application name>

The first option is used automatically when the exposed application name matches the name of the snap, such as with vlc. The second option is used for every other case.

Application aliases

The namespace syntax (see above) is effective at preventing conflicts, but it’s not ideal when applications have well known names that third-party scripts depend upon. This is where aliases are useful.

For example, the LXD container manager snap exposes the application as lxd. However, many third-party scripts depend on this being lxc. To solve this issue, the LXD snap creates an alias for lxc.

Aliases can be viewed with the snap alias command:

$ snap aliases lxd
Command  Alias  Notes
lxd.lxc  lxc    -

Unlike applications that use a snap’s namespace, there is no guarantee that an aliases is going to be unique. For this reason, they can be easily disabled and re-enabled:

$ sudo snap unalias lxd
  - lxd.lxc as lxc

$ sudo snap prefer lxd 
  - lxd.lxc as lxc

The prefer command disables aliases for both the snap you specify and for any installed snaps with the same conflicting aliases. This is why the command is prefer, because it allows you to switch application preference between alternative options.

Requesting aliases

As there is no guarantee that an aliases is going to be unique, and potential conflicts create a minor inconvenience, a snap’s default aliases are only enabled after a simple public review process.

The same review process also ensures that any default commands exposed by a snap are either named after the snap or, when different, reviewed to ensure the alias is relevant within the context of the application. This helps maintain a sane shared namespace for everyone.

If you want an alias enabled for your snap, please open a small forum topic in the store requests category with the details.

Manual aliases

Snap’s aliasing system supports the creation of arbitrary custom aliases defined for the local system. This allows applications to be exposed under any name that is convenient locally.

For example, the following exposes a new command under /snap/bin to support calling the vlc application as my-vlc:

$ sudo snap alias vlc my-vlc
  - vlc as my-vlc

$ snap aliases vlc
Command  Alias   Notes
vlc      my-vlc  manual

When a manual alias is set, the original application name will continue to function.

Removing a manually created aliases is also straightforward:

$ sudo snap unalias my-vlc    
  - vlc as my-vlc

Daemons and services

Some applications may also be exposed as daemons or services which run in the background automatically when the snap is installed.

See Service management for more details.

Getting started
Service management
Newbie Question: Adding commands
Snap documentation
Call for testing: dev-time-cli
Snap Documentation (page deprecated)

@niemeyer @degville Would it be okay if I convert the “NOTE TO EDITORS” block at the top of this and other posts into an HTML comment? e.g.:


This document is introductory material, and as such it is organized with a story line in mind. Each section builds upon information described in preceding sections. That also means the content is focused on foundational concepts, so it’s not a complete reference and not supposed to provide in-depth information about these aspects.

This will mean that it won’t display to visitors to this topic, but only to those who actually try to edit it, which seems sensible.

The reason for this is because, in the new docs website that will present this documentation content, I’d like to avoid post-processing the mark-up at all - so the content presented on the documentation website is exactly equivalent to the content found on the forum.


@nottrobin We want the content in the forum to look good as well, and that probably won’t.


@niemeyer Sorry how do you mean? It won’t display to regular forum users, so content will look better to them (in that they won’t have to see a loud “NOTE TO EDITORS”). It will only display in the edit window when you come to edit the content - to editors.

I’ve made the change in this post just now to show you what I mean. Let me know if it’s acceptable.


Some of the people reading the document here in the forum are editors, and seems nice that they are able to comfortably read such notes as they flow through the document, rather than only when they open the editor for a change. It’s a clearly labeled info box, and doesn’t seem hard to skip it when one is not an editor.


@niemeyer okay we can do it whichever way you think is best.

I have to admit, I really did think you’d prefer this approach as it makes reading the core content on the forum neater for everyday users, keeps the forum content closer to the documentation site, and keeps the documentation website application more naive and less custom - closer to representing pure Discourse content - which I thought was your philosophy in general and one I very much agree with.


@nottrobin I don’t have a strong opinion in this case, to be honest, and I’m fine with experimenting another way if we see some evidence that this is not a good plan. The trade off here, per the conversation above, is cleaning it up for users vs. making it slightly more friendly for editors to see such notes.

I’ll talk to @degville today in our daily meeting and exchange some ideas on the topic.


This should be corrected to:


fixed - thanks for letting us know!


Should perhaps link to ?


You’re absolutely right - thanks! This is fixed now.