“Buried deep within Windows’ bosom is a carbon-crusted fossil from the ancient days of computing. This aged wart on Windows’ soul harkens back to a more primitive time, when computers lacked the oomph to go graphical and mice were nothing but rodents. I speak of the command prompt, whose roots lie in DOS, that antique operating system of the 1980s. DOS is gone now. Yet despite Windows’ glorious graphical goodness, a wispy memory of text-based computer life still exists. It’s a program called CMD.EXE, and it appears in Windows as the command prompt window. Believe it or not, the command prompt to this day still serves as a useful alternative way to control your computer. Indeed, there are some things you can do in the command prompt window that in Windows’ graphical interface are tedious, slow or darn near impossible. Come with me as we discover how an old warhorse like DOS can once again find purpose.”
…if only for the news (to me) of the ROBOCOPY command. That could be very handy at work (Win2K3R2 servers). Of course, I’d much prefer cp, but you can’t have everything.
Yeah, it’s a quite interesting artice. Even though I am using Cygwin with Bash as my shell of choice under Windows, there’re some information I might use in the future (especially the Networking part)
Google “Robocopy GUI” for a decent graphical frontend to Robocopy. It’s finicky, but helps out with the plethora of switches, plus you can script it out after designing it for doing batch processing.
http://www.microsoft.com/technet/technetmag/issues/2006/11/UtilityS…
It’s also worth mentioning that xcopy can do many of the things robocopy can do, such as the ability to restart failed copies, preserving file ACLs/attributes, etc.
…that CMD.EXE isn’t DOS at all. It’s a Win32/Win64 console application, that presents a command-line interface similar to DOS. If you want emulated DOS, you run COMMAND.COM (and notice how sluggish it feels in comparison).
CMD.EXE has moved on an awful lot from the interface it inherited from DOS (lots of new commands and new switches to older commands, as well as incidental features, and slight variances in behaviours to make life easier for people doing scripting).
Cmd.exe is not DOS, like some parts of the article seems to imply.
Edit: To late.
Edited 2007-10-21 11:42
Cmd.exe is not DOS, like some parts of the article seems to imply.
IIRC then in Windows NT 4.0 sometimes cmd.exe reported DOS version 5.0 or something.
If you run “COMMAND.COM” (or some other actual DOS program), the INT 21h function call to return the DOS version reported that it was MS-DOS 5.0; this is buried in ntvdm (the virtual DOS machine that provides emulation services for DOS programs).
CMD.EXE would always report the actual Windows version, as it had nothing to do with the DOS VM.
You recall incorrectly. Cmd.exe has never pretended to be command.com or DOS.
(DOS can use forward slashes, but their behavior is inconsistent, so it’s safest to stick with the backslash.)
That’s news to me.
ROBOCOPY is a directory-copying (i.e., folder-copying) tool. It can even mirror a directory tree on a network computer, which can help you resume automatically after a network failure.
FINALLY, WE CAN COPY DI…err…FOLDERS!! OMG!!!111
And my favorite:
GETMAC
Quickly and diligently, your PC’s MAC address appears.
DOS got colourful command prompt NOW!!!
COLOR 1F
WOW, just wow….
> FINALLY, WE CAN COPY DI…err…FOLDERS!! OMG!!!111
Hold your sarcasm. The ability to correctly resume ofter a network disruption, or the mirroring ability (deleting files in the destination that were deleted in the source) are very useful.
One word: rsync
come now
just because we have things a little more luxurious than them doesent mean we should announce it to them 
After years of ignoring rsync, because I don’t run any mirrors and prefered archive formats like tar.lzo for backups, I have “discovered” rsync. It is truly amazing. I always assumed that it only operated at the file level. In reality, the amazing rsync algorithm can operate upon files down to the 1k block level, quickly and efficiently syncing corresponding files which differ, with transparent compression, and with minimal use of bandwidth and processor. Once in a while I come across something that I have *known about* for years, which absolutely stuns me when I look closer and discover its true capabilities.
ROBOCOPY also has a folder-change notification based mirroring mode that monitors and syncs. Also, there’s no reason you can’t run rsync on Windows
. It’s just a program after all.
right…. its just a freaking pain and install it for winblows.. i for one really really prefer having it by default with gentoo, or simply issuing 1 command and have the package manager install it
Am I the only one old enough to remember xcopy?
As far as I can tell, the sole purpose of CMD.EXE is to let the wizened old computer science professors here continue to pretend that GUIs never happened…
From the article:
To hear some Microsoft programmers talk about Windows Powershell as if it’s God’s gift to them, and how it is the best UI ever, I do not doubt this.
Edited 2007-10-21 15:58 UTC
As far as I can tell, the sole purpose of CMD.EXE is to let the wizened old computer science professors here continue to pretend that GUIs never happened…
Or perhaps it’s the easiest way to automate large cumbersome tasks other than downloading a full development environment and learning a programming language.
I find that GUIs are generally imprecise and error-prone methods of commanding a computer to manipulate files in a way that could otherwise be done very simply and quickly from a command prompt.
The GUI doesn’t solve the world’s computer-use problems, it often just puts a single-button interface in front of a user that couldn’t otherwise do anything.
(edit: fixed tag)
Edited 2007-10-21 16:59
Yes indeed. Anyone who has tried Windows scripting, WSH GUI scripting not command line batch, will agree with this. Spending a couple minutes whipping up an on the fly batch file is nothing really even for a novice while whipping up an WSH file is pretty hellish, especially for a novice.
It is very simple: For tasks you don’t do often, so that you basically have to relearn them every time you do them, ad GUI is more efficient, because it’s procedures are closer to real-world physical experiences the user has (take drag and drop moving of some file, it’s close to moving physical objects).
For tasks you do often, the command line is better, because you don’t need to relearn all the time, and the command line is much more powerful than the GUI.
Two words:
Logon scripts.
I don’t know what an old unpatched vulnerability has to do with the topic at hand…
Eh?
Have you ever been near a corporate Windows installation? Logon scripts are used fairly typically on a regular basis to ensure consistency across the network (although I’m sure Microsoft would rather they were all written in VBscript or were GPOs or something instead). It’s not uncommon for ITS to need to roll out “ensure X is in Y location for every user when they log on” type stuff, or forcibly mount network drives (Windows—rightly—won’t “remember” to re-mount a share next time you log on if you manually disconnect it), or sync some arbitrary data with your proprietary back-office at logon time.
As far as I can tell, the sole purpose of CMD.EXE is to let the wizened old computer science professors here continue to pretend that GUIs never happened…
Well, then you’re misinformed. Scripting is a terribly useful thing, and most GUI’s completely suck at it– or would, if they actually did it at all.
Using a gui of your choice under Windows Server 2003R2, create a job to run nightly that creates a .zip file of a specific directory, copies it to another server, and maintains no more than 5 past copies. The zip files should have a name of the format of “backups-YYYYMMDD.zip” where YYYY is the year, MM is the numeric month, and DD is the numeric day.
I used infozip’s zip.exe, cmd.exe (batch file), and scheduled tasks. I could have used perl, but the script would have been more complicated(!?!), and it would be Yet Another Package to document and maintain in the event the system needs to be rebuilt.
“As far as I can tell, the sole purpose of CMD.EXE is to let the wizened old computer science professors here continue to pretend that GUIs never happened…”
Ignorance is not a point of view, pal.
“””
“””
No. I *rarely* use Windows. But I have clients who do. And some of them have need to connect to their Linux servers remotely. There is ssh, of course. But dynamic IPs, combined with the prevalence of brute force password attacks these days makes straight ssh a no go. And, of course, they want to print. OpenVPN is *great*. But talking a user through copying a key file and config file to the proper location and setting it up to run as a service is a frustrating affair for all concerned.
But with cmd.exe, it’s easy to send them a zip file and have them simply click “setup”. While Windows’ command line does not seem to be as powerful as what I am used to, I was pleasantly surprised that I could start the service and set it to start automatically in just a couple of lines.
I’m hardly a wizened old computer science professor. But it’s obvious to me that one does not have to look hard to find real *utility* in the Windows command line in the 21st century.
Didn’t I read an article a while back saying that future Windows Server versions would have the option to run *without* a gui?
I’m not a big Microsoft fan, as my OSAlert comrades surely know. But hey, we learn from them. They learn from us.
It’s pretty amazing what can be done with CMD.exe after rooting around in it, and about it, for a while. My personal favorites are CACL(S), I think that’s the correct spelling, and diskpart. There are pretty powerful tools out there, but the mainly manifest themselves in the enterprise arena.
It’s still not as powerful as the Unix command line, but that has been honed for years.
Good thing Windows comes with GUI ping, route and tracert, right? Oh wait, it doesn’t.
Not that the CLI tools are good (they’re quite abysmal really) but it’s all you get to do basic troubleshooting with.
bash, I think they will like it.
Edited 2007-10-21 16:12
They have bash. It’s not base, but it can be added on.
http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX
… the Windows command prompt is lousy at best. Fortunately you can install the GNU tools on Win32 and do some serious scripting.
Edited 2007-10-21 17:33
Yes, one can install GNU tools – or possibly Cygwin – or SFU (Services For Unix – parts released under the GPL by Microsoft) – or one can install Windows PowerShell. It is ~99% compatible with Bash-syntax as well as old DOS-syntax.
copy, cp, del, rm, dir, ls, move, mv and so on… it’s there.
Not in the older CLI – but the newer CLI. Microsoft should at least have credit for that.
“Fortunately you can install the GNU tools on Win32 and do some serious scripting.”
Or use VBscript, or a combination of Automator/Applescript/Bash on OSX
Don’t ever use VBscript. There’s a reason why it is hidden away as much as possible in WinXP and Win2K3.
The windows command line is OK. But for serious command line stuff I use a wrapper around it. My personal favourite is winconsole(http://winconsole.co3soft.net).
There is a lot of commands and info available in there. How does it handle security? What can the non-administrative user do?
Basically anything that doesn’t affect the state of the system outside the user’s given set of privileges (e.g., standard user can’t modify files owned by the system or another user). You can use runas to run commands using different credentials, or optionally on Vista, right-click the command prompt shortcut and click “run as administrator” to open an elevated prompt.
Edited 2007-10-21 18:38
I still prefer JPSoft’s 4NT (as I did in the age of dos, but then I preferred 4DOS
It’s also possible to change the command prompt window’s text and background colors, something old-time DOS users requested for years.
Huh? You’ve been able to do this in DOS for as long as I can remember using it. I used to do this with DR-DOS and MS-DOS 4 or 5, can’t remember but it certainly isn’t something new.
You could do it with ANSI.SYS and clever use of the PROMPT environment variable since DOS 3.0, possibly earlier.
Windows does it differently, though, and somewhat more cleanly.
“Buried deep within Mac OSX’s bosom is a carbon-crusted fossil from the ancient days of computing. This aged wart on OSX’s soul harkens back to a more primitive time, when computers lacked the oomph to go graphical and mice were nothing but rodents. I speak of the command prompt, whose roots lie in UNIX, that antique operating system of the 1980s. UNIX is gone now. Yet despite OSX’s glorious graphical goodness, a wispy memory of text-based computer life still exists. It’s a program called TERMINAL, and it appears in OSX as the command prompt window. Believe it or not, the command prompt to this day still serves as a useful alternative way to control your computer. Indeed, there are some things you can do in the command prompt window that in OSX’s graphical interface are tedious, slow or darn near impossible. Come with me as we discover how an old warhorse like UNIX can once again find purpose.”
BWA-HAHAHAHA! Oh, that was classic! So true… so true… except I think MacOS X, then, has older “bits” in it than even Windows XP/Vista. For shame!
Or does this article ALSO apply to XP/Vista? *gasp!*
You’re the best poster on OSAlert.
My interest to use windows command shell / dos ( or whatever you want to call it) dropped quickly when i first time needed read current date to a variable in BAT file.
Please, if _anyone_ knows any better way to do this on bat file not using any 3rd party tool, please let me know.
rem get date
FOR /F “tokens=2” %%i IN (‘date /t’) DO set mydate=%%i
C:TEMP>echo %DATE% %TIME%
Mon 10/22/2007 18:22:37.84
NET USE by itself does not show who’s using your shares… it just shows which shares you have credentials for and are using at the moment.
The rundll command he mentioned is also not exactly described properly. Rundll loads a dll and calls a function with the passed in parameters. In his “%SYSTEMROOT%SYSTEM32RUNDLL32.EXE “%PROGRAMFILES%WINDOWS PHOTO GALLERYPHOTOVIEWER.DLL”, IMAGEVIEW_FULLSCREEN %1″ command, he’s calling a function called ImageView_FullscreenW in photoviewer.dll.
Some unmentioned but useful commands are “NETSH” and “WMIC”.
Windows .cmd files are not the most pleasant development environment, but they do get the job done and vbscript can be used for most of the more complicated jobs.
I really don’t see the huge advantage that the common UNIX CLIs give the user over CMD.EXE. I’m curious about this one for instance: what’s the UNIX equivalent of “RENAME foo.* bar.*” in a directory containing files “foo.h and foo.cpp”?
As an interactive shell the difference isn’t that big. You got your command history and command completion (does CMD have completion? I cant remember).
What makes the *nix CLI superior is the abundance of useful CLI apps, piping and the shell scripting. Bat and cmd files aren’t exactly smooth sailing and there’s not a lot of usefull CLI tools.
CMD supports file and directory completion and you can configure the key(s) that map to each function. The TAB key is used by default in most cases. Some versions of Windows (e.g., IIRC Windows 2000 RTM) may have completion disabled or not mapped to TAB by default (CTRL+D/CTRL+F for directories/files respectively). In this case, type cmd /? for details on enabling/remapping completion.
well, gee. the command prompt has never gone away, as the fresh-out-of-puberty (i suspect) author of the article tried to imply. for most of us experienced windows users, it is very much alive.
one infamous incident has a microsoft engineer making a file copy via command line while demoing a new windows releases …
For a real trip down amnesia lane press Alt-Enter in a CMD window, and check out DOS (or its look-alike) in all its full screen glory on your 21″ LCD
Always thought CMD was the NT command shell and COMMAND was dos?
If you go to start run and type COMMAND you will get Microsoft Windows DOS
You can tell the difference because in DOS you can’t see spaces in folders like you can in the NT shell.
So if you are in docs and settings in the NT shell you get: c:Documents and SettingsUsername
In DOS you get: c:DOCUME~1Username
on the NT side of things that is, NT/2k/XP/Vista;
cmd, and a host of tools have long been available for scripters. in corp land this stuff is used pretty often.
large cmd scripts, vbs scripts with all sorts of wsh, or just pure wsh. there are also tons of cmd/shell based tools available for scripters, things like ifmember for parsing nt and ad groups of cusrmgr the comand line user manager.
and on the vbs/Perl side of things there is tons of native calls you can do.
this is not rocket science, windows admins have been scripting since day one. (at least good admins do)
its not unlike good Unix admins, script everything. just becuase some people did not know, its possiable in windows does not mean you cann’t do it. there is even rysnc for windows, and most of the GNU tools have all been ported also. things like sed, etc are all there if you want them.
sheesh….
-Nex6
Edited 2007-10-22 13:26