Microsoft Next Generation Shell 832
An anonymous reader writes "I found this while searching for Perl Jobs in India:
"The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the .NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of competitors' shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and .NET (e.g. command discovery via .NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete)."
Re:Needed at the Enterprise (Score:4, Informative)
You guys didn't research this too hard, huh? [jsifaq.com]
WSH (Score:5, Informative)
Re:Cygwin (Score:5, Informative)
For those whou don't know, Cygwin [cygwin.com] is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts: (1) A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality. (2) A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel. The Cygwin DLL works with all non-beta, non "release candidate", ix86 versions of Windows since Windows 95, with the exception of Windows CE.
Other thing which I'd suggest for anyone who is unfortunate enough to work under Microsoft Windows is Perl Power Tools [perl.com]: The Unix Reconstruction Project. The goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so. See the command list [perl.com].
(I post as AC, because I'm not a Karma whore or anything like that.)
Re:Good step (Score:2, Informative)
Ever since NT4 became a serious peice of infrastucture, Microsoft provided Resource Kits available to manage the more advanced characteristics. You can control everything that the GUI offers. It's just that a lot of people don't bother to look past the surface of the Control Panel.
If you want more advanced analysis of NT domain related issues, RPC problems etc, mass creation of accounts the only solution you have is to use the command line.
Re:Cygwin (Score:5, Informative)
Stop and start services remotely with this... (Score:1, Informative)
Wonderful tool. Part of a good package. Free (beer).
What's not to like?
Re:So, we're back to the 60's. (Score:5, Informative)
Consider - I want to resize a directory of images, and put them in a thumbnail directory. Which is easier?
Command line:
or GUI:
Re:Those dont know UNIX are (Score:4, Informative)
"Those who don't understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer
Re:Cygwin (Score:3, Informative)
Re:What about this one? (Score:3, Informative)
P.S.: I accidentally discovered that the native command line interepreter in Windows XP has a decent filename completion feature. Without thinking, I hit tab to complete a file name, and it took me a minute to notice that it worked even though I wasn't using bash.
Re:So, we're back to the 60's. (Score:1, Informative)
Click File/Open
Go to the right directory
Open the fileClick on Edit/Image Size
Set it to 128x96, or 96x128 depending on if it's portrait or landscape
Click Save As...
Go to the right directory
Click OK
Go back to the start, until all 300 or so images are done....
I hate to be positive about MS on
1 - Go to the folder
2 - Highlight the files you want to thumbnail
3 - Right-click and choose Resize
4 - Pick a size (or use the custom button to pick your own)and click OK.
YMMV
Re:So, we're back to the 60's. (Score:5, Informative)
Function CreateUser(sOuDomainPath,sUserName)e scription,sEmail,sPassword)
End FunctionOn Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sUserName)
oUser.Put "sAMAccountName", sUserName
oUser.SetInfo
oUser.AccountDisabled = False
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser = True Else
CreateUser = False
End Function
Function
CreateUser2(sOuDomainPath,sFirstName,sLastName,sD
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sFirstName & " " & sLastName)
oUser.Put "sAMAccountName", Left(sFirstName,1)& sLastName
oUser.SetInfo
oUser.FullName = sFirstName & " " & sLastName
oUser.GivenName = sFirstName
oUser.Sn = sLastName
oUser.AccountDisabled = False
oUser.Description = sDescription
oUser.SetPassword sPassword
oUser.Mail = sEmail
'oUser.Profile = "\\server\share\username"
'oUser.Put("HomeDrive"),"X"
'oUser.HomeDirectory ="\\server\share\username"
'oUser.LoginScript = "myscript.vbs"
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser2 = True Else
CreateUser2 = False
That's actually some code that can be easily found in a number of locations Microsoft, for example [microsoft.com].
Im not a huge fan of MS (Read my journal for opinions on your run-of-the-mill Windows admin), but I wish people would stop bashing Windows for a lack of understanding on their part. Most of this stuff is in the Windows 2k Server resource kit, too. I guess your company didn't shell out the $100, or you didn't read it...
Re:What the... (Score:5, Informative)
tcsh can. Guess the problem is still solved. tcsh can expand command from other 'completors' other than just the $PATH. Like, type mount somehost: and it will try to expand from the output from 'showmount -e' for example. Granted, they aren't reflection API's but that's just another buzzword to me :)
Re:Good news... kinda ;-) (Score:3, Informative)
Oh, if this were only true. As a systems developer and operating system architect (no, I do not work for MS), I can say, beyond a shadow of a doubt, that the underlying architecture of Linux (i.e. the kernel) is NOT superior to the 2k/XP kernel. Not by a longshot. OSS kernel hackers are making significant progress, but they are unfortunately stuck using an aging paradigm (UNIX) from a distant era of computing. UNIX is meant to be a data monster, nothing more, nothing less. Machines you could run for years without giving them a second thought as they churned through unfathomable amounts of information. And to be quite frank, it is still very well suited to its original purpose. On the flip-side, MS was able to start from scratch. The NT/2k/XP kernel, while similar in architecture to VMS (Dave Cutler from DEC who wrote VMS also single-handedly wrote the first NT kernel), is robust and modern. It's main issue to this point has been the inclusion of the Win32 API. But make no mistake, it is a well-designed, efficient kernel. The original NT design specification was over 1200 pages (there is quite a bit of information and excerpts available on the web). If you really want to get into architectural level discussions, or just peruse many of the thousands of threads on the "big" Win kernel vs. Linux, I suggest browsing the newsgroup alt.os.development for a while.
Re:Can they get serious? (Score:1, Informative)
Right. It's not like they invested HEAVILY in ActiveState... which makes both for Windows. In fact, I think they might have been bought out by MS.
Re:Good step (Score:5, Informative)
Think outside the box...
In Windows we're not limited by piping text from one command to another. We have COM automation today which allows one to instantiate Microsoft Word as an object and issue commands to it. This new scripting/shell will apparently allow for similar automation using native
"Are they going to release command line versions of most of their administrative tools? "
command line version of administrative tools have been available since NT 3.x. For those that don't you can use WSH to automate the task.
"Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it."
Huh? Can you open up the word processor in Star Office and build a document based upon data you pulled from an Oracle query, complete with various layout features from a Unix shell script?
We've been able to do that from the Windows command line for several years now. I don't think you fully understand the scripting capabilities Windows offers.
Re:Cygwin (Score:1, Informative)
Most UNIX'en who have never tried Windows 2k/XP command shell programming are really missing out. Many of the command shell commands are designed to handle the way you do things in the Microsoft world. The way you deal with drive letters, parsing, environment variables, NTFS ACL's, stdio and such. Using cygwin is a step backward, that is unless you are mind-locked into the unix paradigm.
Some people do have some valid points about the command shell being too incomplete. Well, I'd have to agree, but I also think this has been a good thing for me. I'm the type of programmer that see's when shell scripting is at its end and jumps to coding a c binary to do something I need speed or complexity for. I don't use scripting for advanced programming. Using shell scripting for real programming is like using Perl to write a database. It's just silly, and I think a waste of time.
Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format. This is so funny to me. It just goes to show why some people (like E.S.R) don't get change. Its almost like they're funtionally illiterate or something. They just learned a few words, then decided that the rest of the vocabulary wasn't needed.
Get with the program, when changing OS's use the native tools! When in Rome?
Re:What about this one? (Score:3, Informative)
Sounds Like Amiga CLI + REXX of Yore (Score:1, Informative)
Re:Good step (Score:1, Informative)
A key design point about NT is that it's designed from the ground up to work in a networked environment with central, trusted authentication. Which is a total disaster if you plug it directly into a untrusted network.
Unix's model of local authentication + kludges is "better" for a small number of machines or specially trusted systems. However using rsh or ssh does not scale very far.
Re:Cygwin (Score:1, Informative)
They BOUGHT it!
sound familiar????
JoeR
Re:Cygwin (Score:5, Informative)
You've provided a straw man argument in "Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format", and then attempt to categorize Eric S. Raymond and other UNIX or Cygwin users in this light. Cygwin is a tool, part of your arsenal of options in systems administration, and nothing more. The ability to obtain a UNIX-style directory listing is irrelevant compared to the ability to use the same script to accomplish the same thing regardless of software platform.
"Crock of Crap" is the first thing that comes to mind. Bash/tcsh/ksh/psh/etc. are so many light-years ahead of the MS-DOS command line scripting language when it comes to pure functionality and understandability that there it is difficult to know where to begin creating a valid comparison. Using a Bash shell under Cygwin to accomplish systems administration or automation duties on W32 is a sound, rational decision for reducing your time investment when supporting legacy platforms like Microsoft Windows 32-bit stuff. Using Cygwin to be able to provide environmental portability across platforms can be an intelligent, measured decision that can make sense both on a personal level as well as corporate decision-making.
You've made at least one incorrect assumption in this paragraph, and that is that using Cygwin makes DOS scripting unavailable. That is simply not true. Every facility of the MS-DOS command shell is available via a Bash shell in Cygwin. You can call external programs, or even use an MS-DOS batch program to launch a Bash shell. Cygwin gives you more power and flexibility to deal with all the things you wrote of, not less, and in a fully POSIX-compliant environment to boot. Using Cygwin is a giant step forward, that is, unless you are mind-locked into the legacy Microsoft Windows paradigm.
- the command shell being too incomplete... I also think this has been a good thing. [I can see] when shell scripting is at its end and jumps to coding a c binary to do something... Using shell scripting for real programming is like using Perl to write a database. It's just silly
You're entitled to your opinion. I'm a professional systems administrator, not a professional programmer, yet I've used Perl, Python, Bash, Cshell, Visual Basic, Excel scripting, MS-DOS command scripting, TCL, and other languages to automate certain tasks, make my job easier, or provide additional functionality where it was needed. Each tool has its place. I would not use Python to attempt to create a performance-critical OpenGL game, no more than I would use C to write a small daily cron job that mounts a filesystem, copies files, and unmounts the file system. Each tool has its strength. Cygwin and the programs available within that environment allow you to do more and go further with command scripting than MS-DOS command can possibly do. The "jumping off point" to an alternative language is very, very low on W32 MS-DOS scripting. Conversely, the "jumping off" point using a real, powerful command shell is quite high, and allows you to accomplish a great deal without having an enormous knowledge base of various programming languages.The line between "scripting languages" and "programming languages" doesn't exist except at some arbitrary line which differs from programmer to programmer. Whatever language lets you get the job done in the shortest amount of time with the greatest degree of maintainability is probably what you want to pick. I can take my pick of Perl, Python, Bash/csh/ksh/whatever, Java, C, or anything in between to create what I need to get the project complete. Cygwin lets me have that additional flexibility, with the side benefit that I can use the superior command-line tools (grep/awk/sed/uniq, for instance) of a UNIX environment from Windows.
- They just learned a few words, then decided that the rest of the vocabulary wasn't needed.
The world always has a need for the simple, elegant, and practical. I would submit that your analogy is flawed. Allow me to share an analogy of my own. I recently had a choice of transportation to and from work, between daily riding the bus (an hour and fifteen-minute affair each way), or driving my car (45 minutes each way). Now, for many people, the choice is very obvious: Use the option that takes the least amount of time, driving the car. Given only the time data, many would come to the same conclusion, that driving the car takes 1.5 hours per day, while riding the bus takes 2.5 hours per day. This overly simplistic view of the question doesn't nearly cover all the facts, however. Here are some other factors that influence my decision:- My car consumes a gallon of gas every 30 miles. Work is 40 miles away, so I will fill my 10-gallon tank roughly every 3-4 driving days, which will cost me somewhere a bit less than $20 each time
- My work provides me with a parking space ($40 value) or a bus pass ($40) every month.
- I have to pay for maintenance on my car.
- Time spent in the car is time that I cannot do something else: I must be exclusively driving
On balance, I decided to take the bus. The extra time consumed by the bus ride is time that I can sleep, work on my laptop, or read a book, whereas if I were driving that hour and a half would simply be lost to me.How does this relate to the question? Well, I think your perspective on why people use Cygwin and other UNIX-like tools on non-UNIX operating systems is a bit skewed. The native tools may be elegant, powerful, and complete (which would be quite a debatable point on legacy W32 platforms IMHO), but the question lies in the balance. Would using native tools allow you to take that same programming effort and use the same script on another operating system? Would using native tools give those who follow you a proper perspective on how to maintain your programs once you've moved on? Would re-implementing something in a native tool, when one could otherwise just install Cygwin and run the same code that is running elsewhere in the enterprise successfully, be the best use of time and the company's dollars?
Regardless, when using Cygwin you are using the native tools available to you, but just substituting a powerful command shell and scripting language for the severely retarded one that is provided by default on W32. "When in Rome" (or some foreign operating system), they say, do as the Romans do. However, if doing so would compromise system integrity, maintainability, stability, or compatability, then I do whatever I need to to make the system work well, even if it requires using a tool that doesn't quite seem "native".
I do not use Cygwin much myself. I boot to Microsoft Windows to run legacy or gaming applications on my home system, and exclusively use GNU/Linux at work and home otherwise. I do a lot of work with legacy W32 systems at work and am a big fan of "use the right tool for the job", which, to date, has not included installing Cygwin on those machines. However, it has included installing Perl, Python, or TCL as the situation requires; if Cygwin were needed to make something work, I'd use it as just another tool in my box.
Get with the program! When running any OS, use the best tool for the job!
(As a final note, I think it's very interesting that Microsoft has finally acknowledge that their shell is horribly crippled and are working to fix that. I'm not anti-Microsoft, I am pro-GNU/Linux, and am very excited to see them finally addressing the massive wart of a lack of decent systems automation on W32 platforms.)
Re:Cygwin (Score:4, Informative)
http://thinstall.com/docs/index.php?sp=unix_tools
Re:So, we're back to the 60's. (Score:2, Informative)
If there wasn't a 'convert' program, there would be a 'mogrify' command or whatever. And I can still use it in a *generic* way. You can't come up with a GUI which would do all the things I could do on the shell.
It has very much to do with GUI vs. CLI. It has to do with the very simple fact that GUIs can't anticipate every wish a user might have. On the shell, programs don't need to anticipate anything because the user can glue things together himself.
Copy of AppleScript (Score:2, Informative)
Re:Cygwin (Score:1, Informative)
I am continually shocked and dismayed to see people write test cases, install scripts, and other random hackery using the csh. Lack of proficiency in the Bourne shell has been known to cause errors in /etc/rc
and .cronrc files, which is a problem, because you *must* write these files
in that language.
The csh is seductive because the conditionals are more C-like, so the path of least resistance is chosen and a csh script is written. Sadly, this is a lost cause, and the programmer seldom even realizes it, even when they find that many simple things they wish to do range from cumbersome to impossible in the csh.
The most common problem encountered in csh programming is that you can't do file-descriptor manipulation. All you are able to do is redirect stdin, or stdout, or dup stderr into stdout. Bourne-compatible shells offer you an abundance of more exotic possibilities.
The csh is a horrid botch with its built-ins. You can't put them together in many reasonable ways.
In the csh, all you can do with signals is trap SIGINT. In the Bourne shell, you can trap any signal, or the end-of-program exit.
You can't quote things reasonably in the csh: set foo = "Bill asked, \"How's tricks?\"" doesn't work. This makes it really hard to construct strings with mixed quotes in them. In the Bourne shell, this works just fine.
There's this big difference between global (environment) and local (shell) variables. In csh, you use a totally different syntax to set one from the other.
Wouldn't it be nice to know you had an error in your script before you ran it? That's what the -n flag is for: just check the syntax. This is especially good to make sure seldom taken segments of code code are correct. Alas, the csh implementation of this doesn't work.
While some vendors have fixed some of the csh's bugs (the tcsh also does much better here), many have added new ones. Most of its problems can never be solved because they're not actually bugs per se, but rather the direct consequences of braindead design decisions. It's inherently flawed.
Do yourself a favor, and if you *have* to write a shell script, do it in the Bourne shell. It's on every UNIX system out there. However, behavior can vary. There are other possibilities.
The Korn shell is the preferred programming shell by many sh addicts, but it still suffers from inherent problems in the Bourne shell's design, such as parsing and evaluation horrors. The Korn shell or its public-domain clones and supersets (like bash) aren't quite so ubiquitous as sh, so it probably wouldn't be wise to write a sharchive in them that you post to the net. When 1003.2 becomes a real standard that companies are forced to adhere to, then we'll be in much better shape. Until then, we'll be stuck with bug-incompatible versions of the sh lying about.
The Plan 9 shell, rc, is much cleaner in its parsing and evaluation; it is not widely available, so you'd be significantly sacrificing portability. No vendor is shipping it yet.
If you don't have to use a shell, but just want an interpreted language, many other free possibilities present themselves, like Perl, REXX, TCL, Scheme, or Python. Of these, Perl is probably the most widely available on UNIX (and many other) systems and certainly comes with the most extensive UNIX interface. Increasing numbers vendors ship Perl with their standard systems.
If you have a problem that would ordinarily use sed or awk or sh, but it exceeds their capabilities or must run a little faster, and you don't want to write the silly thing in C, then Perl may be for you. You can get at networking functions, binary data, and most of the C library. There are also translators to turn your sed and awk scripts into Perl scripts, as well as a symbolic debugger. Tchrist's personal rule of thumb is that if it's the size that fits in a Makefile, it gets written in the Bourne shell, but anything bigger gets written in Perl.
-Tom.