Linux visual diff/merge utilities

[guest]

Hello,

We're evaluating SOS at our company (for several different reasons).
One reason is to be able to run linux clients.

I'm trying to run an external program for comparing files (and ultimately
merging).

I've tried tkdiff (i.e. sh .../tkdiff "%s" %"s") and this works sometimes
but then it will also fail with: "error waiting for process to exit: child process lost .... I've also tried xxdiff and this always fails. Both of these
run ok if they're invoked seperately on the tempory files sos creates.

So, my question is: why do this diff utilities fail ? And can you recommed a diff utility - for Linux to use instead ?

If it matters I've used versions 3.5 and 4.0 of the sos clients.

Thanks for the help.

[Guest]

MetroWerks CodeWarrior has an absolutely fantastic diff system; unfortunately they dropped support for their linux version. We've been holding out on RedHat 6.2 precisely because we didn't want to lose CW.


- Oliver

[Guest]

Using RedHat 7.3 - 9.0, gtkdiff worked as an external diff utility. I have just switched to SUSE 9.0, gtkdiff won't build. But tkdiff works OK, if you open up the file (it is text) and comment out the 2 "diff failed" sections. tkdiff %s %s, 'n' for next, 'p' for previous.

[guest]

I have exactly the same problem as described.
Does anyone as found out a solution by now?

(I'm using xxdiff, which does not work when linked to sos'client)

[andy]

It would appear that using a diff program that spawns another child process doesn't work as the SOS client is ignoring SIGCHLD and SIGPIPE signals. I don't remember exactly why that was done, but if you compile your own client, you can remove the first 2 signal() calls in main() in VermMain.cpp and your external apps will then work. I'm not sure exactly what other consequences this might have on the program - use at your won risk :-)

[rfauth]

I've had success using meld to diff and merge projects

http://meld.sourceforge.net/

use external programs line:meld "%s" "%s"

[tfield1974]

Hi guys -

How exactly do you configure the external programs to work? I'm trying to do it on a mac running SOS 4.1.1 under X windows, so it shouldn't be too much different for me as it is for you linux-types. If anyone's on BSD it should be the same....

On the other hand, if there's a mac user out there who knows how to point "view" to XCode and "diff" to FileMerge, I'd be very grateful!

Thanks,
Tony

[nemo]

It would appear that using a diff program that spawns another child process doesn't work as the SOS client is ignoring SIGCHLD and SIGPIPE signals. I don't remember exactly why that was done, but if you compile your own client, you can remove the first 2 signal() calls in main() in VermMain.cpp and your external apps will then work. I'm not sure exactly what other consequences this might have on the program - use at your won risk

I'm rather attached to gvim.
Would this happen to be why, you think, gvim -d "%s" "%s" has been failing for me? (The directory /tmp/sosRANDOM is always nonexistant, so left diff is an empty file).

I know gvim invokes diff to do its colourising.

[Guest]

It would appear that using a diff program that spawns another child process doesn't work as the SOS client is ignoring SIGCHLD and SIGPIPE signals. I don't remember exactly why that was done, but if you compile your own client, you can remove the first 2 signal() calls in main() in VermMain.cpp and your external apps will then work. I'm not sure exactly what other consequences this might have on the program - use at your won risk

I'm rather attached to gvim.
Would this happen to be why, you think, gvim -d "%s" "%s" has been failing for me? (The directory /tmp/sosRANDOM is always nonexistant, so left diff is an empty file).

I know gvim invokes diff to do its colourising.

Aaand, to reply to myself. No, the problem is that gvim is detaching from the shell so the system(diff) call returns immediately.
That, I think I can solve in gvim. n/m!

[Guest]

Aaand, to reply to myself. No, the problem is that gvim is detaching from the shell so the system(diff) call returns immediately.
That, I think I can solve in gvim. n/m!

To continue my talking to myself.
In fact, gvim -df and commenting out the signal were needed.
Good times. Definitely will have to look through and see what that actually does, but something to consider when I create an ebuild version.

[lbauer]

I don't have anything to add, just wanted to let you know we're listening.

[nemo]

Well thank you.

One more for the gvim crowd out there.
Put:
au BufRead,BufNewFile *.*_Version_* exe "doau filetypedetect BufRead ".substitute(expand("<amatch>"), "_Version_.*", "", "")

In your .vimrc to get the correct highlighting on the tmp files.
Thanks to p0g on #vim for this one, since my vimscript is rather mediocre.

[nemo]

The gvim -df worked fine using the RPM version.
However, extracting RPM files, symlinking v3 of libgdbm to v2, adding v4.1.2 of libdb in order to get have a binary working in Gentoo is a bit more of a hassle than patching 4.0.0. It'd be thoughtful if an updated tar.gz of the source was added to the ftp site.

[Guest]

KDE's "kompare" is a reasonably good diff too also.

- Oliver

[chrismon]

I've had success using meld to diff and merge projects

http://meld.sourceforge.net/

use external programs line:meld "%s" "%s"

This is a great tool! Although, that cmdline seuqence doesntwork for me. I had to write a shell script wrapper to meld get the arguments to work properly from SOS. When I put the "%s" "%s" in there, it just printed out the %s's with the other args, confusing meld