zhangkun2007 / meld-installer

Automatically exported from code.google.com/p/meld-installer
0 stars 0 forks source link

meld.exe does not find relative paths #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Add ...\meld\bin to PATH
2. meld.exe relative\path\tofile1.txt relative\path\tofile2.txt

What is the expected output?

Meld should look for the files relative to the current directory.

What do you see instead?

Meld complains that it cannot find 
...\meld\install-path\meld\relative\path\tofile1.txt

Example:

meld.exe th\ws\t2d\r1.md th\ws\t2d\r2.md

Command above gives the error in attached screenshot.

What version of the product are you using? On what operating system?

1.6.1.1 and 1.7.0.0 on Windows 7 x64.

Original issue reported on code.google.com by tom...@gmail.com on 22 Feb 2013 at 5:29

Attachments:

GoogleCodeExporter commented 9 years ago
The problem is that meld's current working dir is not set to the dir from which 
it was invoked, but is set instead to the dir where meld is located. So it ends 
up looking for relative paths starting at the meld dir, which is certainly 
wrong.

Same versions, same OS.

The attached image shows this problem more clearly. Note that meld was invoked 
from the command line above, which is in the dir 
C:\Users\jppm\projects\decathlon\Game to a file which is on that dir. Meld ends 
up looking for the file in the meld dir, C:\Program Files (x86)\Meld\meld .

Original comment by joao.mag...@biodroid-entertainment.com on 2 Apr 2013 at 10:35

Attachments:

