Hidden commands

I’d like to propose “hidden” commands. These would be commands that do not display with command completion and do not display in “snap info SNAP”

Rationale: Sometimes you want commands in your snap but you do not want normal users to know they are present. For example, troubleshoot commands, which could have unacceptable consequences in normal production case but which may be appropriate in troubleshoot cases.

1 Like

How would you expect the user to run such hidden commands?

They would type them in completely.

Can you give me an example please?

wifi-connect snap (currently alpha release) has commands that I want to preserve, but I do not want users to run them. They are not needed in normal operations and could even create state problems. However, I want them available for devel and troubleshooting scenarios.

For example, the wifi-connect deamon starts (and stops) up a web server/portal when needed. The user should never run the command that starts the portal. But having such a command is useful during development (without it I need to wait until the daemon decides to put up the portal). Having a hidden command would seem to accomplish the goals.

Another example: wifi-connect.netman command. This displays external SSIDs then allows the user to pick one, enter the passphrase, and connect. Normally, users should never use this (they use the web page instead). But, it is useful for verifying my code (that uses network manager dbus – unit tests mock dbus). It may also be useful to troubleshoot a problem by a user in the field. Currently, there is no good way to provide the command but discourage its use. Hiding the command would seem to accomplish this.

Are there ever any scenarios where it might be legitimate for users to run these commands, or would they be entirely for your own use?

troubleshooting. imagine they are interacting with a support person who tells them the command to run.

Not saying no, just wondering if for troubleshooting something like this would be enough:

$ snap run --shell my-snap
$ $SNAP/troubleshoot-command

Then all you need to do is just don’t put it under apps


Well, then you don’t get snapcraft’s help setting up the environment for you, which can be pretty painful especially when you start talking about multiple architectures. Personally I’d just export them as normal and show a big warning banner of some kind.

This feels like a work around though, and pushing the work to the developer.

I propose that this is a legitimate case that many will face, and if so should be on the roadmap.

I’d like to hear whether folks think it is is/not a legitimate use case.

“hiding” a command from tab completion means removing it from the path. Let’s say, as a strawman, that we add a directory to the snaps directory, and the directory doesn’t live on the path. That means that to tell the user what to run, you first need to know if the distribution they’re running things on has snaps in /snap, or in /var/lib/snapd/snap (or in C:\Users\%USERNAME%\AppData\Local\Snaps), and then tell them to type in, say, /var/lib/snapd/snap/.bin/myapp.s3cr3t. I’m going to go on to state that this is ridiculous, user-hostile, and not something we should pursue.

One thing we could do is have apps that are not presented to the user in any way, other than through snap run. I think snap run myapp.s3cr3t is less user-hostile than the other option.

On the other hand, the idea of a binary blob having secret commands gives me the heebie jeebies. Why was this a good idea again?

1 Like

Why (other than “heebie jeebies” ) do you think this is not a real use case that snapcraft might want to support?

On reflection what I’m opposed to is hiding it from snap info, lying to the user by omission. Uncluttering the user’s path seems like a good thing.

I think we might even want to hide daemons from the path by default, with the .service file just calling snap run directly; very few daemons are meant to be invoked by the user.

EDIT: having said that, hiding them by default would make backwards compatibility hard, so let’s not do that :slight_smile:

1 Like

I’ve decided to use command options and simply not display in help the options I want to keep hidden. So the command is not hidden but certain options are, which meets my needs.

1 Like