I didn’t mean to suggest that a c# program CANNOT take output, parse it, feed it to something else. Obviously it can. The difference is that scripting environments/languages are designed with this as a regular task. So it takes a lot less coding to actually *do* it. Also, you can do it interactively – type out your command, hit enter, watch it run. No compile step.

I’m certainly not saying CLI should replace GUI. Both have their place. But I would be very loathe to administer any OS which provided no CLI at all! No matter how many features it has, there will always be something we need to do today, for which that exact feature has not been implemented yet, and a compiled language with an IDE is overkill.

To respond to your other points would just be a repeat of what I already said, so … nahh.

I don’t understand why you think a C# program shouldn’t be able to take the output of another program as its input, though. We do this all the time.

I think that GUIs are “more human” because they are easier to handle for humans. If you want to talk to a computer using PowerShell, you have to invest a considerable amount of time first. If you want to talk to a computer in binary code, you have to invest even more time, but it costs the computer less time to process it. GUI’s are more advanced user interfaces and that’s why computers need a considerable amount of time to process this kind of input. The next generation of user interfaces will cost even more processing time, but they will also mean less work for humans. That’s what I meant.

I beleive that there are a lot of cases where, if you built up a GUI that could do everything a scripting interface allows, you would have something so byzantine and baroque that simple tasks would be difficult to accomplish – especially for those who are less experienced in the sysadmin craft.

I fully agree that you should have a base understanding of how the underlying tech works, and you should be able to visualize what is that you want your script/GUI actions to accomplish (and how the technology building blocks will go about making it happen) *before* you begin typing or mousing your way through telling the system to do the task.

But with a complex scripting language *or* GUI, and a full understanding of what it is you want to accomplish, there will probably still be points where you need to stop and think about syntactical issues, or look up the syntax. With a checkbox in a GUI – does that checkbox add the property, or remove it? Press the HELP button to find out!

I find it is handy to have two CMD/PS windows open – one for the script I am writing or commands I am entering, another for running help commands to see the syntax of the command I am about to enter. If you only have one cmd window, you can type out half a command from memory, then be staring at the blinking cursor, wondering about syntax of the next clause in your statement. This is partly why some people have a perception of the CLI as being less productive than the GUI, where you have more in view – and where help buttons pop new windows.

You tossed off the idea that any programming language can aqccomplish the same sorts of automation that scripting can. Again, I beg to differ. Shell activities, where your script needs to run various programs, parse their output into something another program can use, then perhaps parse the output of that – these are fundamentally different than the sort of programing you’d do in c# or some similar language, where most or all of the time, the universe of interaction is *within* the program doing the work.

Finally, the idea that the GUI is “more human.” Well, doesn’t this depend on the human? Some folks love their GUIs – but others feel more comfortable at a command line. I don’t think that GUI = one size fits all. Same is true for CLI. Having both worlds available makes me more comfortable as an admin, not less. Although at the ned of the day, when I need a succinct and authoritative way of documenting the actions I have performed, I would prefer writing out the CLI commands as opposed to a long document full of ‘click Next. Now click the Advanced button on the window labelled Foo, scroll the list and …’ (you get the point, I hope).

I could go on about this at length, but I’ll end here. Thanks for a thought-provoking article.

My long reply to a long reply was getting a bit…long, so I thought I’d move it here. Much easier to do the editing in Live Writer anyhow.
You can find the original article and several comments from myself and the author at this blog pos…

Aaron, why do you think that GUI tools are more prone to mistakes?

All in all, I think working on the command prompt, PowerShell or CMD, is a step back. I am looking forward to far more advanced graphical interfaces like Microsoft surface, 3D interfaces or maybe even with VR (virtual reality). Talking to a computer on the command prompt seems to be quite old-fashioned for me.

In most cases, I find I get things done faster via the command line, but I think the best reason for using command lines tools whereever possible is consistency. GUI tools make it too easy to make mistakes.

Good article overall but I have to take exception with two points.

Above you talk about how you can do things faster in bash than in any CLI Windows because the commands are too verbose, or opaque or not robust enough. And you seem to lump PowerShell in with CMD.EXE and that’s what mystifies me.

PowerShell tackles the verbosity issue very well with aliases and shortened parameters. Aliases are self-explanatory. A shortened param is the shortest unique string of a parameter. e.g. “ls -r” is equal to “Get-ChildItem -recurse”. This works because recurse is the only param to that cmdlet which starts with an R. When you have conflicts, you just type as many letters required to make it unique.

The opacity/usability issue and robustness are handled by posh with the built-in help files, tab-completion on parameters, and detailed error objects, and the “-whatif” parameter supported on many cmdlets.

The second statement I disagree with is how you discount scripting because it is either something the vendor should’ve done or something that can be done with any programming language.

I wonder if you are just trying to pick a fight with that one. If so, it worked. As a long time system administrator, I can tell you that most of the time, developers have no clue what sysadmins need. If they knew what we wanted, then maybe they would put that stuff in their app–but maybe not, those sorts of things aren’t very sexy and marketing doesn’t care about that stuff. Besides–who knows what sort of weird combinations of stuff you’ll want to do with umpteen different packages from various vendors. There’s no way my needs can be met perfectly, and why should I wait for someone else to fix it if I have the tools to do so myself?

And programming languages, while they handle the same sorts of tasks as scripting languages, there really core design differences. The focus is on totally different job functions. Besides, why would I design, compile, test, fix, compile, test, etc. a program when I can bolt together modular scripts interactively? Besides, scripting languages are a higher level than most programming languages, and that appeals to sysadmins who do not want or need to learn an API.

I do have to agree with you about servercmd…Obviously the timing did not work out such that they could have done all of what was needed consistently with PowerShell or they would have done that. As it stands, the “everything aside from powershell” CLI functions in windows is sub-par. It’s getting better though.

thanks

Hal, co-host, PowerScripting Podcast