Application cwd in SNAP_APP_PATH vs SNAP_APP_DATA_PATH

[Gustavo Niemeyer]

On Fri, Mar 18, 2016 at 5:31 AM, Sergio Schvezov <
sergio.schvezov at canonical.com> wrote:
>
> >>> Why not SNAP_USER_DATA? As a user I cannot do anything on SNAP_DATA
>

As predicted. :-)

I'd use PWD for everything to avoid confusions.
>


> Coincidentally though, the systemd units would make use of
> `WorkingDirectory=` to set it to SNAP_DATA for root run services and
> SNAP_USER_DATA for user ones (when those come).
>

Yes, that indeed feels like a better approach, and an expected one since
it's exactly how processes have always worked in Linux.

Another reason to do it is that it opens the door for us to handle command
lines in a more standard way in terms of relative paths, when security
constraints permit.

The consequence, though, is that processes cannot assume they are inside
their data directory, because they might well not be. But I think that's
alright.. per my initial point in this thread - it's usual for applications
to pick their preferred working space and move there, when they don't want
to work on the local relative path context.

The binaries one is quite tricky because I'll try to access a file and
> all of the sudden I'll get "No such File or directory" style errors.
>
>
>     $ cd ~
>     # in theory this would be just `vim` in the future.
>     $ vim.editor Documents/myfile
>


In practice, actually. We already agreed that when <snap name> == <app
name>, the executable name becomes just <snap/app name> rather than <snap
name>.<app name>.

I still prefer SNAP_USER_DATA though.
>

If we change to that, tomorrow someone will come along and report a bug
about it not being $SNAP_DATA again. :-)


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160318/05e46ef2/attachment.html>