[PATCH] Fix find_in_path not including some file extension logic under win32

Alexis S. L. Carvalho alexis at cecm.usp.br
Sat Apr 28 21:33:28 UTC 2007


Thus spake Patrick Mezard:
> # HG changeset patch
> # User Patrick Mezard <pmezard at gmail.com>
> # Date 1177753411 -7200
> # Node ID b5c24ded6e50af68e0800abbe6c09d3b06e91868
> # Parent  e33ad7cea15fd01ad055be44ab801237fb843399
> Fix find_in_path not including some file extension logic under win32.
> 
> Windows shell resolves utility path by combining PATH, the utility name and a set of file extensions from PATHEXT.
> 
> diff -r e33ad7cea15f -r b5c24ded6e50 mercurial/util_win32.py
> --- a/mercurial/util_win32.py	Wed Apr 25 13:14:01 2007 -0700
> +++ b/mercurial/util_win32.py	Sat Apr 28 11:43:31 2007 +0200
> @@ -297,5 +297,30 @@ class posixfile_nt(object):
>              win32file.SetEndOfFile(self.handle)
>          except pywintypes.error, err:
>              raise WinIOError(err)
> +            
> +def find_in_path(name, path, default=None):
> +    '''find name in search path. path can be string (will be split
> +    with os.pathsep), or iterable thing that returns strings.  if name
> +    found, return path to name. else return default. name is looked up
> +    using cmd.exe rules, using PATHEXT.'''
> +    if isinstance(path, str):
> +        path = path.split(os.pathsep)
> +        
> +    pathext = os.environ.get('PATHEXT', '.COM;.EXE;.BAT;.CMD')
> +    pathext = pathext.lower().split(os.pathsep)
> +    isexec = os.path.splitext(name)[1].lower() in pathext
> +    
> +    for p in path:
> +        p_name = os.path.join(p, name)
> +        
> +        if isexec and os.path.exists(p_name):
> +            return p_name
> +        
> +        for ext in pathext:
> +            p_name_ext = p_name + ext
> +            if os.path.exists(p_name_ext):
> +                return p_name_ext
> +            
> +    return default

This should probably be in util.py instead of util_win32.py.

AIUI the functions/classes in util_win32.py depend on something from
win32file/win32com/etc., which may not always be available, while the
functions in the "if os.name == 'nt':" conditional in util.py can be
implemented with standard python features.

It'd be nice to keep following that, even though I really don't know how
well hg works without these extra modules.

BTW - are these win32file/win32com/etc. modules usually available on
Windows, or are they present only in very hacked instalations?

Alexis



More information about the Mercurial-devel mailing list