Discussion:
"fossil gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?
(too old to reply)
Gilles
2018-08-04 11:16:29 UTC
Permalink
Hello,

I have a couple of questions:

1. Although fossil.exe is configured with…

fossil settings > gdiff-command    (global) "C:\Program
Files\WinMerge\WinMergeU.exe"

… nothing happens when I run "fossil gdiff myfile.txt".

Any idea what it could be? FWIW, I'm running Windows7.

2. Is there a way to make fossil.exe autocomplete commands, eg.

fo + TAB : fossil.exe
fossil gd + TAB : fossil gdiff
fossil gdiff my + TAB :fossil gdiff myfile.txt

Or is there an alternative to the native CMD.EXE that would do the trick?

Thank you.
Warren Young
2018-08-04 12:07:39 UTC
Permalink
fossil settings > gdiff-command (global) "C:\Program Files\WinMerge\WinMergeU.exe”
Double check that the executable is in fact there, not somewhere else, like c:\Program Files (x86).

If that doesn’t work, try “dir /x c:\” and putting in the short version of the path to avoid the embedded space. If I had to guess, it’s:

c:\PROGRA~1\WinMerge\WinMergeU.exe

But check. It could be ~2 or other things.

And if that still doesn’t work, try using forward slashes. It’s possible this is running through sprintf() or similar internally to Fossil, so those backslashes are causing confusion.
2. Is there a way to make fossil.exe autocomplete commands, eg.
fo + TAB : fossil.exe
fossil gd + TAB : fossil gdiff
fossil gdiff my + TAB :fossil gdiff myfile.txt
That’s not something fossil.exe can do, even in principle. It’s a function of your shell, not of the command the shell is about to run. fossil.exe hasn’t even run yet at the point where you’re wanting command argument completion.

There are several advanced shells for Windows (e.g Cmder), but I don’t pay much attention to that space, so I can’t actually give any recommendations.

If you are willing to use a POSIX type shell on Windows, several of the advanced shells can be configured to do this. E.g. with Bash:

https://hackaday.com/2018/01/19/linux-fu-custom-bash-command-completion/

Zsh can also certainly do it, and probably Fish as well.

Such shells are vastly superior to cmd.exe anyway.
Warren Young
2018-08-04 12:10:01 UTC
Permalink
Post by Gilles
fo + TAB : fossil.exe
fossil gd + TAB : fossil gdiff
fossil gdiff my + TAB :fossil gdiff myfile.txt
Also, realize that Fossil will accept any unique prefix for sub-commands. So, “fossil gd” is already a valid command: you don’t need the TAB.
Gilles
2018-08-04 12:49:45 UTC
Permalink
Post by Warren Young
Also, realize that Fossil will accept any unique prefix for
sub-commands. So, “fossil gd” is already a valid command: you don’t
need the TAB.
Thanks. Good enough.
Stephan Beal
2018-08-04 12:22:55 UTC
Permalink
Post by Warren Young
https://hackaday.com/2018/01/19/linux-fu-custom-bash-command-completion/
There's one big caveat to doing so: trying to use features not explicitly
allowed for by the programmable completion will break completion in
annoying ways.

e.g. when using my system-provided completion, which includes support for
the sqlite3 shell, i cannot tab-complete sqlite3 database filenames unless
they have the exact set of extensions defined by the completion rules. e.g.
tying:

sqlite3 myF<TAB>

will not complete myFossilRepo.fsl

because the programmable completion has a hard-coded list of file
extensions it will expand.

Likewise, the completion for the zip/unzip commands cannot tab-complete CBZ
files, which are simply ZIP files with a different extension. (i use a lot
of CBZ files, including manipulating them from the shell, so this
limitation is severely annoying.)

