On Fri, Mar 18, 2016 at 5:31 AM, Sergio Schvezov < sergio.schve...@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
-- snappy-devel mailing list snappy-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
