Slashdot Mirror
Microsoft PowerShell RC1
rst+ack writes "Microsoft has released RC1 version of PowerShell the .NET-based shell with perl-like syntax previously known as Monad or MSH. PowerShell (PS) has been covered a few times on Slashdot. Contrary to cmd.exe and Unix/Linux shells it operates on objects, not text when passing data between scripts and executables. Easy access to .NET classes allows users to create quite advanced solutions in short time. PS won't be shipped with Vista or Windows Server 2007 but it will debut with Exchange 12."
You can do both with cmd.exe ... check the properties of the window and adjust the buffer sizes to your taste. I use 132X9999. Turn on Quick Edit Mode for right-click paste actions. And, if you want, you can also drag a folder from Explorer into the window to copy-paste the path to the command line.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
It will be a general download to the OS as well. It's just that the admin scripts shipped with Exchange will rely on it.
> One nifty feature though, is that you no longer have to type the drive letter first to change to a directory on it.
/d D:\Bar
You can do that in cmd.exe too--
C:\Foo> cd
D:\Bar>
Go somewhere random
Be sure to turn on tab-completion while you're at it (it's not the best tab completion in the world, but it's better than nothing)
- Oisin
PGP KeyId: 0x08D63965
RTFM mate. This is not reinventing the wheel. It's adding a few more spokes, better tires and tougher rubber.
PGP KeyId: 0x08D63965
I encourage you all to come kick the tires and find out what PowerShell really does/does not do. I think you'll be pleasantly surprised by its power and simplicity and might even like it. Many of us on the team have a deep background in UNIX and brought that into our work. Even if you don't like what we've done, trying it out will allow you to know enough to throw your rocks accurately. :-)
a milyId=2B0BBFCD-0797-4083-A817-5E6A054A85C9&displa ylang=en
http://www.microsoft.com/downloads/details.aspx?F
If you'd like to learn more, you can read our team blog at:
http://blogs.msdn.com/PowerShell
Enjoy!
Jeffrey Snover
PowerShell Architect
It takes five minutes to setup a passport account associated with any arbitrary email address and thus far has generated absolutely zero spam to my email account. You can also sign-up with a "Limited" passport account, which means, you can sign up with no association with any actual email address whatsoever. You end up creating a fake @passport.com address for signing in.
4 .0.5610.0&cbalt=www&vv=400&lc=1033
The contracts are not any different than what you would agree to with Google, Yahoo, or any other online service provider.
Furthermore, with only accepting the passport license, it's a bit shorter than hotmail's. Try reading it yourself. The TOS is actually very short and easy to read if you're not illiterate: https://accountservices.passport.net/PPTOU.srf?x=
I read the script, and I think it would help my character's motivation if he was on fire. -Bender
while we're giving out CMD.EXE tips, try this:
enter a few commands
then press F7 for surprising results
It's a legitimate question. The security of PSH is mainly two-pronged: first, as in every other console/shell, including cmd.exe, commands and scripts can only act with the permissions that the current user has. This is the standard *nix way of doing things, and it should be far more effective in Vista once proper LUA is finally well-implemented. The other prong is a combination of security features. First, there will be no default associated file type for PSH scripts, meaning that by default, it is not possible to double click a script file and have it run, like you currently can with .BAT files. You can always create an association, but the default behavior is to instatiate the shell first, then run the script with a command-line command. Second, by default, scripts in the current director must be explicitly invoked (equivalent to not having "./" in your PATH). Third, PSH will support code signing, so that scripts must be digitally signed by a trusted publisher. This can, of course, be yourself, because you can easily enough create a cert and trust your own certificate. But it would prevent a lot of trojan attacks.
If you don't know where you are going, you will wind up somewhere else.
Hands in my pocket
Windows PowerShell RC1 (for .NET Framework 2.0 RTM) x86
f 14c-8009-43ad-b953-1b18609cf14c/PowerShell_i386.zi p
http://download.microsoft.com/download/e/8/c/e8cc
Unfortunately a lot of the examples on ScriptCenter are direct translations of VBScript examples. This is good in the sense that it shows how a VBScript user can migrate stuff to PowerShell. It's not, however, a good illustration of how PowerShell works. The above script can simply be written as
get-wmiobject Win32_UTCTime
WMI is one of the reasons we needed an object-based shell - it presents Window management information as a collection of objects. Writing code to render those objects to strings and then parse them back into objects is not realistic. We needed a shell that could deal with them directly.
Bruce Payette
PowerShell Technical Lead
Microsoft
I can't believe no one picked up on this comment. Mr Payette here is giving us interesting insight into the reasons for the object-orientatedness of the shell.
As I understand it, the difference between PowerShell and your typical Unix shell is that the Unix OS is built around the shell and PowerShell is built around the OS.
As text exchange of data is the de facto way of piping data between applications in a unix system and the shell has long been the de facto way of interacting with the OS and the applications running on it most applications and the OS itself have been built to interact very well with the shell.
However, on windows, which hasn't been built around the shell and which presents objects as the standard way to share data, they had the choice of either
a: adding functionality to all applications in order to allow it to interact in a text-based way with cmd.exe, which is rediculous because of the vast number of applications already out.
OR
b: writing a shell built to integrate with the OS and the objects it uses to exchange data, which they did with PowerShell.
Basically, this seems a sound design decision which probably has it drawbacks (necessity for data type handling & such ) but seems like a good match for winOS'es. An object orientated shell would probably not work very well with a unix OS, if only for the fact that (most?) unixes are written in C, which does not do objects at all.
Seems like a good solution for windows systems, too bad it isn't (won't be?) included with the OS by default. It might make windows a better place to live for all us CLI types, and it can't possibly be worse than cmd.exe, can it?
---
"The chances of a demonic possession spreading are remote -- relax."