I was reading a topic on SO: Why are scripting languages (e.g. ...) not suitable as shell languages?. Especially I liked the answer by Jörg W Mittag, from which I learned interesting things about Windows PowerShell. So after more than 20 years Windows finally has a well designed shell (Windows 1.0 - 1985, PowerShell stable release - 2009). On other hand Unix systems has a bunch of various shells since 1978 Bourne Shell. I've read some articles about MS job interviewing and I have an impression of very "geekish" company. I am wondering why didn't they had a need for command-line tools compared to Unix people who do all their work with those tools.
-
@JerryCoffin, it probably depends for how long you were in this industry. I'm just starting here so I am quite happy with all this great software which was given for me. There is place for big improvements but it always will be.– SkiOct 15, 2011 at 22:35
-
1Please take the extended, off-topic discussion to chat.– user8Oct 17, 2011 at 19:58
Add a comment
|
9 Answers
The same reason that the iPod, iPhone (any phone for that matter), and the iPad don't: the command line is not the primary channel of user interaction with the computer in Windows. It is in UNIX or GNU/Linux - so that's why they're more mature. Same argument why the linux GUI desktops were rubbish for so long compared to Windows (Mac OS kind of cheats here since they got the unix command line kinda for free).
Maybe I'm oversimplifying, but I think of it as a cultural thing:
- In Microsoft culture, developers focus on writing programs for their users. The programs are all GUI-based.
- In Unix culture, developers focus on writing programs for other developers. The programs are small and focused on doing a specific thing well.
Note that there's no reason that Microsoft can be the only one to write a shell for Windows. The guys who write bash are different from the guys who write *nix kernels. You don't even need root privileges. I've compiled my own shells to use when I didn't like the one the sysadmin installed. If there was a true demand for a better Windows shell, someone would have written one.
answered Oct 15, 2011 at 22:22
Because there has never been enough call for one, I guess.
Windows Scripting Host has been installed as standard since Windows 98 (I assume it was around before that); VBScript was very capable; or you could easily write a command-line tool, which had access to the whole Windows API.
Powershell, put simply, is just another step in the same direction. COM isn't popular any more, so WSH has become quite a learning process. But .NET is the current Big Thing in the Windows world and learning Powershell from a .NET background is relatively easy.
One place I think Powershell has gone wrong though is in trying to appeal to the *nix crowd as well, with all its aliases that make it look like Bash when it clearly isn't.
Apart from the commandline switches, piping is very different in Powershell and is really the first thing you should learn when you pick it up.
And honestly, it is much more like a scripting language, a la Perl, than a shell, a la Bash. There are some serious gotchas if you try to use it as your primary shell.
For example, try doing a simple SVN dump from Powershell. It doesn't handle binary data in stdout very well. On the other hand, manipulating an SVN log is an absolute dream, thanks to its built-in xml type.
-
I do not mind the aliases, but I do not like too many edge cases in its syntax.– JobOct 15, 2011 at 20:56
-
@Job: I have many issues with Powershell, that just seemed the only one pertinent here. That said, there are enough good things about Powershell to make it worth the pain sometimes.– pdrOct 15, 2011 at 21:40
-
+1, having VBScript really eliminated the need for a shell scripting environment in many ways. Oct 16, 2011 at 1:07
-
Another thing is that typical unix IPC is awfully slow and clumsy in Windows. Pipes are worthless there.– SK-logicOct 16, 2011 at 10:08
Because there is little need and much pain in developing a second parallel Windows toolset.
Shells are made powerful through the number and power of helper programs on a GNU system, such as sed, find, xargs et al. Re-implementing these tools is a lot of work, and just building a POSIX compliance layer on top of Windows has proven much easier. Cygwin is such a POSIX compliance layer and provides for most of the needs shell users have when they are forced to use Windows.
I would personally guess that the developer community that is both unwilling to jump the POSIX and Linux bandwagon and still sufficiently devoted to shell programming is so small that it took 20 years to develop a stable shell.
If you consider the Unix shells "decent", then there's been at least one shell for Windows that's been "decent" for decades. The Hamilton C shell is reasonably close to the Unix C shell (though note that the C shell has never had particularly huge market penetration on Unix). Quite a few people have also used JPSoft's various shells (4DOS, 4NT, now called Take Command) for quite some time -- as you can probably guess from the name, 4DOS goes back to the MS-DOS days.
If you insist on a shell distributed by Microsoft, 15 years ago or so the Windows NT Resource kit used to include an NT port of the PD Korn shell1, along with a fair number Unix-ish utilities. It probably didn't include enough to run a lot of shell scripts without modification, but was enough to handle a fair amount of use, especially quite a bit of interactive work.
1In all honesty, I don't know that it was a port of that exact shell, or just something quite similar -- I used it enough to verify that it was as annoying as I remembered Unix shells being, and left it at that.
answered Oct 16, 2011 at 7:24
-
Since we're talking shell "programming" here, wouldn't that need to be "...was enough to handle a fair amount of abuse..."?
:)– sbiOct 16, 2011 at 9:43 -
yay 4DOS - I was really confused the first time i had to use MSFT's default shell after growing up with 4DOS (before switching to Linux and Unixes) good memories ...– johannesOct 16, 2011 at 11:15
This is one of those questions that, ignoring conspiracy theories, probably doesn't have a single answer and is the kind of thing historians could argue about forever without ever finding a definitive answer.
My impression is that the power of the shell is not immediately obvious. I started in on programming in Windows 3.1 and there was very little use of the shell. Everything was done through the Visual C++ IDE, and I never looked at makefiles and DOS batch files were so limited that I rarely tried to use a batch file to automate anything more complicated than a basic backup. None of the Windows focused programming books (I have fond memories of Petzold) I was reading at the time discussed using the Windows shell for anything. It wasn't until I started using and programming Linux that I understood how useful a powerful shell could be. I remember when Windows came out it was so exciting because you didn't have to use old command.com anymore. We finally had a pretty interface with more than one font and multiple programs running at the same time without the need for a TSR...
I think that most programmers who start in Windows just don't have experience with a powerful shell and so, don't feel a pressing need to implement one for Windows. Programmers who work in Linux and appreciate the shell, prefer to work in Linux and so don't feel inclined to spend the time working in an environment they aren't as comfortable in to implement one for Windows, especially considering (as has been pointed out in another question) the need to also implement all the CLI tools that are needed along with the shell itself.
The increasing popularity of Linux is, probably, the main reason that Microsoft finally put a proper shell in. As more and more people realized what a shell is useful for it became more and more clear that Windows was missing an important tool.
Windows has design features that do not lend themselves to scripting. This is a result of making the graphical interface the primary mode of operation. Many tools do not have functional command line interfaces. Without a decent command line interface it is very difficult to generate a good shell.
Often things that need to be scripted in Windows require mouse clicks and key strokes to be simulated at various locations on an applications window. The resulting scripts can be quite fragile. Describing where to script in a command language is not a trivial exercise as the relevant geometry is not readily available.
Windows also did not have a functional piping mechanism in early versions. As it was described to be, the first process would run and its output would be saved to a temporary file. That file would be used as input to the next command. This could be disk intensive and would fail if sufficient temporary space was no available. Unix pipes pass the data in memory and schedule the processes in a manner that minimizes delays.
When it was launched, in 1993, Windows NT was a move by MS into the space previously occupied by Unix servers and at the time a big deal was made about POSIX compatibility and portability. But it didn't quite do the job - instead its users were more the desktop crowd using better hardware (these were the days when a 486dx 50MHz with 32MB of RAM was close to the top end) and wanting a better OS. But they weren't interested in shells, so that all slipped. By the time of Windows Server 2000, which was a second serious attempt to crack this market I think MS had realised they were weak on the shell side - as admins love shell scripts - but even then it took them some time to scratch the itch.
