Commands and aliases

doc
1

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 of snap info lists the applications a snap makes available beneath the commands: section:

$ snap info vlc
name:      vlc
summary:   The ultimate media player
(...)
commands:
  - 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 aliases command:

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

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

$ sudo snap unalias lxd
Removed:
  - lxd.lxc as lxc

$ sudo snap prefer lxd 
Added:
  - lxd.lxc as lxc

The prefer command enables all aliases for a given snap in preference to conflicting aliases from other snaps. This allows you to switch application preference between alternative options provided by other snaps.

A snap can also be installed with an additional --unaliased argument to prevent aliases being created automatically:

$ snap install lxd --unaliased
lxd 4.22 from canonical✓ installed
$ snap aliases lxd
Command  Alias  Notes
lxd.lxc  lxc    disabled

Requesting aliases

As there is no guarantee that an alias 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
Added:
  - 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 alias is also straightforward:

$ sudo snap unalias my-vlc    
Removed:
  - vlc as my-vlc
1 Like
2

@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.:

<!--
** NOTE TO EDITORS **

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.

3

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

4

@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.

5

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.

6

@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.

7

@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.

8

This should be corrected to:

1 Like
9

fixed - thanks for letting us know!

10

Should perhaps link to https://docs.snapcraft.io/service-management ?

11

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

12

This explanation of the prefer command seems to contradict the code sample preceding it.
Also the man page says it

enables all aliases of the given snap in preference to conflicting aliases of other snaps[…]

13

Thanks for flagging this. I’ve updated the prefer text to copy the help text and to hopefully better explain what it does.

14
  • “The output to [of] snap info …”
  • “As there is no guarantee that an alias[es] is going to be unique …”
  • “Removing a manually created alias[es] is also straightforward:…”
15

Great typo spotting, thank you!

16

Is it worth pointing out the install “–unaliased” option, which installs a snap without its automatic aliases?

17

Good suggestion - now added, thanks!

18

it should be «Aliases can be viewed with the snap aliases command»

1 Like
19

Good spot! Thanks so much for letting us know!

20

What does that final short section, “Daemons and Services,” have to do with aliases?