Thus... i disable all programmable completion on my systems. It just gets
in the way, which i cannot abide.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Gilles
2018-08-04 12:49:07 UTC
Permalink
Post by Warren Young
Double check that the executable is in fact there, not somewhere else, like c:\Program Files (x86).
c:\PROGRA~1\WinMerge\WinMergeU.exe
But check. It could be ~2 or other things.
And if that still doesn’t work, try using forward slashes. It’s possible this is running through sprintf() or similar internally to Fossil, so those backslashes are causing confusion.
Thanks much for the tip.

The program is, c:\Program Files\WinMerge\WinMergeU.exe", ie.
"C:\PROGRA~1\WinMerge\WINMER~1.EXE"

At the root of C: , where fossil.exe lives:

c:\> fossil settings gdiff-command "C:\PROGRA~1\WinMerge\WINMER~1.EXE"
c:\> fossil settings
Post by Warren Young
gdiff-command        (global) C:\PROGRA~1\WinMerge\WINMER~1.EXE
d:\temp\> fossil gdiff myfile.txt

Nothing.

c:\> fossil settings gdiff-command "C:/PROGRA~1/WinMerge/WINMER~1.EXE"
c:\> fossil settings
Post by Warren Young
gdiff-command        (global) C:/PROGRA~1/WinMerge/WINMER~1.EXE
d:\temp\> fossil gdiff myfile.txt

Nothing.

I also ran the command in the work directory, still no go. Incidently, I
notice that settings can be changed at the local level:
d:\temp\> fossil settings gdiff-command "C:/PROGRA~1/WinMerge/WINMER~1.EXE"
d:\temp\> fossil settings
Post by Warren Young
gdiff-command        (local) C:/PROGRA~1/WinMerge/WINMER~1.EXE
d:\temp\> fossil gdiff myfile.txt

Still nothing :-/
Warren Young
2018-08-04 13:17:51 UTC
Permalink
Post by Gilles
d:\temp\> fossil gdiff myfile.txt
Nothing.
Is d:\temp a checkout directory? What does “fossil stat” give in that directory?
Gilles
2018-08-04 13:30:02 UTC
Permalink
Post by Warren Young
Post by Gilles
d:\temp\> fossil gdiff myfile.txt
Nothing.
Is d:\temp a checkout directory? What does “fossil stat” give in that directory?
Yes. I used "d:\temp" to investigate this issue on a dummy repo.

d:\Temp>fossil settings
gdiff-command        (global) C:/PROGRA~1/WinMerge/WINMER~1.EXE

d:\Temp>fossil stat
repository:   d:/Temp/my.repo
local-root:   d:/Temp/
config-db:    C:/Users/fred/AppData/Local/_fossil
checkout:     6517de2577504d8ca1b5a962db04ced55bfcaa72 2018-08-04
13:28:00 UTC
parent:       e711051a5a175a1e7b30a5b477639d5947d86af6 2018-08-04
13:27:00 UTC
tags:         trunk
comment:      Blah (user: fred)
Martin Gagnon
2018-08-04 13:36:37 UTC
Permalink
Post by Gilles
Hello,
1. Although fossil.exe is configured with…
fossil settings > gdiff-command    (global) "C:\Program
Files\WinMerge\WinMergeU.exe"
… nothing happens when I run "fossil gdiff myfile.txt".
You can try to add "C:\Program Files\WinMerge" to your PATH environment
variable.

Then start a cmd window and try if it works by just typing winmergeu.

If it's works, this should works

fossil set gdiff-command winmergeu
fossil gdiff myfile.txt
--
Martin G.
Gilles
2018-08-04 13:51:53 UTC
Permalink
Post by Martin Gagnon
You can try to add "C:\Program Files\WinMerge" to your PATH
environment variable.
Then start a cmd window and try if it works by just typing winmergeu.
If it's works, this should works
fossil set gdiff-command winmergeu
fossil gdiff myfile.txt
Thanks for the tip.

"C:\Program Files\WinMerge" was already in my system PATH:

d:\Temp>echo %PATH%
C:\Program Files\Common Files\Oracle\Java\javapath;… C:\Program
Files\WinMerge;C:\Program Files\UltraEdit\

