[ygra]

What is a shell for you then? If the defining characteristic is that it's not written in a managed language, well, okay, but I don't think many people share that sentiment.

I have observed the several seconds startup time last with PowerShell v2 or so and that was not the time needed for the CLR to start, but rather PowerShell which was slow to start. v5.1 starts instantly here and the only slow thing about it is my profile, which admittedly does a bunch of things that take time (it's not yet at a point where it's annoying me so much that I edit it, and I can start typing commands during that time anyway (considering that I often spend more time thinking about what to write that's okay)).

[flukus]

> What is a shell for you then?

A way to execute programs. The parent is right, powershell is more like a REPL to execute .net code. It's still no where near as good as a unix environment.

[ygra]

But as long as you only execute programs a script for cmd, bash, PowerShell and a number of other shells looks pretty much the same. In PowerShell executing a program is simply to state the program name (barring spaces in the path for now). You don't have to do something like execute_program(name, args, input_redirection, output_redirection, ...). Well, you can, if you're so inclined, but it's usually unnecessary. Any shell is "just a REPL for a scripting language". Interactive use is one of the tenets of a shell, otherwise it's more a batch processing system, I guess. And just like in other shells the language is one geared towards running commands (cmdlets or external), managing their execution and processing their output. That it works better for general programming than many other shell languages (in my eyes) is a nice bonus.

Heck, running programs is even easier than in most other shells since there's a specific token that stops argument parsing completely which means you don't have to care about quoting at all (an ever-present nightmare at times).

[flukus]

The difference is that windows/PowerShell don't provide the programs that make a she'll useful.

[ygra]

Wow, then I've done a lot of apparently-useless PowerShell work.

I beg to differ, by the way. Different is not the same as »not useful«. It's not a traditional Unix shell and doesn't pretend or want to be. That doesn't make it useless, just different.

[tremon]

It's not a traditional Unix shell and doesn't pretend or want to be.

Except in the sense that it provides aliases for most popular Unix shell commands. They even made their aliases incompatible with other Unices, like every other traditional Unix shell.

[loopykidney]

I agree that powershell is far from useless, but it does feel like there are a lot of cmdlets missing out of the box. It's real easy to end up in Get-WmiObject land for everyday admin tasks.

[ygra]

But WMI is really, really huge. I can understand that there is a bit resistance to providing cmdlet wrappers around every single WMI class, although I think on Windows Server there are a lot more things exposed by default (and I think even more in modules that are not loaded by default).

Also, since PowerShell can work with WMI objects natively it's already close to what a cmdlet can provide.

[vishbar]

Doesn't Bash (or any Unix shell) fail to fit your definition, then? Bash contains an interpreter for a language that, while lightweight, is still a separate interpreted language. In particular commands like cd can't be executed as separate programs.

[useerup]

A shell is so named because it was envisioned as a way to interact with the operating system core (not kernel, the core typically consists of both kernel and userland processes/tools). Core and shell, get it?

A command shell is a shell that uses commands to interact with the operating system, whereas a GUI shell is a shell that uses a graphical user interface to let the user interact with the operating system core (services/tools/processes).

In Unix philosophy, a 'command' is almost synonymous with a 'program', except when it's not. Seems to me that you are stuck in the Unix mindset and refuse to entertain the idea that a "command" could be anything but a program. In fact, the Unix shell commands are already a hybrid concept: Commands can be magical built-in commands (like 'cd'), programs (like 'ls') or script files which will execute in a special surrogate process (a seperate shell process).

However, there is a problem with programs as commands: They are opaque. And because every program is started within it's own process, they are also limited when it comes to extending the shell features. This is why 'cd' is a special command that is not a program.

PowerShell is a fresh take on this: PowerShell commands are still used to interact with the operating system, but they need not be full-blown programs executing in their own process. Hence, PowerShell is in some ways even terser than the traditional sh shells. An example of this is the way that 'cd' is not a magic built-in command. In PowerShell 'Set-Location' (the command for which 'cd' is an alias) is implemented like any other command and packaged in module. Only this module is always distributed with PowerShell.

This approach also has several other advantages (not limited to):

* PowerShell "discovers" the parameters, types, positions of command parameters. It is the shell that performs parameter parsing, position matching and (most importantly) coerces values, e.g. parsing a string as a number when the parameter expects a number. This leads to much higher consistency.

* The shell can generate documentation from the command definition. Not possible with sh shells where you need authored documentation, because the parameter parsing is really the responsibility of each command.

* The shell can generate tab-completion and auto suggestions from the command. Not possible on sh shells where you need authored completion files to support completion. In PowerShell you get documentation and tab-completion even for scripts you write yourself!

* The commands may interact with the shell itself. This is important not just because you can implement commands like 'cd', but because the "shell" may actually be part of an application. A GUI administration tool can actually act as a shell, and commands can control the GUI. A very generic example of this is PowerShell ISE, where commands can actually open new windows/panes, change menus etc.

> The parent is right, powershell is more like a REPL to execute .net code.

Wrong. PowerShell is a REPL (i.e. a command shell) to execute PowerShell commands. PowerShell commands may be cmdlets but may also be programs. PowerShell may be implemented in .NET, but PowerShell scripts are not .NET code.

[flukus]

Yes, I'm aware of all the selling points. They even sound great in theory. In practice though, PowerShell is nowhere near as easy as a UNIX environment.

[pjmlp]

Says the one that never used a Xerox PARC like OS in anger.

A GUI workstation using a REPL for scripting/automatic is so much powerful than a plain UNIX shell.

[raverbashing]

Type program.exe in powershell, it runs

Fits the definition for me