I've ended up following a somewhat different approach, of creating a new file type -- let's call it "sim(ulated)link" -- which contains the (relative) path of file to be open, and then created a script do deal with it.
Consider the following scenario:
"odl" for "OpenDocument Link". The contents of "foo.odl" being:
You can then create the following script to open
*.odl (adapted from terdon's answer):
declare -a targets
for file in "$@"; do
targets+=( "$(readlink -f "$( dirname "$file" )"/"$( <"$file" )")" )
(In case you don't want to use
readlink because it will follow the link in case the path thus specified is a symlink, you could simply go with:)
for file in "$@"; do
cd "$( dirname "$file" )"
libreoffice "$( <"$file" )"
You can then associate this script with
.odl files in your file manager (as explained in terdon's answer). Eventually, you will have to create a mime type for
.odl files and associate it with the script (lacking this step in my case worked, but associated all plain text files with the script, which was clearly undesirable).
Why have I preferred this alternative to the ones provided by PSkocik and terdon, even though they work perfectly fine? For three reasons:
Not all of my
.odt files (and links to them) have this structure that I have to open them "in the target file's directory". In this way, I affect the opening procedure only of the files of interest.
The system regular symlinks will work regardless of the settings in my current computer. This means that, if I happen to open one of these files in a computer in which I didn't change the settings to open
.odt files with my script, it will open anyway and I may inadvertently mess up with the paths of my hyperlinks within it. This way, if the computer is not setup to open
.odl files, they simply won't work, and I will have to go for the target files directly.
Lastly, in case I move or rename some of the directories involved, I can easily search and replace the
.odl files to correct the paths. (This is likely also doable with the symlinks, but seems somewhat harder).
Caveats: I think this will only work for a well formed, non redundant, relative path given in the
.odl file. There is probably a way to do things more robustly in the sense that it would work also with an absolute path or with a relative path with some redundancy in it.