GoogleCodeExporter commented 9 years ago
I don't maintain Meld itself, only an installer for Meld.  Please ask about 
issues related to Meld itself on their mailing list 
(https://mail.gnome.org/mailman/listinfo/meld-list) and file bugs with their 
Bugzilla (https://bugzilla.gnome.org/enter_bug.cgi?product=meld).

Original comment by keeganw...@gmail.com on 2 Apr 2013 at 3:52

GoogleCodeExporter commented 9 years ago
Respectfully, this is not a Meld problem, as shown by the attached patch, which 
fixes the issue. 

It's a problem in the ahk script. That script runs with %A_ScriptDir% as its 
working dir. It should run in the original working dir, and call python with 
the environment set. I am not confortable with AHK, so what I did instead was 
to save the initial workdir in cwd and prepend it whenever a given path is 
relative. 

But the ideal way to do it is to never make the call to SetWorkingDir, and 
prepare the python environment instead.

Original comment by joao.mag...@biodroid-entertainment.com on 2 Apr 2013 at 6:00

Attachments:

GoogleCodeExporter commented 9 years ago
For those wanting a quick solution:

(Assuming your Meld installation dir is C:\Program Files (x86)\Meld)

1. Save the attached ahk script
2. Compile the ahk script with Ahk2Exe:
  2.1 Source: select the ahk script
  2.2 Destination: select a folder with write permissions and name your file meld.exe
  2.3 Custom Icon: select C:\Program Files (x86)\Meld\meld\meld.ico
3. Copy the meld.exe into C:\Program Files (x86)\Meld\meld\meld.exe, 
overwriting (you'll probably need to provide admin permissions).

Original comment by joao.mag...@biodroid-entertainment.com on 2 Apr 2013 at 6:20

Attachments:

GoogleCodeExporter commented 9 years ago
OK - this new version of the ahk is less hackier. It turns out that, unlike 
what I wrote above, there is no need to set the Python environment. The trouble 
I was having initially was (I think) related to the spaces in the Program Files 
(x86) folder.

This new ahk script version completely solves this. There's no call to 
SetWorkingDir, so meld now works as expected - with its workdir set to the 
caller's workdir. This means meld can be called from the command line with any 
sort of path (unlike my previous meld.ahk version).

Look - I am very grateful for your installer - it finally gave meld to Windows 
users. But please understand that *this is a problem with the installer* (ie, 
meld.ahk and consequently meld.exe) and not with Meld itself, which is fine. 
Your intermediate meld.exe is making meld itself not usable when relative paths 
are given (which is almost all the time in the command line).

So please remove that egregious call to SetWorkingDir, and consider using this 
meld.ahk version instead.

All the best - and thanks again,
João

Original comment by joao.mag...@biodroid-entertainment.com on 2 Apr 2013 at 11:32

Attachments:

GoogleCodeExporter commented 9 years ago
João's script works perfectly for me when compiled down to an exe using 
AHK2EXE. It's a shame that it is not in the official installer, as it can be 
tedious to open two adjacent directories for comparison using the GUI.

Original comment by star99...@gmail.com on 12 Jun 2013 at 3:37

GoogleCodeExporter commented 9 years ago
João script worked for me as well, I can finally use git difftool with meld.

@Keegan Witt: please reconsider the status of this bug and include the changes 
contributed by João. Thanks!

Original comment by joan.cha...@gmail.com on 6 Aug 2013 at 9:01

GoogleCodeExporter commented 9 years ago
With reading joao's post I believe it's a bug of the installer. It work's fine 
with supplied meld.ahk.

I believe it's worth fixing it.

Original comment by kong...@gmail.com on 22 Aug 2013 at 9:04

GoogleCodeExporter commented 9 years ago

Original comment by keeganw...@gmail.com on 6 Sep 2013 at 5:24

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by keeganw...@gmail.com on 7 Sep 2013 at 3:07

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Sorry, I think I missed that you guys had commented.  Thanks for your feedback. 
 I think this version should do what you need: 
https://code.google.com/p/meld-installer/source/browse/meld.ahk?r=0b2e0e22ee8fe1
0c70030dcf7ded58c85714a082.  Give it a look and let me know.

Original comment by keeganw...@gmail.com on 8 Sep 2013 at 12:14

GoogleCodeExporter commented 9 years ago

Original comment by keeganw...@gmail.com on 10 Sep 2013 at 9:56

GoogleCodeExporter commented 9 years ago
Thanks a lot for this fix!!!

Now I can use "git mergetool" with no problems.

Here is my git config:

[merge]
        tool = meld
[mergetool "meld"]
        prompt = false
        keepBackup = false
        keepTemporaries = false
        path = c:/Meld/meld/meld.exe

Original comment by cch...@gmail.com on 11 Sep 2013 at 3:13

GoogleCodeExporter commented 9 years ago
My pleasure.  Glad to hear it's working for you, and thank you for your 
patience.  I've modified the issue tracker here to default to me as the owner, 
that should prevent something like this from being missed in the future.

Original comment by keeganw...@gmail.com on 12 Sep 2013 at 2:48

GoogleCodeExporter commented 9 years ago

Original comment by keeganw...@gmail.com on 15 Sep 2013 at 3:05

GoogleCodeExporter commented 9 years ago

Original comment by keeganw...@gmail.com on 15 Sep 2013 at 3:06

GoogleCodeExporter commented 9 years ago
I installed Meld with the Windows installer and I can run it manually and via 
command line ok.  However I can't get SourceTree it kick off the GUI interface? 
 It creates the  BACKUP, BASE, LOCAL, REMOTE files but just won't fire up the 
GUI.  Any ideas what is wrong with SourceTree doing this for my git project?

My .gitconfig says:

[merge]
        tool = meld
[mergetool "meld"]
        prompt = false
        keepBackup = false
        keepTemporaries = false
        path = 'c:/Program Files/Meld/meld/meld.exe'

Original comment by delettec...@gmail.com on 15 Oct 2013 at 7:57

GoogleCodeExporter commented 9 years ago
I'm not sure if this would correct the issue or not (I don't use Meld for 
this), but have you tried using meldc.exe instead of meld.exe?  This was added 
in the last release.

Original comment by keeganw...@gmail.com on 15 Oct 2013 at 11:15

GoogleCodeExporter commented 9 years ago
Try adding meld.exe to your path. I don't know SourceTree, but if SourceTree 
itself calls Meld (instead of letting git do it) then meld.exe needs to be in 
your path.

Original comment by joao.mag...@biodroid-entertainment.com on 15 Oct 2013 at 11:33

GoogleCodeExporter commented 9 years ago
Hi there,
If you are using a Windows of non-English version, you can try change system 
format to English:
    Control Panel -> Region and Language -> Formats.

Working within windows is totally a nightmare.

Original comment by kong...@gmail.com on 16 Oct 2013 at 4:01

GoogleCodeExporter commented 9 years ago
Meldc.exe didn't work.  Sourcetree should be using native git commands.

I can see the sh.exe open up in my task manager but it's doing nothing.

Original comment by delettec...@gmail.com on 21 Oct 2013 at 6:22

GoogleCodeExporter commented 9 years ago
Did you mean cmd.exe instead of sh.exe?  I'm unsure what to recommend.  Setting 
my .gitconfig as you have works with SourceTree.  Are you running a 64bit 
version of Windows?  If so, make sure you're pointing at %PROGRAMFILES(x86)%.

Original comment by keeganw...@gmail.com on 21 Oct 2013 at 11:35

GoogleCodeExporter commented 9 years ago
If you did mean sh.exe, I wonder if differences in path separators could cause 
that.  Also when I was testing, I was using mysysgit, and not Git from Cygwin 
or something else.  I'm trying to think what else could be different in our 
setups.

Original comment by keeganw...@gmail.com on 22 Oct 2013 at 4:09