Next-gen Windows Command Line Shell Now in Beta
Suddenly_Dead writes "Microsoft's new command line shell, MSH or Monad, has entered the beta phase. Channel9 Wiki has information on how to download this (complete with Guest ID), and other related info."
Ok, but does bash or ksh run on windows? This is for their own OS, not unix.
Of course it does, silly.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Ok, but does bash or ksh run on windows? This is for their own OS, not unix.
Actually, yes, it does. Ever heard of cygwin? You can run a host of linux tools and shells on there including bash and ksh. I use it on my home computer so I don't have to continually reboot my computer just to use gcc or something of the like when I'm on Windows.
-py
I have no idea what the previous text was but it wasn't the Monad Beta 1 shell. Actually, a real screenshot looks like the following and the concept of drive letters is not really used:
Microsoft Command Shell
Copyright (C) 2005 Microsoft Corporation. All rights reserved.
MSH>_
Windows has had symbolic links since Windows 2000. It was called junction points.
In XP it was renamed as reparse points.
That's just a cmd.exe (and explorer.exe) limitation.
The NT kernel fixed the backslash brokenness years ago.
Some bits about the shell:
Natively, both forwardslash and backslash are allowable as separators. You can use both and even intermix them. So 'C:/program files/Mozilla/' should work just fine.
The verbosity is a bit annoying, but that can be taken care of via aliasing. Also, all options are shortenable as long as they're disambiguous. Furthermore, you can alias everything just like you can in unix, so if you don't like get-process as a name you can just alias it to gp or ps or whatever you like.
Why it's better than using Perl: because it has built-in OS hooks. You don't get the list of processes back when you run get-process: you get a streamed list of processInfo objects. If you want to store them and use them later, you can. If you want to kill a specific process, you can run process.kill on it. Want to browse the registry or AD the same way that you browse the filesystem? You can do that too. Want to format anything in a certain way? You can pick and choose what columns to display and how to display them easily, and you can set these as the defaults for these objects.
I'd strongly recommend trying it. As a linux user and a windows user, it has a lot to recommend it. It has much of the good parts of unix-style ideals - small parts, working together and all that is where the name comes from (it's a Leibniz idea, in case you were wondering). It's very composable and mixable. It works quite a bit better than any other scripting language in exposing the native APIs. It almost allows lamdba closures; it is a lot closer to lisp than to perl or bash.
Try it.
All the others use strings for piping.
If you read the article (Wiki) you'd see that Monad does too, it just automatically converts them before passing them off to the program (like PHP does with all of its variables). We'll have to wait and see if their approach is any good - there's a lot of flexibility in grep and awk that I don't see MS duplicating to occur automagically.
The previous text is the interface to XP's default shell, cmd.exe.
How Can I get MSH?
To get MSH, first navigate to http://beta.microsoft.com/ and logon using Passport. Then, click where indicated just after the text "If you were issued a guest ID by Microsoft you can sign in" then enter the guest id of mshPDC (this is case sensitive!). You the need to enter your details and you should get beta details back within a couple of days with site access to the MSH bits.
What the fuck where you trying to say?.
Not to be pedantic about your pedantry, but I think you meant were, not where.
Those who do not understand Unix are condemned to reinvent it, poorly
.NET class derived from our base class and tag it with a NOUN and VERB. The properties of that class become PARAMETERS.
Actually, in this case it should read...
Those who do not understadn VMS are condemned to reinvent it, poorly
Monad is heavily influenced by VMS, not the UNIX shell.
From an interview w/ the Monad developers.
MSFT Jeffrey Snover (Expert):
Q: I've heard Monad has VMS roots... will we have a utility or functionality similar to VERB to create our own verb commands and parameters?
A: We are very influenced by the VMS (and AS400) environments. That said, we don't have the same set of utilities. Do define you own command, you write a
The first DOS versions didn't support directories at all-- all files were flat on the disk, so you didn't need path separators. By the time a path separator was needed, front slashes were already being used for command line parameters, so they needed something else, and they picked the "next best" thing-- the backslash.
Now, as to why they decided to use front slashes for command line parameters, I have no idea.
Yes, there is a reason for it. The original MS-DOS didn't have directories and used / for command-line switches where unix uses - (e.g. copy /b or dir /p). When MS-DOS 2 came out with directory support, they wanted to stay compatible (so you could use batch files from DOS 1, etc.) but with the primitive state of the applications back then, using / as both the command switch thing and directory separator would confuse them, so MS decided to use \ as the directory separator instead.
I am trolling
What? MSH has absolutely nothing to do with the Windows kernel. Perhaps you've mistaken its "native" access to things like the registry as "hooks into the Windows kernel". That functionality is not "built-in", but available through a default set of "providers". You can write your own provider to add new functionality. Similarly, most of the functionality of the shell itself is not built-in, but provided by a bunch of default cmdlets (small bits of code either provided in a .NET assembly or even written as a MSH script that perform some task). Where in unix you'd write an application like grep or a small script to process some data, in MSH you'd write a cmdlet. Like unix providing you many useful bits by default like grep, awk, cut, or sed, MSH provides a bunch of useful cmdlets by default like select-object, where-object, or sort-object.
Off-topic about names: Monad/MSH follows a "verb-noun" standard. Thus what would be "sort" in unix is "sort-object" in MSH (beause it "sorts" a bunch of "objects"). As many others have pointed out, you can use aliases to make these names shorter (MSH ships with a bunch of default aliases to provide both dos-like and unix-like functionality).
Let me think, Can you rotate, resize and compress a JPEG, GIF or PNG
on the MS$ command line?
You can if you install the appropriate tools to do so, yes. Same as with any other OS with a command line system. I have ImageMagick on my system, so yes I can.
Can you do this ssh user@domain.com.
Yes, if you have ssh installed.
Can you run a firewall script from the cmd?
Depends what you mean by "firewall script". I don't really understand what you mean, but you might mean something like "netsh firewall set opmode enable", which is the command to turn the firewall on. There are similar commands for opening/closing ports, switching notifications on and off, and so on.
Can you chmod or chown?
You can use those exact commands if you've installed cygwin or something similar, or if you'd rather just use the default utilities, cacls can achieve just about anything you want.
Actually, I think I have heard/read that since Windows 2000 (and maybe earlier for the NTs), every administration task in Windows was required to be manageable via command line, as well. Something like that, at least - there certainly are a lot of command line apps in
I don't know what exactly makes cmd.exe anemic - it's perfectly fine, in my opinion. It's not as powerful as bash or the other Unix shells, and the scripting is terrible, but it's just fine for basic interactive file management and the execution of command line apps. It does name completion (command.com didn't), which is basically THE killer feature for me.
There is no clear way to interface with the system, such as with kill -SIG PID (granted, this is because Windows is void of a kill binary); the intent behind this is likely the design philosophy of Windows. Ships with every Windows post 2000, I think.
As for other interfaces with the systems, like I said, there is a lot more than what you expect. The NET command certainly is well-known and used for about a thousand things, notable starting and stopping services. It certainly beats the rc.d scripts from my point of view, although I guess that's just because I'm used to it.
That said, one of the first things I do in a fresh Windows install is get Cygwin along with some Unix essentials - grep, wget, etc. And ls for the pretty colors.
Switch back to Slashdot's D1 system.
The entire .NET class library is exposed to MSH. And the class library almost entirely wraps all Win32's functionality. So yes, you can do anything. The design philosophy behind Longhorn is that any UI configuration must be exposed in the CLI. On and by the way, you get lossless JPEG rotation in Longhorn.
Why is everyone immediately saying cygwin? Windows Services for Unix is the official release of ksh for Windows.
'cause 95% of us think that ksh is a horrible, horrible shell, and that bash "rulez".
Probably because cygwin takes ten minutes to install and is a snap to use while SFU is a royal pain in the ass to install and maintain.
The cake is a pie
The link says the story might be apocryphal, but David Korn confirmed it right here on /.
The real world. How many method invocations will your structured 10kb of data require to find the relevant data items? Think about it--there's a reason xml stream parsers are much faster than parsers which load the entire xml doc into an object model.
You're really, really confused. Take a simple example, such as getting the process ID of a task from that task's name. The obvious way to do it in bash is to do a ps ax, then grep through the lines of output and finally use awk to separate out the process id field. With Monad, you could (probably) just make a method call like OperatingSystem.GetPID("TaskName") and get the information you wanted directly and efficiently, without any parsing overhead. If you think that the most efficient way of handling structured data is to serialize it into text streams and then parse it with primitive parsing tools, you're just plain nuts. The most efficient way to handle structured data is to actually process it as structured data, not as a text stream. Presumably, in those cases where your data actually is a text stream, Monad would allow you to process it as such. But text streams are a poor way of representing most structured data.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
Maybe it's because I come from a more Microsoft- than *nix- centric background, but since where and when have Microsoft ever made any sort of statement even resembling anything close to what you've said above? Sysadmins have plenty of tools at their disposal. See %windir%\help\ntcmds.chm for tons more info than I can provide here.
I use Windows at home and at work and find the command line environment very powerful and usable. I admin my machines (3 at home, 3 at work, 1 laptop, and several remote family member's pc's) almost exclusively via the command line. The set of default tools has increased dramatically in the last 10 years, and any Microsoft OS released in the last 5 years includes all of the following:
sc - service controller for starting/stopping/managing services on local or remote machines
diskpart - create/modify/delete local disk partitions (including advanced configurations like RAID arrays)
bootcfg - modify boot entries
fsutil - file system tools (reparse points, sparse files, hardlinks)
netsh* - network configuration tool to manage interfaces, protocols, routes, firewall, etc.
wmic - complete WMI (Windows Management Instrumentation) control
cacls* - modify NTFS permissions
systeminfo - query basic configuration information for local or remote machine
findstr - text searching, and yes, it handles regular expressions
msiexec* - not strictly a command line tool, but supports installation/configuration/uninstall of any
reg - modify the registry (including online and offline hives, and other users' hives)
I do find a couple of things lacking, so I customize all my Windows installs to include the following (all free except for the last, which requires that you own WinZip):
File Hashing: By the time Microsoft came out with fciv, I was already sold on fsum.
HTTP Downloads: I use wget for Windows.
Patch Scanning: I use MBSA for an instant report of missing patches so I can avoid Windows Update.
cab Compression Tools: Uncompression is supported natively via "expand"; need cabarc from the support tools to compress.
zip Compression Tools: Free add-on to Winzip works here.
Most people I know (Windows and *nix users alike) are very uninformed about Windows command line capabilities. However, this does in any way mean that the command line is crippled, or unable to perform the same admin tasks that are possible via the GUI.
*also existed in Win2000 or earlier
Since Monad can instantiate objects and call methods on any .NET Framework class that's public, any windows developer who writes anything using the .NET Framework will automatically have their classes accessible to Monad.
This is the case with many developers who are writing for any sort of managability. If they want an even nicer syntax, then they can custom write cmdlets which would then use a full verb-noun semantic for an even nicer user experience, but it's not required.
Finally, it's really easy to write Monad cmdlets if you already have the .NET class implemented. The most basic version of get-process is a grand total of 5 lines of code.
Leonard