which.exe v1.12 - Now efficiently detecting doskey macros and PS aliases

Discussion forum for all Windows batch related topics.

Moderator: DosItHelp

Post Reply
Message
Author
jfl
Posts: 100
Joined: 26 Oct 2012 06:40
Location: Saint Hilaire du Touvet, France
Contact:

which.exe v1.12 - Now efficiently detecting doskey macros and PS aliases

#1 Post by jfl » 26 Mar 2019 12:54

Announcing an updated version of my which.exe tool, for searching which programs will run at the command.com, cmd.exe, or PowerShell prompts.
This which.exe program strives to implement the best of both Unix which and Windows where.exe, and a bit more!

which_v1.12.zip
(184.73 KiB) Downloaded 88 times

Note about the new option -i introduced in this version, for listing cmd doskey aliases:
As discussed in this thread, capturing the doskey macros for the current cmd shell is tricky.
Piping the 'doskey.exe /macros' output to 'which.exe -i' will not work. It is necessary to use a doskey macro for which itself:

Code: Select all

doskey /macros which=^(help ^& doskey /macros^) ^| which.exe -i $*
And the best way to define doskey macros in an extensible way is to use the AutoRun.cmd script.
See this post on this forum for explanations on how to use AutoRun.cmd, and how it works.
For PowerShell, the problem is very similar, and it is necessary to define a which function invoking which.exe.
Run 'which -?' to get help on how to configure both shells for this to work.


