doskey
is a utility primarily designed to work with cmd.exe
, not PowerShell.
- PowerShell has better functionality built in, in the form of aliases and functions, and in Windows 10 you must even deactivate PowerShell's own command-line editing to even get
doskey
to work (see below).
If you still want to use doskey
in PowerShell, there are two prerequisites:
The PSReadLine
module - which handles command-line editing since Windows 10 by default - must not be loaded, as it takes precedence over doskey
definitions[1]; that is, you may need to unload it explicitly with Remove-Module PSReadLine
, but that means that you'll lose all of its benefits.
You must invoke any doskey.exe
macro definitions with /exename=powershell.exe
(Windows PowerShell) or /exename=pwsh.exe
(PowerShell Core) for them to be usable from PowerShell.
Note that it is then doskey
that expands a macro name typed by the user, which means that PowerShell only sees the expanded command and therefore has no knowledge of macro names. Therefore, trying to inspect doskey
macros with
Get-Command
won't work; inspect the output from doskey /macros
instead, as in Lee Dailey's answer.
Additionally, doskey
also resolves macros when soliciting arbitrary user input via Read-Host
[1], which is undesired.
To summarize the reasons for not using doskey
in PowerShell:
It cannot be used with the PSReadLine
module, which by default handles command-line editing since Windows 10 and provides invaluable functionality.
doskey
macro expansion invariably also occurs when scripts solicit arbitrary user input via Read-Host
, which is undesired.
Therefore, I suggest you abandon doskey
in favor of PowerShell functions, and add them to your $PROFILE
file so that they're available in every session:
While you can define functions named for numbers such as 105
in PowerShell, you'll have to invoke them with &
so as to disambiguate from actual numbers, e.g., & 105
.
Therefore, I suggest refactoring your approach to define a single function named, say, c
, that takes an optional argument to identify which file(s) to open:
function c { pushd E:/static5; code $(if ($Args) { $Args } else { '.' }); popd }
Your original doskey
macros then map onto this function as follows:
105
-> c 105
135
-> c 135
static5
-> c
Note that this not only allows you to pass an arbitrary file name (of a file located in E:/static5/
) to function c
, but even multiple ones; e.g., c 105 135
would open both files for editing.
To inspect the definition of function c
later, you can simply call $function:c
or, more verbosely, (Get-Command c).Definition
.
[1] As PetSerAl notes: "doskey
performs translations on the console input buffer. [...]. It does not work if the console is not in line input mode, thus it is not compatible with PSReadline
, although Read-Host
will be affected.
https://i.stack.imgur.com/HpYzq.png"