<html><head></head><body><div>On Fri, 2016-03-04 at 06:59 +0100, Didier Roche wrote:</div><blockquote type="cite"><pre>Discussing with Michael yesterday, it seems that this wasn't really
discussed in the past and may be a good change for 16.04 for the big
cleanup time :)
I was first surprised to see that when starting an application, the
current directory was SNAP_APP_PATH.
In traditional systems, the current directory is generally a path where
the app have write access to (like $HOME or the one your are in for CLI).
I realize that in most of the snappy apps/services I'm writing, I'm
doing `cd $SNAP_APP_DATA_PATH` as first thing in most of them.
In that case, is there any particular reason to set the current working
directory to SNAP_APP_PATH instead of SNAP_APP_DATA_PATH or would a
change to set it to the latter makes sense for 16.04?
</pre></blockquote><div><br></div><div>I imagine the reason that Snap does this is because Click does, we start applications on the phone in the application directory. The advantage this provides is that when a toolkit/language looks for modules it very often will look in relative paths. Most of the time this can be overridden with environment variables, but people aren't used to doing that with Click's today because they don't have to.</div><div><br></div><div>While I don't have strong feelings on which way to go, I don't think it'd be good for applications to assume that the directory they're started in is writable. That isn't a good assumption even on a deb based system as you could quite easily be started in / from a terminal. You should write your data/config files in an appropriate place depending on the environment.</div><div><br></div><div>So I think that it's six of one, half dozen of another. Apps should resolve all their directories for modules <i>and</i> for data paths, but developers are lazy and they use cwd for too much. For me, it seems the same, so I'd be in favor of sticking with the status quo.</div><div><br></div><div>Ted</div><div><br></div></body></html>