Defining a command

When creating snapcraft.yaml to build a new snap, its executable components are built from parts, following the Snapcraft lifecycle, and selectively made available to the host system.

Exposing executable components

An executable is exposed to the host system via one or more sub-sections beneath the top-level apps section of snapcraft.yaml.

To give an executable the same name as the snap, ensure the sub-section name matches the snap name.

For example, here’s a complete snapcraft.yaml for a fully-functional snap:

name: os-release
base: core22
version: '0.2'
summary: Outputs the contents of /etc/os-release
description: Prints the contents of os-release
grade: stable
confinement: strict
apps:
  part-os-release:
    command: bin/os-release.sh
parts:
  part-os-release:
    plugin: dump
    source: .
    organize:
      os-release.sh: bin/

The above example creates a snap from the following simple script, called os-release.sh, located within the top-level snap of the directory:

#! /bin/sh
cat /etc/os-release

Make sure the above script is executable by running the following command on the build host after creating the script:

$ chmod +x os-release.sh

The os-release.sh executable is brought into the snap via part-os-release, which is a part using the dump plugin. It then uses organize to copy the os-release.sh file into the snap’s bin/ directory before the top-level apps section exposes the bin/os-release.sh executable to the host system

Services can be managed with a set of additional commands. See Services and daemons for more information and for further details on other metadata, see Snapcraft app and service metadata.

If you need to add user configurable options to your service or daemon, such as which port it should use, see Adding snap configuration.

See Tab completion if you wish to add command line tab completion to your snap.

:information_source: Interfaces enable an app to access system resources. Interfaces that are required for normal operation are specified at snap build-time within the above app metadata of a snap’s snapcraft.yaml. See Adding Interfaces for more details.

1 Like

Snapcraft app and service metadata

Link is broken, should point to https://snapcraft.io/docs/snapcraft-app-and-service-metadata .

Also, I think there should be some reference to commands/apps in the sidebar under Creating a snap, probably this article.

1 Like

Thanks for letting us know about the broken link, and for your suggestion about adding this to the outline. It’s a good idea so I’ve added it.

The example does not compile.

“Issues while validating snapcraft.yaml: ‘parts’ is a required property”

Thanks so much for letting us know. There was a typo in the example snapcraft.yaml. part: should have been parts:. Also, after just testing this, we also need to ensure os-release.sh is executable (chmod +x os-release.sh). I’ll update the doc. Thanks again!

1 Like

“with with part name”

“Make sure the above script [is] executable:”

And regarding that last line, when you suggest running:

“$ chmod +x os-release.sh”

it’s not at all clear where you want the user to run this. On the build host? Or perhaps embedded in the snapcraft.yaml file?

Just to expand on that last point (chmod +x os-release.sh), if that needs to be executable, could that be accomplished either by setting “x” on the build host so that it’s installed in the snap that way, or by defining some sort of scriptlet that does that during the snap build process?

Thanks for the fixes - I’ve tried to make the text a little clearer. The script is really just a simple example using the dump plugin, standing in for what could be the result of building a part or exposing a binary in some other way. It could be made executable from within the snapcraft.yaml, but I’d assume most executables would already have this bit set, so this could be an edge case.

“A snap’s executable is exposed to the host system via the top-level apps section of snapcraft.yaml. Its name needs to correspond with part name responsible for staging the executable within your snap.”

Um, no, there is no connection between the part name and the corresponding executable name.

“A snap’s executable …” This makes it sound like a snap has only one executable.

1 Like

Thanks for this. I’m not sure where that misunderstanding started, but you’re absolutely right. I just tested to make sure and updated the doc.

Since the app name needs to match the snap name for exposing an executable, maybe in the snapcraft.yaml file the app part-os-release should be renamed to os-release?