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.
I haven't tried this release yet, but the last one, seemed to run in the same command prompt window, so all GUI functions were the same.
One nifty feature though, is that you no longer have to type the drive letter first to change to a directory on it.
In other words cyou can be in "c:\foo", and just type "cd d:\bar". You used to have to type "d:" and then "cd d:\bar".
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)
For the record, MS didn't choose the slash direction (I believe that came from CP/M which grew into the original DOS that MS bought and labeled MS-DOS). It's a legacy thing.
Additionally, I've used MKS Toolkit and other such add-on utilities to get completely compatable scripting, shells, and utilities across Unix, WinNT/2k/XP, etc.
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
- 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
You're thinking about it the wrong way. It's OO in the sense of stdin and stdout, which are object streams and not character streams.
.NET object has a ToString() method, if the final output actually ends up on the console then ToString() is called and you get a result.
For example, "dir" returns a stream of objects which are of type "File". If you pipe that output into another command then it has the full file information available to it from the object stream, so can act on the file contents, file name, file type, file dates etc if it chooses. Another command "list-users" may output a stream of user objects. Something else may output a stream of some other type of object. etc.
From there, and some "glue" type commands which allow object transformation, property selection and taking of subsets of objects you can build up a fairly powerful command line that looks like a unix shell but is kinda different too when you think of all the metadata going between the commands.
Naturally, as every
Kinda cool. Not sure if it will be more or less useful than the unix model though.
Fear: When you see B8 00 4C CD 21 and know what it means
Increasing the buffer size still doesn't let you resize the window horizontally
True, but you can change the maximum window width as well. Change the buffer and window widths from 80 chars to something like 120 to get a wider window. You can resize it to make it smaller, though you get scrollbars along the bottom of the window.
Not quite as nice as a *term window, but then Windows doesn't revolve around a terminal quite like *nix does.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Linux is POSIX-compliant? No it's not... it implements a number of things from the standard but is by no means compliant with it.
If you are going to claim that the Linux implementation makes it compliant than you should extend a similar courtesy to Microsoft's POSIX implementations.
Both have some, but no where near all.
Help Brendan pay off his student loans
That's just not the case, cp/m did not have subdirectories at all (neither did msdos till ver 2.x or so). Okay, sure you can make the argument that users are subdirectories, but they didnt have a / and users were always at the top level (you can have up to 16 users, the default one being user 0 and going up to user 15).
The reason microsoft used \ instead of / has to do with how dos and cpm (possibly borrowed from vms?) pass command line switches to programs, they used the / character, so to avoid confusion microsoft used \. I guess it could have been worse, they could have enclosed subdirs in a pair of braces like cd [mydir] and cd [-], but that's another story altogether.
> I think you will get in big trouble if all this data has to fit into a .NET datatype, you'll need a lot of coding around (string to filename, integer to filename, etc etc) to get it working, which is not what shell scripting is about!!! I will write a real program if I want to do something tidy like that, my shell script is there to solve a problem quick 'n dirty, thank you very much!
2 5/583272.aspx
This exact scenario is actually simpler in Powershell - check this blog entry
http://blogs.msdn.com/powershell/archive/2006/04/
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
You might look into Cygwin and rxvt.
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
Couldn't they have picked a different name? I've been using PowerShell on Linux for years now. It's a terminal emulator for X11 (like xterm) and is the first result on Google for the word PowerShell. Now a terminal emulator isn't exactly the same as a shell, but I could see some confusion occurring as a result.
Yeah, VMS uses "/" for command line switches. Of course it does directories as "[foo.bar]" instead of "\foo\bar" or "/foo/bar", and when looking at a directory listing, directories show up like files with a ".dir" extension. The whole way VMS handles directories and files would probably confuse the heck out of DOS or UNIX users to some extent.
But I also think VMS and Microsoft have more of a connection in developer-land than UNIX and Microsoft, and it does sometimes show.
Just remember that "/proc" only contains process table information in real UNIX. The only OS I'm aware of where it contains everything one could possible care about in the kernel is Linux.
Also, "/proc" is rapidly being deprecated. Heck, on the *BSDs, it is mostly now a totally optional feature. MacOSX doesn't even have "/proc" at all. Solaris still has it, but I wonder how long. (since there are system/kernel calls that utilities can make to get at all that information anyways, and I've heard there are security issues with "/proc")
Here are some of the commands available:
So please check first before asuming anything
Im pretty sure the original UNIX had directories, a decade before MS-DOS was written.
-- listen to interesting music, support independent radio... WPRB
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."
There is just so much wrong with what you wrote that it is hard to know where to begin, it almost seems that you weren't even alive when these things happened:
while MS-DOS 1.0 did not have an hierarchical file system (a file system with directories and sub-directories) the concept of directories most certainly existed at the time that MS-DOS 1.0 was released (around 1981 or 1982). Other operating systems, including Unix, had been using hierachical file system for at least a decade (Unix was invented around 1972 and had a hierarchical file system almost from day one). While hierarchical file systems were not common on personal computers of the era, they were far from unknown.
Other aspects of MS-DOS were also taken from DEC OS's via CP/M: drive letters delimited by a colon, the 8.3 file name limit, file extensions and much of the original MS-DOS API are all carried over from CP/M and are in CP/M because they mirror similar features of DEC operating systems.
When a hierarchical file system was introduced to MS-DOS with version 2.0 it was pretty clear, at the time, that Micorsoft was trying to turn MS-DOS into a Unix look-alike (the hierarchical file system was unixy, as were a number of new OS APIs, including a whole new set of handle-based file-I/O routines, as well as command I/O redirection and piping in the shell). Since the slash had already been used by the DEC-lovers for option flag indication, and since the new-guard at MS wanted stuff to look as unixy as possible, they settled on the next-best-thing to a slash: a backslash. In other words, the backslash was chosen, not for it's incompatability but because it was as compatible as possible without breaking backward compatability with MS-DOS 1.0 and CP/M.
In fact, the Microsoft folks had very little choice in the workings of MS-DOS 1.0: they bought it for a song from the original author and had to ship it almost immediately. They couldn't have changed the flat file system or the other CP/M-isms even if they had wanted to (they probably didn't want to, initially, since the CP/M 'compatability' was a selling point). To suggest, however, that any of this was done in innocent ignorance, or that any of these things were invented after the introduction of MS-DOS, is simply dishonest: all the concepts that Microsoft later incorporated into MS-DOS 2.0 were present in existing operating systems ten years earlier (1970-73) and were well known to anyone familiar with computers at the time (1981/82).
just a ghost in the machine.
All it does is bring up a command history list
I don't know much about GNOME, but most of KDE (including KOffice) is scriptable via DCOP. DCOP can be used via the command line, or in several languages (python, ruby, perl, java, perhaps more). For building a program (yes, with a nice shiny gui) quickly and effectivly, use Kommander.
Jeffrey Snover, chief architect, acknowledges this on the old blog (the old blog's articles have been copied to the new PowerShell blog but the comments haven't.)
The startup time is something we're aware of and are working to improve as we reach RTM. Our priorities thus far have been primarily around ensuring that the core functionality is correct and the shell experience is a high quality one. As we move forward, we will be tuning up the performance of the Windows PowerShell.
With that said, this is just initial startup of the shell in which you should get the worst hit prior to the prompt loading. If you close the shell thereafter and load it again, the shell should open promptly. Individual commands execute more quickly as well as passing objects does not require a performance sapping test output and reparse phase which is normally required in most shells.
If you have particular scenarios or issues with PowerShell performance, let us know at http://connect.microsoft.com/ (sign up for PowerShell under Available Programs)
Leonard Chung
Program Manager
Windows PowerShell