You are not logged in.
Pages: 1
The list of commands identified as internal at An A-Z Index of the Windows CMD command line is incomplete.
The internal MKLINK command is listed, but it is not identified as an internal command.
The following internal commands are not even listed as Windows commands
BREAK - Pretty much useles, but it exists
CHDIR - synonym for CD
MKDIR - synonym for MD
RENAME - synonym for REN
RMDIR - synonym for RD
I discovered the above while working on this StackOverflow question: Check if command is internal in CMD
Dave Benham
Offline
In fact I'm using BREAK for creating empty files :-)
Offline
Yes, I made a deliberate decision not to clutter up the list with all the synonyms, but the synonyms are mentioned on the individual pages so a search should find them. Also if you navigate manually to the URL http://ss64.com/nt/chdir.html http://ss64.com/nt/rmdir.html etc you should get redirected.
I fixed MKLINK now - thanks
The break thing is a neat trick, I'll have to think about whether thats enough to justify creating a page for an otherwise useless command!
Offline
Is the KEYS command internal?
It's not listed in the help output.Didn't find and exe/com in the path....Does not change the errorlevel so my guess is that it is an internal command.
Also not pretty useful - eventually can be used as a global boolean switch independent from setlocal contexts.
Offline
In fact I'm using BREAK for creating empty files :-)
In my opinion, this use of BREAK command is confusing. Any command that show nothing may be used to create an empty file. In old MS-DOS days I used REM command, but that trick no longer works. Currently I use:
cd . > empty.txt
KEYS is another old command preserved just for compability (and it is internal), but I am afraid that both BREAK and KEYS will disappear in future Windows versions...
Antonio
Last edited by Aacini (23 Jan 2014 00:42)
Offline
I think that is not realiable only use redirection for create a non empty file.
Because if the file have the read only attribute, the redirection fails with errorlevel 0 and error message on screen.
Also, for readability type nul can be used.
Maybe you can use this:
Rem If file exists:
Rem Take a decision: consider change the filename for not overwrite the user file.
Set "filename=Empty.txt"
Rem If Exist "%filename%" Call :getNewFileName
Rem If You want overwrite the filename: Attrib -r -h -s "%filename%"
Rem Also consider that change the attributes can be not possible for permissions.
Rem And redirection can fail.
Type Nul >empty.txt
Last edited by carlos (23 Jan 2014 05:32)
Offline
Gosh, I was a fairly heavy user of DOS, back in the day, and I have no memory of the KEYS command. Ouch.
Here is the Windows built in help:
C:\test>keys /?
Enables or disables command line editing on DOS system
This is present for Compatibility with DOS systems. It has no effect
under Windows, as command line editing is always enabled.
Not entirely accurate. It maintains the current state of KEYS, and it sets an environment variable! But the internal state is independent of any variable definition.
C:\test>set keys
Environment variable keys not defined
C:\test>keys
KEYS is on.
C:\test>keys on
C:\test>set keys
KEYS=ON
C:\test>keys off
C:\test>set keys
KEYS=OFF
C:\test>set keys=junk
C:\test>keys
KEYS is off.
C:\test>set keys
KEYS=junk
C:\test>keys on
C:\test>set keys
KEYS=ON
C:\test>set keys=junk
C:\test>keys
KEYS is on.
C:\test>
I don't see any use for it, but it does have an effect.
Dave Benham
Last edited by dbenham (27 Jan 2014 12:34)
Offline
Interesting. Didn't came to me to check for a changes in variables , but despite this looks like the KEYS does not rely pretty much on this variable , but just sets it:
C:\Windows\system32>keys
KEYS is off.
C:\Windows\system32>keys on
C:\Windows\system32>set KEYS=OFF
C:\Windows\system32>keys
KEYS is on.
C:\Windows\system32>set "keys="
C:\Windows\system32>keys
KEYS is on.
C:\Windows\system32>
(even when I manually set variable KEYS to OFF the KEYS command does not care and continues to take the keys for ON.May be it's only for easier checks of keys state )
Offline
Perhaps somewhat off topic, but here it is...
I thought in an easier way to identify internal commands looking for they inside cmd.exe file. The internal commands are written in uppercase unicode letters preceded by a two bytes lenght, so it is very easy to look for words with this format via JScript code, for example. The problem with this method is that it would give many false positive results, because there are many strings with this format inside cmd.exe that are not commands. Anyway, the part of cmd.exe that have readable text is interesting; here it is a segment of it:
C O P Y C M D . . . C M D . E X E = , ; P A T H E X T \ ; " c m d . C M D
. B A T F O R G O T O T I M E R E M N O T K E Y S I F E X I S T
E R R O R L E V E L D A T E D E F I N E D C M D E X T V E R S I O N D P A T H
M K L I N K V O L V E R V E R I F Y T Y P E S T A R T S H I F T S E T L O C A L
S E T R M D I R R E N R E N A M E M O V E R D P A U S E M D M K D I R
B R E A K E X I T E R A S E E N D L O C A L E C H O D I R D E L F T Y P E
A S S O C P O P D P U S H D P R O M P T P A T H C O P Y C L S C H D I R
T I T L E C O L O R C A L L C D | ) R E M / ? I F / ? F O R / ?
| | & & & P A T H P R O M P T K E R N E L 3 2 . D L L C O M S P E C
C M D C M D L I N E R A N D O M H I G H E S T N U M A N O D E N U M B E R c o n : . \ = , ; + / [ ]
0 1 2 3 4 5 6 7 8 9 : E O F % 2 d % s % 0 2 d % s % 0 2 d % s % 0 2 d & < | > / I E L S E
= = E Q U N E Q L S S L E Q G T R / B G E Q . * f d p n x s a t z o f f
E N A B L E E X T E N S I O N S D I S A B L E E X T E N S I O N S E N A B L E D E L A Y E D E X P A N S I O N
ÙÕ ÙÕ f¾ ÙÕ ÙÕ 2× u s e b a c k q u s e b a c k e o l = d e l i m s = s k i p = t o k e n s =
F A T D I R C M D c m d . e x e A F F I N I T Y A B O V E N O R M A L B E L O W N O R M A L B H I G H
L O W M I N $ P $ G / K % s / K - M A X N O D E N O R M A L R E A L T I M E
S E P A R A T E S H A R E D W A I T D I S A B L E D E L A Y E D E X P A N S I O N % c
/ D % s % 0 4 X - % 0 4 X % 5 l u . . . €·@ èµ@ SetThreadUILanguage
S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s \ S y s t e m CopyFileExW IsDebuggerPresent
SetConsoleInputExeNameW 1 M M / d d / y y .OCP S o f t w a r e \ M i c r o s o f t \ C o m m a n d P r o c e s s o r
D i s a b l e U N C C h e c k E n a b l e E x t e n s i o n s D e l a y e d E x p a n s i o n D e f a u l t C o l o r
C o m p l e t i o n C h a r P a t h C o m p l e t i o n C h a r A u t o R u n
e x t - m s - w i n - b r a n d i n g - w i n b r a n d - l 1 - 1 - 0 ^C G e T o k e n : ( % x ) ' % s '
o n
@ ( = = E Q U N E Q L S S L E Q G T R G E Q % s % s
. C O M ; . E X E ; . B A T ; . C M D ; . V B S ; . J S ; . W S ; . M S C
CMD Internal Error %s
% s = % s
\ S h e l l \ O p e n \ C o m m a n d & ( ) [ ] { } ^ = ; ! % ' + , ` ~ Null environment =
S o f t w a r e \ C l a s s e s O F F O N % s > A p p l i c a t i o n S y s t e m ( % s )
Then there is a section with several names of Win-32 API functions, that I assume are called by cmd.exe, and finally this xml text:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="5.1.0.0"
processorArchitecture="amd64"
name="Microsoft.Windows.FileSystem.CMD"
type="win32"
/>
<description>Windows Command Processor</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
</assembly>
Many years ago, in the days of MS-DOS versions 2 and 3, I identified the place inside command.com file where the default ECHO ON value was stored and modified it by ECHO OFF, so after that modification all Batch files started its execution with ECHO OFF (I don't remember the goal, but was useful at that time). We could use this technique to achieve certain advanced tricks that could be useful in certain cases; for example, to cancel dangerous internal commands (like DEL and RD) when the computer is used by beginners (I am pretty sure that just modifing the "DEL" and "RD" strings inside cmd.exe file will achieve that), or increment the 8 KB maximum size of variables managed by SET command. However, I understand that this technique is much more dangerous nowadays!
Antonio
Offline
@Antonio good idea to check the strings in the cmd.exe .Just have found a new internal "command" . Also not useful at all:
DPATH
It just sets environment variable called DPATH the arguments called for the value and it's help points to the APPEND command which is not available in 64b versions of windows (http://www.dostips.com/forum/viewtopic.php?f=3&t=5300).
DPATH variable is set by APPEND command also , and is where the appended data files are stored , but I can't make it work neither on 64 nor in 32 bit system.
And the value can be cleared with ; . (similar to PATH command)
Looks like command prompt still can surprise me :-)
Last edited by npocmaka (06 Apr 2014 08:22)
Offline
And one more thing that popped up - useback and usebackq are sysnonims for FOR /F
Offline
Yes, I got the same about useback FOR /F option, but I am reluctant to use it...
Offline
I have now added the BREAK command, if works as an equivalent to 'true' in bash,even if it wasn't designed with that in mind.
Offline
Pages: 1