Tcl Source Code

init.tcl's auto_execok function has for some time since 8.57 looked for executable files with empty extensions first. 
Some tools such as msys2 provide various shims/scripts named like their MS counterparts either with or without a .exe extension.

With c:\windows\system32 earliest in the path - one would expect that typing cmd at a prompt would preferentially find the normal c:\windows\system32\cmd.exe - or use the $env(COMSPEC) value.   For shell builtins as defined in the auto_execok function such as 'echo' - the correct cmd.exe is used (from COMPSPEC).

However - in the presence of some other file named cmd in the path - just typing cmd in the shell loads that other path into the ::auto_execs array.


This can be worked around by typing cmd.exe instead of just cmd, but it is surprising, and I'm wondering if at least for cmd - this could specifically use the COMSPEC value - as this is what is chosen for the builtins, and I can't think of a circumstance where cmd should point to a different location than its builtins.

The potential remains for other programs to be selected in an order based on extension that doesn't follow the order listed in PATH - presumably(?) it is done this way for performance so that the entire set of PATH dirs isn't searched for each extension - but I do also wonder at the reason for 'no extension' being ahead of .exe

Current search order is {foreach extension {foreach path ...}}

Generally on windows one expects the earlier entries in the path to be respected  - but Tcl on windows has operated in this way for some time.


Might it be worthwhile doing a pre-scan for all extensions in the dirname of $::env(COMPSPEC) (usually something like c:\windows\system32), then, noting the position of that folder in the PATH (or giving lowest pref if not present), only replace it in auto_execs if something was found earlier in the PATH?

That proposal gives the folder of COMSPEC a special privilege - which is a bit ugly.

Rather than that, my preference would be to reverse the the loop nesting and search once through the folders but check each of the 5 extensions - as this is the least surprising in terms of how users have their PATH configured - but I don't know why the current ordering was chosen.

Some very rough testing.. I have a bit over 100 folders in my PATH - which I suspect is somewhat higher than most. 

Doing a tcl glob for the 5 extensions (with a specific filename) in one call for a folder with say 50 files - takes less than 1ms   
Doing the same on a large folder such as c:\windows\system32 (contains around 5k files) takes less than 3ms 

both these rough tests were for non-existent names e.g
glob -nocomplain -dir $d -tail flubber flubber.exe flubber.cmd ...

A single glob like this is a bit faster than testing file exists for each one.

With my changes below  - entering a non existent command returns about 4x faster (noticeable in interactive shell) and the selection respects the PATH order. Please review and consider.


    set lookfor [lmap ext $execExtensions {string cat ${name} ${ext}}]
    foreach dir [split $path {;}] {
        # Skip already checked directories
        if {[info exists checked($dir)] || ($dir eq "")} {
            continue
        }
        set checked($dir) {}
        foreach match  [glob -nocomplain -dir $dir -tail {*}$lookfor] {
            set file [file join $dir $match]
            if {[file exists $file] && ![file isdirectory $file]} {
                return [set auto_execs($name) [list $file]]
            }
        }
    }

    if 0 {
        foreach ext $execExtensions {
        unset -nocomplain checked
        foreach dir [split $path {;}] {
            # Skip already checked directories
            if {[info exists checked($dir)] || ($dir eq "")} {
            continue
            }
            set checked($dir) {}
            set file [file join $dir ${name}${ext}]
            if {[file exists $file] && ![file isdirectory $file]} {
            return [set auto_execs($name) [list $file]]
            }
        }
        }
    }