<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 17/08/2016 15:20, Mark Shuttleworth wrote: </div> <blockquote cite="mid:a028dd37-2608-8c02-5354-03712260901c@ubuntu.com" type="cite"> <pre wrap="">On 16/08/16 22:09, Sergio Schvezov wrote: </pre> <blockquote type="cite"> <pre wrap="">Create a new `apps` entry like this apps: sh: command: bash plugs: [same list of plugs used by what calls git] There's a `snap shell` (or similar) command making a come back some time and would make this more straightforward. </pre> </blockquote> <pre wrap=""> Given the nature of sandboxing during the development process ("zomg the glass walls!") I think we should have a first-class command that spawns a $SHELL (not the shell of the snap but your preferred shell) inside the sandbox.</pre> </blockquote> Isn't that the purpose of the 'snap run --shell' command? $ snap run --help [...] [run command options] --shell run a shell instead of the command (useful for debugging) David <blockquote cite="mid:a028dd37-2608-8c02-5354-03712260901c@ubuntu.com" type="cite"> <pre wrap=""> It might be reasonable to have a snap.yaml flag to turn that ability OFF for some snaps, but it seems silly to have boilerplate for debugging purposes. For example, how about adding a 'enter-sandbox' command to snap, so: $ snap enter-sandbox app.command Now running inside the sandbox for app.command $ And in snap.yaml: debugging: [ allow-sandbox ] Mark </pre> <fieldset class="mimeAttachmentHeader"></fieldset> </blockquote> </body> </html>