The restriction of the `apps._app_name_.command` property is too strict
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snapcraft |
Confirmed
|
Undecided
|
Unassigned | ||
snapd |
Triaged
|
Medium
|
Unassigned |
Bug Description
I'm migrating a snap with a legacy snapcraft syntax to the new one with bases, however the previous command used to launch the application:
```yaml
command: >
bin/zenity
--info
--title='My Awesome App'
--width=600
```
no longer work and causes the following Snapcraft error message:
```
Failed to generate snap metadata: The specified command 'bin/zenity\n --info\n --ok-label=\'Got it\'\n --title=\'My Awesome App\'\n --text=\'This is a demonstrative application for Snapcrafters Template Plus.\\nIt indicates that the snapped application has been launched properly.\'\n --window-
The command must consist only of alphanumeric characters, spaces, and the following special characters: / . _ # : $ -
```
although this problem can be easily workarounded by using a launcher we probably should reconsider whether we should impose a restriction to this property as it can be any arbitrary string.
description: | updated |
Changed in snapcraft: | |
milestone: | none → 3.4 |
Changed in snapcraft: | |
milestone: | 3.4 → 3.5 |
Changed in snapd: | |
status: | Confirmed → Triaged |
importance: | Undecided → Medium |
I encountered this problem again with `command: bin/guvcview --audio=pulse` (the `=` character seems to be the trigger)