And "d:\Temp>winmergeu" does launch Winmerge as expected.

Next, I added the shorter version:

d:\Temp>setx /M PATH "%PATH%;c:\PROGRA~1\WinMerge

d:\Temp>echo %PATH%
…C:\Program Files\WinMerge;C:\Program Files\UltraEdit\;C:\Program
Files\Mercurial;"c:\PROGRA~1\WinMerge

d:\Temp>fossil set gdiff-command WinMergeU.exe

d:\Temp>fossil settings

gdiff-command        (local)  WinMergeU.exe

d:\Temp>fossil gdiff test.html

Nothing.
Gilles
2018-08-04 14:25:28 UTC
Permalink
Post by Gilles
d:\Temp>fossil gdiff test.html
Nothing.
I don't know if it means anything, but incidently, "fossil diff" doesn't
return anything either:

d:\Temp>fossil diff test.html

d:\Temp>fossil finfo test.html
History of test.html
2018-08-04 [6517de2577] Blah (user: fred, artifact: [e123cf7827],
branch: trunk)
2018-08-04 [e711051a5a] Original files (user: fred, artifact:
[7d257c6ae4], branch: trunk)
Martin Gagnon
2018-08-04 14:36:50 UTC
Permalink
Post by Gilles
Post by Gilles
d:\Temp>fossil gdiff test.html
Nothing.
I don't know if it means anything, but incidently, "fossil diff" doesn't
d:\Temp>fossil diff test.html
d:\Temp>fossil finfo test.html
History of test.html
trunk)
2018-08-04 [e711051a5a] Original files (user: fred, artifact: [7d257c6ae4],
branch: trunk)
If you don't have any local changes, it's normal that it shows nothing.
If "fossil changes" return nothing, it will be the same for "diff" or
"gdiff".

Fossil will not try to run the gdiff-command if there's no change.

Try again after modifying the file.
--
Martin G.
Stephan Beal
2018-08-04 14:43:37 UTC
Permalink
Post by Gilles
Post by Gilles
d:\Temp>fossil gdiff test.html
Nothing.
I don't know if it means anything, but incidently, "fossil diff" doesn't
d:\Temp>fossil diff test.html
d:\Temp>fossil finfo test.html
That means there are no diffs to show. Try:

fossil gdiff --from prev test.html
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Gilles
2018-08-04 15:10:54 UTC
Permalink
Post by Stephan Beal
fossil gdiff --from prev test.html
That was it.

Grrr, I should have thought about it :-/

I don't know how common this mistake is, but if it, it might be a good
thing if Fossil said something like "No change."

Thanks much everyone.
Stephan Beal
2018-08-04 15:17:21 UTC
Permalink
If it was that common we would have realized the problem sooner ;).

The problem with generating output for "no changes" is that we potentially
break any automation which relies on an empty diff to mean "no changes".
(That lnly applies to "diff", not gdiff.) That could, i guess, be "fixed"
by adding a --quiet option, suppressing any non-diff output. Something to
consider, in any case.

----- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.
Post by Stephan Beal
fossil gdiff --from prev test.html
That was it.
Grrr, I should have thought about it :-/
I don't know how common this mistake is, but if it, it might be a good
thing if Fossil said something like "No change."
Thanks much everyone.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Martin Gagnon
2018-08-04 15:30:45 UTC
Permalink
Post by Stephan Beal
If it was that common we would have realized the problem sooner ;).
The problem with generating output for "no changes" is that we potentially
break any automation which relies on an empty diff to mean "no changes".
That is what stderr is for.

—
Martin G.
Stephan Beal
2018-08-04 16:19:41 UTC
Permalink
Post by Martin Gagnon
Post by Stephan Beal
If it was that common we would have realized the problem sooner ;).
The problem with generating output for "no changes" is that we
potentially break any automation which relies on an empty diff to mean "no
changes".
That is what stderr is for.
For this particular case i disagree. It's not an error condition and it
seems (via a cursory glance) that fossil has so far used stderr only for
logging and error cases.

