#1 03 Nov 2012 16:54

dbenham
Member
From: U.S. east coast
Registered: 15 Apr 2012
Posts: 109

Additional internal commands

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

#2 03 Nov 2012 17:12

npocmaka
Member
From: Bulgaria
Registered: 03 Dec 2009
Posts: 421

Re: Additional internal commands

In fact I'm using BREAK for creating empty files :-)

Offline

#3 03 Nov 2012 20:37

Simon Sheppard
Super Administrator
Registered: 27 Aug 2005
Posts: 873
Website

Re: Additional internal commands

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

#4 22 Jan 2014 09:37

npocmaka
Member
From: Bulgaria
Registered: 03 Dec 2009
Posts: 421

Re: Additional internal commands

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

#5 23 Jan 2014 00:39

Aacini
Member
Registered: 05 Dec 2012
Posts: 115

Re: Additional internal commands

npocmaka wrote:

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

#6 23 Jan 2014 05:24

carlos
Member
From: Chile
Registered: 04 Nov 2008
Posts: 244
Website

Re: Additional internal commands

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

#7 26 Jan 2014 00:00

dbenham
Member
From: U.S. east coast
Registered: 15 Apr 2012
Posts: 109

Re: Additional internal commands

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

#8 26 Jan 2014 13:27

npocmaka
Member
From: Bulgaria
Registered: 03 Dec 2009
Posts: 421

Re: Additional internal commands

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

#9 27 Jan 2014 05:50

Aacini
Member
Registered: 05 Dec 2012
Posts: 115

Re: Additional internal commands

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

#10 05 Apr 2014 10:32

npocmaka
Member
From: Bulgaria
Registered: 03 Dec 2009
Posts: 421

Re: Additional internal commands

@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

#11 05 Apr 2014 12:24

npocmaka
Member
From: Bulgaria
Registered: 03 Dec 2009
Posts: 421

Re: Additional internal commands

And one more thing that popped up - useback and usebackq are sysnonims for FOR /F

Offline

#12 05 Apr 2014 12:35

Aacini
Member
Registered: 05 Dec 2012
Posts: 115

Re: Additional internal commands

Yes, I got the same about useback FOR /F option, but I am reluctant to use it...

Offline

Board footer

Powered by FluxBB