Back in
15430be5a1 ("Look for gitk in $PATH, not $LIBEXEC/git-core")
git-gui learned to use [_which gitk] to locate where gitk's script
is as Git 1.6 will install gitk to $prefix/bin (in $PATH) and all
of the other tools are in $gitexecdir.
This failed on Windows because _which adds the ".exe" suffix as it
searches for the program on $PATH, under the assumption that we can
only execute something from Tcl if it is a proper Windows executable.
When scanning for gitk on Windows we need to omit the ".exe" suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
+proc _which {what args} {
global env _search_exe _search_path
if {$_search_path eq {}} {
global env _search_exe _search_path
if {$_search_path eq {}} {
+ if {[is_Windows] && [lsearch -exact $args -script] >= 0} {
+ set suffix {}
+ } else {
+ set suffix $_search_exe
+ }
+
foreach p $_search_path {
foreach p $_search_path {
- set p [file join $p $what$_search_exe]
+ set p [file join $p $what$suffix]
if {[file exists $p]} {
return [file normalize $p]
}
if {[file exists $p]} {
return [file normalize $p]
}
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
+ set exe [_which gitk -script]
set cmd [list [info nameofexecutable] $exe]
if {$exe eq {}} {
error_popup [mc "Couldn't find gitk in PATH"]
set cmd [list [info nameofexecutable] $exe]
if {$exe eq {}} {
error_popup [mc "Couldn't find gitk in PATH"]