WinMerge doesn't accept trailing "\" in command line paths

Screenshot of the compare target selection dialog

Logged In: YES
user_id=631874

Thanks for reporting. I can reproduce this with current
repository source build.

Logged In: YES
user_id=631874

BTW, you don't need trailing backslash for folder names,
WinMerge detects foldernames correctly without them.

I took a quick look but didn't yet found where this fails.

Logged In: YES
user_id=411238

It is not a bug. :-)

When you used the slash before the quotes you "esc-ed" them,
so Windows figure it should use a quote.

You should write:

"C:\Temp\Test 1\\" "C:\Temp\Test 2\\"

and it will work as expected.

Logged In: YES
user_id=631874

Ah. I was expecting the escaping happens somewhere, but I
didn't expect windows to do it for commandline. So there is
nothing WinMerge can do for this, right?

Logged In: YES
user_id=1223596

Right. My bad for not spotting that.

Silly Windows for using the same character for escaping and
a path delimiter...

Logged In: YES
user_id=411238

> So there is nothing WinMerge can do for this, right?

Maybe we could hijack the CreateProcess function and do
something about it... or in other words, no. :-)

Logged In: YES
user_id=1223596

Actually, it's possible to use GetCommandLine and do the
parameter parsing manually - instead of using argc\argv.

Logged In: YES
user_id=411238

> Actually, it's possible to use GetCommandLine and do the
> parameter parsing manually - instead of using argc\argv.

Maybe, I'm not sure. You might not get the original string
as well.

Logged In: YES
user_id=1223596

> Maybe, I'm not sure. You might not get the original
string as well.

Why? In case you didn't know, Windows doesn't pass the
parameters to the application directly - the C runtime gets
them via GetCommandLine(), then splits it internally,
respecting the escaping "standard" - and only then passes
it to the main function. Consider this simple C program:

#include <stdio.h>
#include <windows.h>

void main(int argc, char** argv)
{
int i;
printf("Commandline is: %s\n", GetCommandLine());
for(i=0;i<argc;i++)
printf("argv[%d]: %s\n", i, argv[i]);
}

Here is an example run/output:

C:\Temp\c\args>args.exe First\Path Second\Path\ "This
is\The Third" "And this is\The fourth\" "This\should be\the
Fifth"

Commandline is: C:\Temp\c\args\args.exe First\Path
Second\Path\ "This is\The Third" "And this is\The
fourth\" "This\should be\the Fifth"

argv[0]: C:\Temp\c\args\args.exe
argv[1]: First\Path
argv[2]: Second\Path\ argv[3]: This is\The Third
argv[4]: And this is\The fourth" This\should
argv[5]: be\the
argv[6]: Fifth

This is exactly what happens with WinMerge. By implementing
a simple command-line parser, it's possible to ignore
escaping (which isn't used anywhere anyway, since the set
of characters allowed in Windows filenames is restricted
enough already) and thus allow trailing backslashes in
folder paths containing spaces.

Logged In: YES
user_id=411238

I was wrong. It happens from time to time. :-(

However I don't think we should give up on the nice work
the C runtime does for us. You might want to use quotes for
a file description and you'll need escaping it.

BTW: The bug that started my way as WinMerge's developer
was an escape bug in check-in comment when using
ClearCase. :-)

Logged In: YES
user_id=631874

I disagree with not trying to fix this bug. Remember lots of
people use WinMerge from other software. If that software
formats the commandline, there is no way user can alter the
format for path. If the software adds trailing backslash
then WinMerge won't work with it.

I'm actually a bit surprised this wasn't reported earlier.
As I'm pretty sure people hit to this bug. But when it
happens from other software, it is hard to see why it failed.

I'm re-opening this bug item.

Now that I think of this.. I think I saw this bug while
working with shellextension. But I didn't track the reason
so I just worked around it (by removing the last backslash).

Ugh.

Logged In: YES
user_id=411238

How do you want this bug fixed?

Logged In: YES
user_id=631874

I'm not sure which way works best, but how about something
like this:
- in initinstance() check paths we got (in buggy cases with
missing ") if they exist
- if paths aren't valid, check possibly missing " at the end
and add it

As far as I understand the core issue in this bug, it it one
special case where we have \ char before ". And we can
detect this case when path begins with " char but there is
no " char in end of path.

Logged In: YES
user_id=631874

Argh, this wasn't so simple I thougth it was: in this buggy
case we actually get only one string containing both paths.
So my suggestion below doesn't work.

Logged In: YES
user_id=411238

The only possible solution that I can think about right now
is if we'll change the command line so the user will prefix
the path (or file) with "-path" (or "-file") switch.

Logged In: YES
user_id=1223596

Hello,

What about my idea below about splitting the command-line
manually?

I've written a small example.
It correctly understands parameters like these:

args.exe First\Path Second\Path\ "This is\The Third" "And
this is\The fourth\" "This\should be\the Fifth"

However, this example doesn't support escaping actual
quotation marks. It's possible to write a function which
simulates Windows' behaviour of splitting command-line
arguments, with the exception of trailing backslashes for
folder paths.

Sample program which parses command-line arguments manually

Logged In: YES
user_id=411238

> However, this example doesn't support escaping actual
> quotation marks.

That's the problem. I think escaping is a must.

Maybe if we will support escaping only in switch
parameters...?

Logged In: YES
user_id=631874

Additional commandline switches would be a one solution, but
won't work for many applications. For example WinCVS gives
just two paths, there is no way to give switches with them
unless you build your own version of WinCVS..

I'm not sure how that escaping works in all cases, but may
we assume we always have full paths escaped? I.e. we have
"C:\p a\t h", but not C:\pa\"t h" ?

Then those quotation marks would be hint how to split
incorrectly handled paths. We need just to find quotation
marks from middle of the path.

Of course we could implement our own routines, but there is
a risk we broke commandline handling in more cases we fix
it.. Not good for next stable release, but may be we can do
that for development trunk and later merge to branch after
bugs are fixed.

Logged In: YES
user_id=631874
Originator: NO

I think I've finally fixed this bug. At least my initial testing looks good.

There is newer bug report about this same bug (didn't at first notice it as duplicate):
#1963523 CmdLine: First path ending with \ in quote marks combines
http://winmerge.org/bug/1963523

I'm closing this bug as duplicate of that another. As I've attached my patch into it.

The latest 2.9.1.2 experimental already has the fix, and next 2.8.2 stable release will have it also.