CMD.exe compatibility

re: CMD.exe compatibility

Aaron Margosis — Tue, 22 May 2007 07:33:39 GMT

Yes and no. "Yes" because now I can use all the CMD DIR options that I'm used to. "No" because it turns all the output into straight text, defeating the purpose of being in PowerShell.

I agree with you - I don't want your team diverted from working on more important stuff. But a community effort should be able to make a great "function dir" replacement for "alias dir".

re: CMD.exe compatibility

Richard Siddaway — Tue, 22 May 2007 09:51:35 GMT

This is a good idea. What may be helpful especially to new PowerShell users is a set of functions that could add directly into their profile to do this sort of thing for the commonest DOS commands that are likely to be required

re: CMD.exe compatibility

Maximilian Hänel — Tue, 22 May 2007 14:22:34 GMT

A compromise between old cmd style and the new PowerShell object orientation might be a function like this:

function dir(cmd /c dir /b $args) | foreach{[System.IO.FileInfo](Convert-Path $_)}

Now you can type dir /ah and one still gets FileInfo objects back. Wow, it's so easy to get only hidden files ;-)

Don't get me wrong, I love PowerShell, but Get-Childitem is by far the hardest thing to learn in PowerShell.

re: CMD.exe compatibility

shaka — Tue, 22 May 2007 15:34:29 GMT

if ($args -ne $null) { $all = $args } else { $all = $input }

cmd /c $all

re: CMD.exe compatibility

Jim Foster — Tue, 22 May 2007 17:21:56 GMT

Maybe I am missing something here, but how about extending some of these existing commands, like Get-ChildItem, to handle those DOS-like items? Perhaps the new parameter names would be more PowerShell like (that is, not /q, but something more meaningful).

Now, I know that Get-ChildItem can be used for things other than the file system, but some of the other information stores that Get-ChildItem can query also have owners too (in this case), like Get-ChildItem HKCU:\. Where the parameter does not make sense like Get-ChildItem Env:\, the parameter could either be ignored or an appropriate error issued.

I have probably just over-simplified this whole process, but I thought I would pitch my idea none the less.

re: CMD.exe compatibility

PowerShellTeam — Tue, 22 May 2007 18:18:17 GMT

> Maybe I am missing something here, but how about extending some of these existing commands, like Get-ChildItem, to handle those DOS-like items?

We can and it is on the list of things to do. That said, here is the reality of how these things work. We keep lists of all the things that we want to do for a release. That list comes from us, our partners, our customers etc. Then we decide upon the THEMEs for a release. Think of this as "What will the newspaper say about the next release?". We then prioritize the list of things we want to do based upon how they support those themes. After that, we look at the input from customers and figure out how we can address as much of it as possible. There is no fixed algorithm for how teams do this and frankly we've tried a few approaches (dedicate a milestone to this, let people do it catch-as-catch can, etc) and we're going to continue to experiment because we value responding to customers highly. All that said, no matter what we do, there will be things that don't make the cut line for a release. "To ship is to choose."

So will we try to get this done? Definately.

Will it get done? I don't know.

This should point out how important it is for the community to speak up and let us know what is important to you. We look at every request that comes in. Common sense will tell you that if we see 100 people asking for feature 1 and 5 people asking for feature 2, feature 1 has a higher probably of getting done. Ergo - even though you know that something has been requested, you should request it or vote for that item.

Jeffrey Snover [MSFT]

Windows Management Partner Architect

Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell

Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

re: CMD.exe compatibility

Frisky — Tue, 22 May 2007 19:23:44 GMT

Thanks to Mark Russinovich for getting you guys' to think this through. And so simple... :)

Frisky

re: CMD.exe compatibility

Carl Klemmer — Tue, 22 May 2007 20:41:25 GMT

This kind of issue has left me dissapointed with PowerShell's performance thus far as an interactive shell. CMD and csh commands have option and formatting choices that have been refined over many years. I don't want to have to rewrite these myself. And while it's cool that I can just use the old DIR inside powershell, what I really want is a new dir with all the formatting and options of the old dir, along with the object features that let it be leveraged in the powershell environment.

I'd love to see a default compatibility pack providing CMD like formatting and options, as well as optional packs mimicking other popular shells.

re: CMD.exe compatibility

PowerShellTeam — Tue, 22 May 2007 21:05:20 GMT

The PowerShell Community Extensions project provides functions that provide some of the features you might be looking for:

$content = Get-Content "c:/Program Files/PowerShell Community Extensions/Profile/Dir.ps1"

$xmlContent = $("<XML>"; ($content -match "###") -replace "###",""; "</XML>" | Out-String)

$xml = [xml] $xmlContent

$xml.XML.Function | Format-List Name,Description

name : dirx

Description :

DIRX is an extended dir function that is used by dird, dirs and dirt.