which.exe features:
  • Allows passing just the base name of a command, and uses the PATHEXT environment variable to infer possible extensions.
    (Like Windows' own where.exe, but unlike all Windows ports of Unix which.)
  • Uses Unicode internally, and outputs file pathnames correctly in any code page. (Provided that the console font has the necessary characters!)
    (Again, Windows ports of Unix which all fail at that if a pathname contains non-ASCII characters.)
  • Knows about command.com, cmd.exe, and PowerShell specific rules. For example, the latter searches for *.ps1 before trying extensions from PATHEXT.
    Also command.com and cmd.exe search in ".", whereas PowerShell does not. (Both where.exe and Windows ports of Unix which fail at that!)
  • By default outputs only the first match. Use option -a to display all matching programs. (Like Unix which)
  • A -i option allows to efficiently detect cmd.exe doskey macros, and PowerShell aliases.
    Run 'which -?' to get help on how to configure both shells for this to work.
    (where.exe has no equivalent; Unix which has this option for Unix shells, but Windows ports don't support that in Windows.)
  • A unique -l option displays the program(s) date/time; Resolves symbolic links; etc.
  • A unique -v option displays verbose comments about why some seemingly obvious programs will NOT run.
    For example in Vista and later, with cmd.exe variable NoDefaultCurrentDirectoryInExePath set, cmd does not search in ".".
  • Last, but not least, a single .exe that runs in all versions of DOS and Windows, from DOS 3 16-bits to Windows 10 64-bits. Including Windows 95 and XP.
    Note that the zip file contains 3 versions: The one at the root, which runs in all MS OSs, as explained above; And two stripped down versions, that run just in DOS, and 64-bits Windows respectively.

To display a help screen with a full list of options, run:

Code: Select all

which -?

The source code is available on GitHub in the SysToolsLib repository: which.c
But note that the which.exe version in the last (as of this writing) SysToolsLib release is an older one.
Use the version in the zip file above to get the latest which.exe features documented here.

If you find any problem with this which.exe, please report it on GitHub in SysToolsLib issues.

Versions history:
  • 1.12 2019-03-01 Added a -i option allows to efficiently detect cmd.exe doskey macros, and PowerShell aliases.
  • 1.11 2019-01-16 Added option -- to stop processing switches. Allows searching for names that begin with a -.
  • 1.10 2018-03-22 Added option -l, and changed -v to display comments about programs excluded.
  • ...
  • 1.0 1987 Initial version for MS-DOS only

aGerman
Expert
Posts: 3639
Joined: 22 Jan 2010 18:01
Location: Germany

Re: which.exe v1.12 - Now efficiently detecting doskey macros and PS aliases

#2 Post by aGerman » 28 Mar 2019 11:58

Jean-François

That's a neat tool, I like it :)
I have a question as to how option -a is intended to work. If I run 'which -a cmd.exe' I was expecting that more than one file was found on my Win10 x64. Also if I run it in the WOW64 subsystem, it reports that cmd.exe was found in System32, which isn't wrong since I know that System32 is the virtualized SysWOW64 folder in this case. Is there a way to see the real path? Same maybe if a path gets redirected via junction?
jfl wrote:
26 Mar 2019 12:54
a single .exe that runs in all versions of DOS and Windows, from DOS 3 16-bits to Windows 10 64-bits. Including Windows 95 and XP.
What kind of black magic did you apply here :shock: Windows Defender didn't like that witchcraft. I had to restore it from quarantine several times :lol:

Steffen

jfl
Posts: 100
Joined: 26 Oct 2012 06:40
Location: Saint Hilaire du Touvet, France
Contact:

Re: which.exe v1.12 - Now efficiently detecting doskey macros and PS aliases

#3 Post by jfl » 02 Apr 2019 09:44

aGerman wrote:
28 Mar 2019 11:58
That's a neat tool, I like it :)
Thanks!
aGerman wrote:
28 Mar 2019 11:58
I have a question as to how option -a is intended to work. If I run 'which -a cmd.exe' I was expecting that more than one file was found on my Win10 x64. Also if I run it in the WOW64 subsystem, it reports that cmd.exe was found in System32, which isn't wrong since I know that System32 is the virtualized SysWOW64 folder in this case. Is there a way to see the real path? Same maybe if a path gets redirected via junction?
The -a option will not report all programs on your system, but all that are accessible in the PATH to the which.exe application you use.
The System32 directory is indeed a tricky case. The 32 and 64 bits versions of which.exe will indeed NOT see the same cmd.exe executable in the %windir%\System32 directory.
But in both cases, they have a single cmd.exe executable in their respective PATH. So I chose to report just that.
aGerman wrote:
28 Mar 2019 11:58
jfl wrote:
26 Mar 2019 12:54
a single .exe that runs in all versions of DOS and Windows, from DOS 3 16-bits to Windows 10 64-bits. Including Windows 95 and XP.
What kind of black magic did you apply here :shock: Windows Defender didn't like that witchcraft. I had to restore it from quarantine several times :lol:
There's no black magic :-). It's because the WIN32 version does not use the default DOS stub. (The one displaying "This program cannot run in DOS mode".)
Instead, it uses the DOS version of which.exe as the DOS stub for the WIN32 version. So the DOS version runs in MSDOS, and the WIN32 version runs in 32 and 64-bits versions of Windows.

If this triggers your Windows Defender, it's a false positive: The DOS version in the DOS stub does exactly the same as the Win32 version, but using int 21h calls!
I'm surprised this triggers your Windows Defender, because it does not trigger it on any of my systems.
But, on the other hand, the funny thing is that at work, the 64-bits debug version of which.exe (which I did not include in the zip file above) triggers the McAffee antivirus on one of my systems!?!
As a workaround, in the likely case that you have a 64-bits version of Windows, try using the WIN64 version of which.exe instead.

aGerman
Expert
Posts: 3639
Joined: 22 Jan 2010 18:01
Location: Germany

Re: which.exe v1.12 - Now efficiently detecting doskey macros and PS aliases

#4 Post by aGerman » 02 Apr 2019 10:02

Thank you for your explanations!
jfl wrote:
02 Apr 2019 09:44
It's because the WIN32 version does not use the default DOS stub.
Yes that was already clear to me. My question was rather how you where able to mount the 32 bit machine code to the DOS code without screwing up the addresses/offsets. But I'm afraid the answer to this question is off topic in this forum.
jfl wrote:
02 Apr 2019 09:44
If this triggers your Windows Defender, it's a false positive
Oh I trust you. As I wrote, I restored the tool every time. It was just for letting you know.
My OS is Win10 Home x64 v. 10.0.17763.379 if that does help you somehow. And yes, the 64 bit version of WHICH has never been quarantined. Don't worry too much about that.

Steffen

siberia-man
Posts: 123
Joined: 26 Dec 2013 09:28
Contact:

Re: which.exe v1.12 - Now efficiently detecting doskey macros and PS aliases

#5 Post by siberia-man » 16 Apr 2019 06:20

Yet another "batch only" implementation of the "which" utility can be found here: https://github.com/ildar-shaimordanov/c ... /which.bat

Code: Select all

:: USAGE:
::     which [-a] [--] name [...]
::
:: -a  Print all available matchings accordingly the description below.
::
:: For each of the names the script looks for and displays a doskey macro, 
:: the internal command information or the full path to the executable 
:: file in this order. The script doesn't mimic of the Unix command having 
:: the same name. It assumes specifics of the Windows command prompt. 
::
:: First of all, it looks for doskey macros because they have the higher 
:: priority in the prompt. The next step is a looking for internal 
:: commands from the known list of the commands. If the command is 
:: identified as internal the searching is stopped. 
::
:: If nothing has been found previously, the script continues searching of 
:: external commands in the current directory and the directories from the 
:: PATH environment. If no extension is specified, the PATHEXT variable is 
:: used for attempts to find the nearest filename corresponding the 
:: provided name. 
::
:: ENVIRONMENT:
::     PATH, PATHEXT
::
:: SEE ALSO:
::     DOSKEY /?
::     HELP /?
::     http://ss64.com/nt/
::
:: COPYRIGHTS
:: Copyright (c) 2010, 2014 Ildar Shaimordanov

@echo off

Post Reply