Where should I put a .desktop file in order to ensure that most desktop environments find it? Is there such a location? In addition, is there any standard place to put it in the user's home directory so that only that user sees it?
Gnome puts them in /usr/share/applications. My personal ones seem to show up on ~/Desktop, but these all seem Wine-related. Some also show up in ~/.local/share/applications. The good people at freedesktop.org have a specification of what they should look like, but I can't find a standard about where they should go.
Unless I'm missing something, you're looking for the user's home directory, usually /home/user/.desktop
If you want to restrict it to just the user, issue chmod 600 /home/username/.desktop to ensure only the user can see it.
Related
Wording the title was a little tricky, but here's the situation. I am making a install.sh file for my game which is written in Python. I am trying to create a game folder with all assets instead of making this a module for Python. I may be doing things the hard way, but this method seems to work well.
The install.sh copies the game's directory to the HOME folder and moves a .desktop file and game's icon to the appropriate places (ie. desktop, applications folder). The issue is, this .desktop file uses Icon=~/.local/share/icons/game.png and Exec=~/Game/game.sh which causes the icon not to show up in the .desktop file or menu nor does the game shortcut execute. I replaced the ~ with $HOME and I get the same issue. However, if I change it to /home/(my account) instead of ~ or $HOME it will work perfectly and show the icon.
Is there a way to make the install bash file create this .desktop file dynamically if a user installs the game? Or is there some way of getting this to work that I am unaware of?
EDIT: Better explanation... ish.
Alternatively, put ~/.local/share/applications in the premade .desktop file, and then sed 's/~/$HOME/g' appname.desktop > $HOME/.local/share/applications/appname.desktop in the installer script, or invoke that from your language interpreter as a shell exec.
It's a real shame that more projects with GUIs don't do this. These desktop files also need a 'wmClass' element in them in order to allow for the launcher to also be a window tab. I've manually fixed several applications for my convenience this way.
Seems the easiest way was to include the files system-wide. While not my intention, it made it far easier to install all the proper files and get things works.
Putting the .desktop file in /usr/share/applications and icon file in /usr/share/icons/
Hi I'm sure there is some way of doing what I want, but maybe I'm just attacking it the wrong way. Hope someone can help.
I have a dev box that I SSH in to from several other machines. In order to debug remotely I need to configure my debugger with my client machine's IP, which changes when I log in from different machines. I'm getting bored of doing this manually all the time so thought I'd try and automate it.
I'm creating a script that is automatically run upon SSH connection that will modify a configuration setting in a PHP ini file. The problem is the PHP ini files are all owned by root so I'm not sure how to modify those files if I'm just logging in as a normal user.
There's not really a security concern with my dev box so I could just change the owner of the ini file, but I wanted it to be more automated than that.
My current attempt is a python script located in my home dir, which is called from .bashrc when I connect via SSH. I don't see how I can gain root privileges from there, I am pretty new to linux though. I thought maybe there would be some other method I'm not aware of.
You have a file that is owned by root. You clearly need to either find a way to mark the file as modifiable by you; or a way for you to elevate your privileges so that you are allowed to modify it.
This leads to the two traditional unix approachs to doing this. They are:
To create a group with which to mark the file, ie. initdebug; chgrp/chmod the file so it has the initdebug group and is group writable; and, add yourself to the initdebug group so you can use the group write permission to modify the file.
To create a very small, audited binary executable (this won't work with a script) that will perform the specific modifications you desire (for simplicity I would suggest copying one of a selection of root owned PHP ini files into the right place). Then chown'ing the file so it is owned by root, and setting the suid bit on the executable so it will execute as root.
You can also combine the two approaches, either:
Not making yourself a member of the initdebug group or suid on the executable, but rather setting group of the executable to initdebug and setting its sgid bit; or,
Keeping the executable suid root but making it only executable by initdebug and therefore only executable by users added to that group.
The security trade off is in the ease/risk of privilege escalation should someone hack your account. If there is a stack/heap overflow or similar vulnerability in the executable and it is executing as root, then you are gone. If the PHP ini file can be modified to open a remote-vulnerability then if they can directly access the ini file you are gone.
As I suspect the latter is possible, you are probably best off with a small executable.
Note: As I alluded to above, unix does not acknowledge the s[ug]id bits on scripts (defined as anything using the #!... interpreter syntax). Hence, you will have to use something you can compile down to a binary. So that probably means either C, C++, Java(using gcj), ML, Scheme(mit), Haskell(ghc).
If you haven't done any C or C++ programming before, I would recommend one of the others as a suid binary is not a project with which to learn C/C++. If you don't know any of the other languages, I would recommend either ML or Java as the easiest to to write something small and simple.
(btw, http://en.wikipedia.org/wiki/List_of_compilers includes a list of alternative compilers you can use. Just make sure it compiles to native, not bytecode. As far as the OS is concerned a bytecode vm is just another interpreter).
you can do it with insert your user to sudoers file on mechine that you want to remote,
for the example you can see my blog.
this is the url : http://nanamo3lyana.blogspot.com/2012/06/give-priviledge-normal-user-as-root.html
and then on your automaticly script add sudo on your command.
i'm sorry my english not good.
How can I add a Matlab search path for all users on a Linux system?
I am managing a Linux computer that is shared by several people.
I want to place some Matlab *.m files at a path (for example, /usr/local/matlab/our_matlab_scripts/) which everyone has a read access permission.
I also want to add this path to the Matlab search paths of all users
so that they can start using the Matlab files immediately.
As a single user, I learned that I can add a search path by Matlab 'addpath' command or from the file menu of Matlab, for example.
However, so far I could not find a way to do it as an administrator for all the current and future users at once.
I would be grateful if you could kindly teach me.
If you look at this thread:
http://www.mathworks.com/matlabcentral/newsreader/view_thread/112560
you will find that there is a file called matlabrc.m that is executed at startup. It looks for the startup.m file that users can have. One could put the addpath commands in this file and it should work for all users.
Is there a standard way of determining file locations under Linux? Even better, are there any POSIX API's which allow the retrieval of standard file locations?
For example, how can I determine a user's home directory? Or, how can I determine the proper location for system configuration files?
I know that typically these locations would be "/home/username" or "/etc/". Should I just hardcode the paths as such?
The path to the current user's home directory is in the environment variable HOME. (I know systems where home dirs are spread over several partitions (say, /vol/vol[number]/[first letter]/[user name]) and not located in /home/.)
For other users, there's getpwent (and getpwent_r), which pull the home directory from the passwd entry.
For the other directories, there is the File System Hierarchy Standard, which most Linux distros adhere to and some other OSen as well.
I don't think there's an API for this. Thus, if a system does things differently, you're on your own -- good luck! ;-)
The current user's home directory can be found in the HOME environment variable. For other users, you can use the getpwnam or getpwuid functions (or the _r variants) to look up another specified user's home directory, among other things.
I know that you didn't ask this, however if you're looking to find the location of an executable, you can use which
I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate?
Have a default of ~/.foo, and an option (for example --config-directory) that you can use to override the default while developing.
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be?
If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps ~/.foo/tracklog or something? Again, add a command line option, and also an option in the configuration file, to override this.
I'm not a fan of your ~/gpsdata default; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?
As stated above, I'd prefer ~/.foo/inbox. Also with command-line option and configuration file option to change this.
But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
Where should the script its self go?
This is usually up to the packaging system of the particular OS you're running on. When installing from source, /usr/local/bin is a sensible default that won't interfere with package managers.
Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/ is used for user-specific settings - it is hidden
$PREFIX/etc/foo/ is for system-wide configuration
$PREFIX/foo/bin/ is for system-wide binaries
sym-links from $PREFIX/foo/bin are added to $PREFIX/bin/ for ease of use
$PREFIX/foo/var/ is where variable data would live - this is where your input spools and log files would live
$PREFIX should default to /opt/foo even though almost everyone seems to plop stuff in /usr/local by default (thanks GNU!). If someone wants to install the package in their home directory, then substitute $HOME for $PREFIX. At least that is my take on how this should all work.