Howdy, This is all just from my general experience, but as I see it you have two approaches, which will vary by the overall design you have going.
Approach 1- user only application. The application runs entirely from within each user's home directory, or rather a branch of the home directory. If you need to share files between different clients on the machine you could have it create a share folder with appropriate permissions, like 775 or 777, then the clients could discover each other by iterating through the /home directories and making a list of clients they find, using the client directory as a flag. This would spare anyone needing root access or administrator assistance in installing the application, but obviously has some drawbacks. Approach 2- You have a core installation with home directory components. Simple applications could easily reside in /usr/bin or /usr/sbin. I'm never sure which is more appropriate, but it doesn't really matter that much. Since your application has some self generated files, which I assume wouldn't need to be replicated out to each user, you might go with a more packaged approach and install it into a directory within /usr/local. I've seen a number of packages that use /usr/local/share/<subdir> for instance, and place their global configs inside /usr/local/etc. This is nice because you don't clutter up /etc but still have a logical directory structure. From there you could do the same thing with the home directories as mentioned above, but maybe with a simpler sharing scheme. Naturally this would all require the use of root to setup, but not to run. I'm sure my ideas have some flaws, but I'm undercaffeinated so it's the best I can come up with at the moment. =) I don't know how familiar you are with linux, so some vague info is below. It might be helpful. In general, here's where you're likely to find executables under linux: /bin /sbin /usr/bin /usr/sbin /usr/local/share/<application dir> Non-global configuration files, such as user preferences, are typically kept in the user's home directory, or a sub-directory thereof. It's pretty common to use a '.' so that default directory listings don't display the file/directory, helping to avoid a user accidentally trashing a config file they want. A handy shortcut for the home directory of the current user is '~/' . This makes it easy for your script or application to ignore the actual username involved. Your application, unless run as a daemon under its own user account with some sort of user agent for the client, will share the write permissions of the uid that spawned it. This could pose some challenges for permissions to common areas and should be kept in mind while generating any setup routines you have. Obviously you can use 777 to make something totally accessible, but this may not always be desirable. You could have a group be generated and use that group to more securely handle permissions, but then each user, that uses the app, will need to be administratively added to that group. A lot of systems no longer add user accounts to users anymore, so that easy out isn't reliable. Normally a user is just assigned to their own unique group. Thanks, Fargo Jim Wagner wrote: > Greetings - > > I need to find an appropriate location for application files under > Linux. > > These files will include ones generated by the application as it > functions and user-supplied script files. The application needs to > write these files only with standard user permissions. The user also > needs ready access to the files. There does not appear to be a blessed > Documents folder under Linux so what are some of the expected > locations? > > Thanks > Jim Wagner > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> > > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
