[SOLVED] [TC 8.01x32] Wrong Path in Internal Link From

[Hansl]

[edit SOLVED 2012-09-10 : was not a problem of TC, see #7 ]

If I let show a search result (Alt-F7, Alt-W) and do a double click on one resulting file with an internal link, TC returns a wrong path and the called application can't find the file.

The wrong path is either the search's root without the result's subfolder or even the path of another tab in the same window. (with Wine in Linux)
Image: http://io-n.de/images/Bildschirmfoto.png

Also, when afterwards rereading the directory (Ctrl-R), TC will not return to the search's root but to the path of the other tab.

[karlchen]

Hello, Hansl.

Hm. A first try which I made did not reproduce the problem which you explained:

• inside T.C. went to ~/Documents
• searched for *.pdf (alt-f7)
• applied the search results
• double-clicked a random filename
• PDF Reader opened and loaded the file without any problem

Environment:

• Total Commander 8.01 x64
• Linux Mint 13 Cinnamon Desktop x64
• Wine 1.4 x64
• Windows programme PDF Reader v4.3.1 32-bit

Kind regards,
Karl

[karlchen]

Hello, Hansl.

The second try which I made did not reproduce the problem which you explained, either:

• inside T.C. went to ~/Documents
• searched for *.odt *.doc *. (alt-f7)
• applied the search results
• double-clicked a random filename
• Libre Office Writer opened and loaded the file without any problem

Environment:

• Total Commander 8.01 x64 / Total Commander 8.01 x32
• Linux Mint 13 Cinnamon Desktop x64
• Wine 1.4 x64
• Genuine Linux software Libre Office v3.5.4 x64

Kind regards,
Karl
--
P.S.:
"Forgot" to mention this:
Inside T.C. there are internal associations for

• *.pdf => launching the Windows software PDF Reader
• *.odt *.doc => launching the genuine Linux Software Libre Office Writer with the help of a little scripts that transforms the Windows paths provided by T.C. into genuine Linux paths which will be understood by Libre Office.
• more file types => launching genuine Linux software

But:
With or without using this little helper script no slash gets ever prefixed to the paths which T.C. provides.

So the questions which you should answer are:

• Which kind of Libre Office do you launch by double-clicking in T.C.? A Windows version of Libre Office or the genuine Linux edition of Libre Office?
• If you launch the Linux edition, why do you expect Libre Office to be able to handle Windows style pathnames provided by T.C.? It cannot do so.
• Which wrapper script - if any - have you put between T.C. and Linux?
• Which Linux version exactly are you using?
• Which Wine version exactly are you using?

[karlchen]

Hello, Hansl.

This is my T.C. internal association for Typename: >DocTextDocuments (*.odt *.doc):
Open: "%COMMANDER_PATH%\..\TC_Addons\run_linux_program" libreoffice --writer "%1"

This is the script "%COMMANDER_PATH%\..\TC_Addons\run_linux_program":

Code: Select all

#!/bin/bash
# Programm: run_linux_programm
# Function: allow a programme running under Wine to launch a native Linux executable
# Source  : http://wiki.winehq.org/FAQ#head-91bf3f0a8ccbfab8dee96f82fae2f1a489e0d243
# Date    : 22-Feb-2012
# Usage   : /bin/bash run_linux_program /path/to/executable WindowsPath/to/datafile
#
case $# in
   3) $1 $2 "`/usr/bin/wine winepath -u "$3"`";;
   2) $1 "`/usr/bin/wine winepath -u "$2"`";;
   *) MSG="Usage:\n\n\t(1) run_linux_program /path/to/executable WindowsPath/to/datafile"
      MSG="${MSG}\n\n\t(2) run_linux_program /path/to/executable option WindowsPath/to/datafile"
      /usr/bin/zenity --error --title "Incorrect Commandline" --text "${MSG}";;
esac

This script is not generic and will not work for any Linux software, but it works for those applications that I launch from inside T.C.
Kind regards,
Karl

[Hansl]

Good Morning Karl,

don't be distracted by my wrapper script (explanation below). My problem is that with quite the same steps as yours —

• inside T.C. went to S:\Text\BS\
  (S: being a wine drive for the Linux path /S:/, that being a mounted network samba share)

• searched for stemk (alt-f7)

• applied the search results (alt-W)