It provides shortcuts for displaying files/dirs with particular

attributes. For more information execute "dirx -?".

name : dird

Description :

Displays just containers (directories).

name : dirw

Description :

Displays folder contents in wide format.

name : dirs

Description :

Displays folder contents sorted by size descending.

name : dirt

Description :

Displays folder contents sorted by time descending.

Lee

re: CMD.exe compatibility

Brian Reiter — Tue, 22 May 2007 21:42:22 GMT

This same trick works great for accessing classic UNIX commands that run under SFU/SUA/Interix.

#aliasing functions for SUA unix utilities

function dig { & "$env:systemroot\posix.exe" /u /c /bin/dig $args }

#By invoking xterm via /bin/sh we get an environment set up before xterm starts (good for xterm -e ssh foo)

#function xterm { & "$env:systemroot\psxrun.exe" -u -p /usr/local/bin/xterm -- xterm $args }

function xterm { & "$env:systemroot\psxrun.exe" -u /bin/sh -l -c "/usr/local/bin/xterm $args" }

For statically linked PSXSS binaries you can also hard-link them to /common where foo links to foo.exe.

For example whois could be a function:

function dig { & "$env:systemroot\posix.exe" /u /c /usr/local/bin/whois $args }

-or-

% ln /usr/local/bin/whois /common/whois.exe

Since C:\SFU or C:\Windows\SUA is automatically put into the PATH environmental variable when SFU or SUA respectively is installed the hard link option gets you a two-fer: it works in CMD.EXE and PowerShell.

re: CMD.exe compatibility

Joku — Tue, 22 May 2007 22:55:50 GMT

Could you make a blog entry about why the copy function of the PS window imitates that of CMD in that the content is stays wrapped in the copy.

That's what annoys about cmd the most really and it's in PS too, run some command like say tracert and use the mouse/quickedit to copy it then paste to somewhere and it looks like this:

8 12 ms 13 ms 13 ms gi3-3.ar1.ARN3.gblx.net [67.

17.196.241]

9 105 ms 105 ms 105 ms qwest-1.ar3.JFK1.gblx.net [2

08.50.13.170]

10 108 ms 107 ms 107 ms jfk-core-02.inet.qwest.net [

205.171.30.57]

11 123 ms 122 ms 123 ms atl-core-02.inet.qwest.net [

67.14.14.14]

What's the usability scenario where this behaviour is preferred over the other? Usually Microsoft is good in getting things right for the common scenario and not optimizing for the edge/corner cases? I know you can pipe output to file and so on but it's just way too often that I'd actually want to copy something already on the screen that this issue should simply go on being ignored.

re: CMD.exe compatibility

Vinicius Canto [MVP] — Wed, 23 May 2007 06:04:17 GMT

Great! But there are a lot of options and commands to create wrapper-funcions. I gave an example of this some months ago, when I wrote about DIR /AD command and its Powershell replacement, the ugly get-childItem | ? {$_.PSIsContainer}

[]s,

Vinicius Canto <scripterbr_at_gmail_dot_com>

MVP Visual Developer - Scripting

MCP Windows 2000 Server, Windows XP e SQL Server 2000

Blog sobre Scripting: http://viniciuscanto.blogspot.com

re: CMD.exe compatibility

Query — Wed, 23 May 2007 22:03:52 GMT

I'm curious about how the old Doskey macro utility interacts with cmd.exe and the win32 console.

It's my understanding that in NT based systems, Doskey is merely an interface for accessing functionality built into the win32 console. But if that is the case, why don't certain funcitons work in powershell?

For example, the command doskey /history prints out the command buffer in cmd, but not in psh. Yet, creating a macro using the switch /exename=powershell.exe will work even to the extent of overriding psh aliases.

My question is: are the doskey macros handled by the console itself and, if so, would there be an easy way to migrate them to psh aliases?

re: CMD.exe compatibility

Jeffery Hicks — Fri, 25 May 2007 06:03:30 GMT

I use the DIR switches all the time. I have to confess that I take the lazy way and use

cmd /c dir /a-d

when in PowerShell. I like to type as few characters as possible.

assoc

Sun, 11 Nov 2007 12:07:41 GMT

hi ...

do tink about this problem in mi sistem..?

this comand : assoc .exe=.exe

thank you..

ithoo.kish@yahoo.com

re: CMD.exe compatibility

Larry Weiss — Thu, 19 Feb 2009 05:29:52 GMT

Here's what I do. I define a file named

"~.bat" in the PATH as these two lines

@echo off

Thereafter I can just do

~ dir /q

at a Powershell prompt.

There's nothing magic about the name "~", but I find it conveniently terse. It allows me access to all the cmd.exe supported internal commands.

- Larry Weiss, lfw@airmail.net