IMHO no output is the pedantically correct thing to do, but... i've got a
long history of being in the minority when it comes to such opinions ;).

Outputting "no differences" to stdout would (IMO) be fine if automation had
the option to use --quiet to surprise that.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Gilles
2018-08-04 18:13:50 UTC
Permalink
Post by Stephan Beal
Outputting "no differences" to stdout would (IMO) be fine if
automation had the option to use --quiet to surprise that.
Considering no one thought about this before I mentioned that "fossil
diff" also returned nothing
 it looks like it might not be that bad an
idea to tell the user that an empty result simply means that no change
was detected between the workspace file and the last revision in the
repo. No reason to worry about the settings, short/long filenames,
forward and backward slashes, etc.

But then, "fossil changes" returns nothing either, and it's coherent
with the Unix philosophy.

Bah, it's a hot Saturday in the Northern hemisphere, we didn't spend
that much time on the issue, and today's exchange should hopefully be
reachable through Google for other users' benefit. Science!
Warren Young
2018-08-05 03:47:22 UTC
Permalink
But then, "fossil changes" returns nothing either, and it's coherent with the Unix philosophy.
Precisely. You’re applying Windows mores to a tool that comes out of the Unix tradition. As long as you do that, you’ll have expectation mismatches.

It is not correct to say that Fossil had no output in this case. Its output was the exit status code, which was zero, meaning there was no failure. Since there is also no standard output, that means there are no differences. You can check for this combination in a POSIX shell:

diffs=$(fossil diff)
if [ $? = 0 ]
then
echo No difference found.
elif [ -n "$diffs" ]
then
echo Difference found.
else
echo Program exit failure, code $?.
fi

If you know the history of mathematics, you know what kind of contortions they had to go through before they invented the concept of zero. This is analogous.

If we relied instead on text output to signal “No changes,” it would break if Fossil was ever localized:

if fossil diff | grep -q 'No changes'
then
… do something for the change case …
else
… do something else for the no-change case …
fi

You’d erroneously end up in the no-change case because the output would be “Aucun changement” on an OS configured for a French locale, if Fossil ever gets localized for French.

If you doubt the usefulness of such a script, consider a “make release” script, which first checks whether there are any changes to unexpected files before proceeding. In one of my projects, the only expected changes upon creating a release are a new section in the ChangeLog.md file and a single-line change to the VERSION variable within the Makefile; anything else means you’ve probably forgotten to check something in separately first. The above shell script logic allows us to test for things like this and stop the process if pilot error is suspected.

If I’ve yet to convince you that this design philosophy is sensible, consider that it’s one of several reasons why Unix type systems are far more easily scripted than Windows systems, which in turn is one of the largest reasons they’ve taken over the cloud space. You can’t deploy 1000 Windows instances at peak load every day and tear them back down as the load decreases when you cannot easily and reliably script the process.

I speak from experience. One of my current Windows software projects drives a program that is externally scriptable only by programming to its .NET API. If this program were available on Linux and followed its conventions, I’d expect to be able to replace the .NET code and its attendant MSI deployment mess with a far simpler shell script. I’ve probably spent more time getting the MSI creator working than I’d have spent writing that shell script.

Incidentally, I asked you for “fossil stat” output in part because I anticipated this possibility: it didn’t give you an “EDITED” line for these files you’ve been checking for changes. You will come to notice absences like that. It will be a clue that you either have no changes or that you forgot to add a new file to the repository, so Fossil is still ignoring it.
Gilles
2018-08-05 10:19:31 UTC
Permalink
It is not correct to say that Fossil had no output in this case. Its
output was the exit status code, which was zero, meaning there was no
failure.
I understand that it's too late now that some scripts would break if
diff/gdiff returned something like "No change" instead of remaining
mute, but I think it would have been helpful to output some information
so that the user know it's not some issue with an external differ like
we all thought.

Back to real life.

Loading...