• double-clicked a random filename at S:\Text\BS\2012\Stemke_BS09.odt :
  Libre Office Writer opens and raises that it cannot find \S:\Text\BS\Stemke_BS09.odt — the subfolder 2012 misses in the path!
  (*.odt having a TC internal association edited by me: /usr/local/bin/runlinuxapp "libreoffice" "%1"

• Again double-clicked the same file : Libre Office Writer raises that it cannot find \S:\TechDok\Alt\A452\Stemke_BS09.odt — this now being the path of the other tab in the background! If this file window has only one tab open, the path of a tab in the other file window will appear...

I can't imagine that my wrapper script could guess paths from other tabs, this must come from TC.

I'm using TC 8.01 (just updated from 7.56a), wine-1.5.5 (built from sources), the current Linux Mint Debian Edition UP4 (that is LMDE, not Ubuntu-based Mint 14!), most applications like LibreOfice native Linux.
My wrapper script runlinuxapp is:

Code: Select all

#!/bin/bash
"$1" "`echo "$2" | sed -f /usr/local/bin/sedcmd_wp2f`"

where sedcmd_wp2f is :

Code: Select all

s/[A-Z]:\\.*\\//

The somewhat convoluted reason for that is as follows: I'm here in a mixed environment. My Linux machine connects to a common Linux Samba flie server. Other colleagues use Win7 machines; they have that server mounted as R: , S: , T: network shares. Many documents on that server (LibreOffice and others) contain absolute links in the fashion file:///S:/somepath/somedoc . So I have to supply LibreOffice exactly this Windows path when opening these documents in order to get it to insert such links so that they work for my colleagues, too...

My solution now is to mount that network share in my Linux machine in /S:/ and all would be well... but then winepath returns an ugly path like /home/username/.wine/dosdevices/s:/Text/BS/2012/Stemke_BS09.odt which would work here for opening the document but cripple the hyperlinks for my colleagues. So I had to devise a script to get my desired paths and all was well while. It did work fine with TC 7.56a and it does now in TC 8.01 with ordinary tabs, but not any more with search results.

(This took me some time to notice, solve and then repair the damaged links... The sed command here is in a separate file — remains from experiments and because of issues with quoting.
I like to retain the long-familiar drives in TC, not least because its loved alt-F10 fast cd.
It would be time now to switch in the Windows machines from old-fashioned network drives to UNC paths, I would think. But LibreOffice, of all things, had severe issues with UNCs when I last looked. And there are thousands of existing links...)

Best regards, Hans

[karlchen]

Hello, Hans.

First thing:
I guess you are in a plight.

The Linux LibreOffice edition is unable to handle Windows style pathnames. So you have to use something like "winepath" to convert the Windows style pathnames returned by T.C. into Linux style pathnames for LibreOffice.

But you must not not do so in order not to break the interal hyperlinks.

Second thing:

Have you bothered to test the results which your script including the sed-script will have when invoked from the commandline?
Does it really do what you expect it to do?

From what I have seen so far, it will always strip the complete pathname from argument $2 thus leaving the pure filename only.

As a result you will launch LibreOffice from an undefined current working directory. Hence LibreOffice should be given the fully qualified path to the document file. But it gets only the pure filename.
It seems that prefixing the current T.C. working folder - in Linux notation - is the side effect / result of this approach.

At this moment, I have got no clue how it might be possible to make the Linux pathnames and the Windows pathnames look absolutely identical in order not to break the internal hyperlinks inside the document.
(I doubt you can, because Windows style pathnames and Linux style pathnames are simply too different. There are no drive letters on Linux, only mount points.)

Kind regards,
Karl

[Hansl]

Hello Karl,

oh what a mess! Due partly to the Linux/Windows mixing, to misunderstandings and not least to my own personal memory leaks...

But you put your finger to the weak spot and so set me right, therefore THANK YOU! The problem was that I used the wrong sed script which (as you correctly deducted) just strips a full windows path to the bare file name. Whereas I already had another script ready (but forgotten it) to convert a windows style full path to a Linux style full path, as follows:

/usr/local/bin/runlinuxapp :

Code: Select all

#!/bin/bash
"$1" "`echo "$2" | sed -f /usr/local/bin/sedcmd_wp2up`"

where /usr/local/bin/sedcmd_wp2up :

Code: Select all

s%\\%\/%g
s%^%/%

This DOES work, and has nothing to do with TC at all, so I'm changing the thread title to [SOLVED] and ask to move it from TC8.0x bug reports (English) to Total Commander (English).

The other script with the bare file name really did work before with TC 7.56, but only by luck with a fitting current working directory, I don't know where that came from. Now, with TC 8.01, the CWD does not seem to fit any more with search results, but that I cannot blame at TC, I just have to provide/convert a proper path.

Now to explain again the office hyperlinks and why they really DO work this way: Of course I can't feed Linux OpenOffice/LibreOffice windows style paths with backslashes, and vice versa. But luckily OO/LO internally stores links always in Unix-Style URIs.

If, in Windows, I mount a network drive as S: and place with Windows OO/LO an absolute hyperlink in a document pointing to S:\somepath\somedoc.pdf , this link will be converted and stored by OO/LO as file:///S:/somepath/somedoc.pdf .

If then, in Linux, I mount the same network drive in /S:/ and place with Linux OO/LO an absolute hyperlink in a document pointing to /S:/somepath/somedoc.pdf , this link will be converted and stored by OO/LO also as file:///S:/somepath/somedoc.pdf — exactly the same URI!

So I CAN edit and use the document with hyperlinks on both Windows and Linux machines with native OO/LO, given that I mount that network share in Linux as /S:/ and point my Wine drive S: to it! The colon ":" is allowed in Linux paths, but is a bit awkward because sometimes it needs quoting; a few Linux programs have difficulties with that. Therefore I also have symlinks /S/ and /home/username/S/ pointing to /S:/ .

The problem with TC (or, with any Windows programs running in Wine) is now, how do I manage to feed OO/LO or any other native Linux app this path in Linux style. Winepath does the conversion backslash to slashes, yes, but prefixes the path with its own mount point thus crippling my links. (Strictly speaking, the path to the document being edited doesn't matter at all, the path to the linked documents matters. But in placing such a link one usually navigates only relative inside OO/LO and overlooks very easily to navigate from something like /home/username/.wine/dosdevices/s:/somepath/somedoc.pdf (note the lowercase s: !) to /S:/somepath/somedoc.pdf . Using relative paths would solve this, but these break when moving the source document.) The solution to this is my above script, converting TC's output S:\somepath\somedoc.pdf to /S:/somepath/somedoc.pdf .

Thank you again, Hans

[Hacker]

[mod]Moved to the English forum.

Hacker (Moderator)[/mod]