Ubuntu – Make link open target file, not file at link location

symbolic-link

Sorry for the tags. I don't know whih one applies. Please remove not pertaining ones, then delete this line. Or comment, and I'll do it myself.

Background

I want to put a link to a file located in /home/myname/some/path/file.tex on my desktop. This TeX file calls other TeX files inside it. Now, when I open the link, which is located on the desktop, my TeX editor, it says I opened the file /home/myname/Desktop/file.tex. I can't compile this file, because the other TeX files the main TeX file relies upon are not located where the program expects them.

Main question

How can I make a link file open the target file in its actual location instead of on the desktop?

EDIT

The solution advertised here does not work as intended. With

#!/bin/bash
exec /home/myname/some/path/file.tex "$@"

I get

/tmp/geany_run_script_JVX1HZ.sh: 7: /tmp/geany_run_script_JVX1HZ.sh: ./open-file.sh: Permission denied


—----------------
(program exited with code: 126)
Press return to continue

Where open-file.sh is the wrapper script located on my desktop.

EDIT 2

Although, if I open a terminal and do

chmod a+x ./open-file.sh

and change exec to texstudio, which incidentally is the program I use to open .tex files, then I can open a terminal and do

bash open-file.sh

it will launch TeXStudio with the desired file loaded in the desired target location. I still can't just double-click open-file.sh on my desktop, since that will open my text editor, letting me edit the bash script. I want to double-click the open-file.sh script file and have TeXStudio open up my file.tex file.

### EDIT 3

From this question, I deduct that I have done everything right and the file should be clickable and be executed upon clicking. Unfortunately, it doesn't. I think my permissions are correct, afaik

and same here

-rwxr-xr-x me me 94 Apr 27 12:00 open-file

Best Answer

I don't know how to make a link itself work like this, but there's a relatively easy way to get it done.

The problem appears to be that program invoked to process your data is not running with its working directory set to the location of your data file.

Instead of linking the file itself, write a launcher script and pass your file location to it as a parameter. Then, link to the script from your desktop entry.

At least in KDE, this is easier to do by adding an entry to your Application Launcher with all the parameters set the way you want them and then dragging the entry from the menu to the desktop. It has a bunch of placeholder variables that let you modify the command and even lets you specify the working directory to use.

This could be simple or fancy. Start with simple:

#!/bin/bash
## Usage: launcheroo working-directory data-file
## defending this script is left as an exercise for the reader
## ... or you can ask in the comments ;)
cd "$1"
myprog "$2" ## or your more fancy exec that will figure out
            ## what program to run by itself

invoked as:

launcheroo path-to-data-files data-file

This handles the most basic usage, and illustrates the approach, but doesn't handle any errors like bad or missing parameters

To get a little fancier, you could extract the path from the specified data file path using dirname or bash parameter editing instead of passing it as a separate parameter.

A quick and dirty way to get this done - especially for testing how it works - would be to just edit the desktop icon to run

cd where-the-files-are ; exec ...

Since this is Linux, there are probably many other ways to do this as well.

If you add the file as an icon on the desktop, you can directly edit its .desktop file and get it to do all sorts of interesting things. I haven't done much with those.

Just saw this answer which is essentially the same as mine with a slightly different spin to it.

Related Solutions

Ubuntu – Symbolic link doesn’t use target working directory

You can't, you need to make a wrapper script.

Assuming that the program relies on the filename for determining the script (likely):

#!/bin/sh
exec /usr/local/android-ndk-r5/ndk-build "$@"

Assuming that the program relies on the current working directory (unlikely):

#!/bin/sh
cd /usr/local/android-ndk-r5
exec ./ndk-build "$@"

Save one of these files in /usr/local/bin/ndk-build and make it executable:

sudo editor /usr/local/bin/ndk-build
sudo chmod 755 /usr/local/bin/ndk-build

Ubuntu – Hard-link /home/theuser to its new location

Hard links in general are not particularly problematic. But hard links to directories are, which is why you have to use the -d flag to attempt to make one, and why you will probably not succeed anyway; the kernel is probably configured (or hard-coded, I'm not sure) to prohibit them.

Furthermore, as you've suspected you cannot hard link anything across volumes, so you won't be able to hard link /home/myuser to a directory on a different partition.

There are two types of links supported by the ln command--hard links, and soft links (also called symbolic links or symlinks).

A hard link to a file is the file. When you make a hard link, you're making it so that another filename identifies the file. Files in a Unix-style filesystem (like ext4, which Ubuntu uses by default) are identified uniquely by their inode number. When a file has multiple names, that is, multiple hard links (or, we can say, just multiple links), it continues to exist even if one or more of them are deleted, so long as at least one remains. (Then it continues to exist on disk until it is no longer open by any process.) The name of the low-level system function that does the work of rm is called unlink for this reason.

A soft link is not the file. It is instead a special kind of filesystem entry that points to a file by the target file's location and name. If you delete a file pointed to by a soft link, the soft link does not cause the file to continue to exist. If you delete or move/rename a file pointed to by a soft link, the soft link stops working to access the file, and is said to be broken.

Hard linking files across volumes does not work because a hard link is the file, and must be on the volume where the file's data is physically stored.

Hard linking directories (that is, having more than one name corresponding to the same directory inode) is generally a bad idea, and is usually prohibited, because it makes it possible to break basic (and reasonable) assumptions about how directories behave. For example, suppose I am in a directory called foo and I cd to a directory called bar. If directory hard links are not allowed, then I know I can get back to foo with cd ... But if directory hard links are allowed, then bar could actually be a hard link to a directory somewhere else. Furthermore, and much more seriously, a hard link is the file, and a hard link to a directory is the directory, so there can then be ambiguity about what directory really is the parent of bar.

On the other hand, soft links to directories are perfectly permitted. A directory foo can contain a soft link called bar which links to a directory somewhere else, but this doesn't cause problems because it is always clear what to do. It is always clear because there is an answer to the question what directory am I in really? So when you are treating the present working directory as the name you used to get there, it's the name of the symbolic link. And when you need to know what directory you're really in (for example, to compare two different paths to see if they're the same or one resides in the other), that works too.

So, you can make a soft link, or symbolic link, from /home/myuser to the new home directory. To make a soft link, use ln -s target source. You do not need to (and should not) specify the -d flag to make a directory soft link.

That might help ameliorate your problem. You could try it. But it would be even better to fix the problem itself. I recommend that you post a new question asking for how to solve the problem of some of your programs not working properly since you migrated your home directory to another partition (assuming that's what you did). Make sure to include specific information about all the programs that are having problems, including the full and exact text of any error messages, and also a description of exactly what changes you made to your Ubuntu configuration that triggered these problems and the complete contents of /etc/fstab and the output of echo $USER $HOME. (You should also link to this question, so people don't answer telling you just work around the problem by making a symbolic link.)