Yes, because, of course, nobody ever saves their command-line stuff to a file in Linux. I always do, unless it's a one-off. Hence, the net effect is the same.
No, the net effect is not the same because at no point can your program interpolate variables or pipes directly from the system shell. You have to write a custom-hack for everything, or rely on some obtuse API that programmers should have no business memorizing
You can't just throw a command to the shell saying "get me the login time corrisponding to the third user in the logged-in list" and assign it to a variable (in 1 line) - even if you could - not without learning an API.
It's an API that only works on Microsoft systems; an API that takes up room in your brain; an API that they want to sell you books to learn about, and upgrade certificates for.
Does any of this make you feel like a complete tool, or do you enjoy all the hassle?
Earlier, you asked MS to produce a shell language which would do stuff. You asked them (for some reason) to use the Unix stuff, and then admitted that that would be limiting, and then you made up your own on the spot.
Any shell language MS would produce would, by definition, only work on MS systems. It would take up room in your brain. There would be books about it. I doubt there would be any certification for it, but that's a whole other thing.
None of that makes me feel like a tool, nor is it a hassle. Why? Because I go through the same thing on our VMS systems, our Netware systems and our Linux systems. They each have their own way of doing things which is unique to THAT system, takes up room in
my brain, has books and needs learning.
I don't enjoy the hassle, but unless you are proposing a unified shell environment / language for all OS's, I'm not sure what you're driving at.
Sure, MS could benefit from it, but you get the same benefit if you just use 'type' and then run your little script using KiX. Sure, it's an extra step, but it's an extra step most NT admins don't mind, becuase it's not like we're at the prompt all that often
Sure, I can see the benefit to some more extended commands, but not to the extent that MS is dropping the ball, things aren't doable, etc. The whole "here's how many lines it takes to do this" thing always irks me becuase it's so subjective. There is no "what
if I don't want to write ANY lines" or "what if I want to save that script" or "how about doing that across multiple servers, domains, locations, environments and OS's"...
All of these things are things I do every day as one of 2 Sysadmins in a fairly large company. Not once in my travels have I wished I had access to a commandline, becuase the tools we have work and because I don't see what problem what you're asking for solves.
Show me the problem and I'll be happy to jump onto a solution full force. I'll blog about it, I'll tell people about it and I'll likely even spec out a business case and framework.
But I won't do anything if all I hear is a "I want this because it's how I work in this other OS and MS isn't being cooperative and this is more efficient and..."
Because it doesn't get me anywhere. It doesn't move me forward. It doesn't tell me why your solution is better. It just says "here's how I want you to do it".
I know I'm being overly ... cutting, but I'm sick. My apologies, honestly. I'm not normally such a hardass.
When did I ask for a 'shell language'? As I recall I was referring to a shell.
There are 101 languages that use the shell, but what good is it (like Kix) if the shell can't interpolate variables with said language?
All I asked for was more information about MSH, which sounds promising.
"grep, sed, awk, blat, cat, fork, tcpdump, top, w, ps, du" have been ported, but the shell still doesn't let you interplate their output - making them useless in a windows environment. The whole reason for writing those generic utilities is so that you can
pass their output easily around to other each other.
With CMD, one still has to parse the output via hacks like getLoginTime(user), or do it through someone else's hack, namely an API (System.whatever.whatever.getLoginTime(user) ).
commands like 'net' are sweet. Commands like 'msconv' would also be sweet additions. These are the kinds of utilities that work well in scripting environments - but they
still need a shell that will allow them to be useful.
I wasn't just making stuff up on the spot...
I'm standing by my tool comment though. Anyone who goes the Microsoft route is asking to be used, upgraded, certified, and otherwise hassled. The only reason I know C# is because it's damn near identicle to Java (Microsoft agrees: "C#
for Java Developers") and I have faith in the Mono project.
You wouldn't need an API to talk to the registry if you were smart enough not to need a registry in the first place.
All those people who used Visual C++ wasted time. How many people wasted a small piece of life learning what a
tChar was? Microsoft is in the habbit (because of poor design choices, or because they like perpetually forcing people to buy newer books) of abandoning previously lauded technology. Anyone remember WindowsCE, VisualFox Pro, J++, DOS, or BOB?
And by the way, the *nix environments are so good that they STILL rely on a shell. They didn't have to abandon it, and hack a solution beause it stopped working. Which means they didn't have to build yet-another-API.
So either 1 of 2 things is happening.
1) Microsoft doesn't want all your money and I'm an insensitive clod who hates Microsoft no matter what
2) Microsoft always tried to do the right thing design-wise when they see the chance, and would never try to take advantage of its large developer following
I peronsally look at the following evidence and I leave the conclusion to you:
1) The Kernel: Microsoft bought the DOS kernel. They didn't even design it originally. They hacked it together and windows wasn't even an operating system (it was a GUI for DOS) until the NT4 kernel came out in the 90's (over 20 years after they began). Proof:
Windows relied on DOS memory management until windows 95, and even until Windows Millenium Edition, Windows included DOS. Microsoft said WinME would be the last version "based upon the DOS kernel". WindowsME was released 25 years after the company began.
2) The shell - it hasn't ever supported varaible interpolation. The only options it chose to support were tokenizing (because it's impossible to have a shell that can't tokenize) and PIPES (which was an idea invented by Doug McIlroy - a UNIX pioneer). Not even
a way to kill or view running processes from the command line - until present day 3rd party developers created a way to do so.
3) Pollution of a platform independent language (ala J++).
4) Certification products (read $$$) from administrators & developers:
MCSA/MCSE, Self-Paced Training Kit (Exam 70-290): Managing and Maintaining a Microsoft Windows Server 2003 Environment (MCSE Training Kit Series)
MCAD/MCSE/MCDBA Self-Paced Training Kit: Microsoft SQL Server 2000 Database Design and Implementation, Exam 70-229, Second Edition
MCSA/MCSE Self-Paced Training Kit (Exam 70-284): Implementing and Managing Microsoft Exchange Server 2003
MCSE Self-Paced Training Kit: Microsoft Windows 2000 Core Requirements, Second Edition, Exams 70-210, 70-215, 70-216, 70-217
MCSA/MCSE Self Paced Training Kit (Exam 70-291): Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (MCSE Training Kit Series)
MCSE Training Kit (Exam 70-227):: Microsoft Internet Security and Acceleration Server 2000
MCSA Self-Paced Training Kit: Microsoft Windows 2000 Core Requirements: Exams 70-210, 70-215, 70-216, and 70-218, Second Edition
Microsoft Press Programmer's Bookshelf for Windows 95
ALS Network + Certification
MCSE Self-Paced Training Kit (Exam 70-294): Planning, Implementing, and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure
MCSA/MCSE Managing a Microsoft Windows 2000 Network Environment Readiness Review;Exam 70-218
and I could go on for days listing things Microsoft wants you to buy for their certification schemes.
Collect em' all! GET THE COMPLETE BOX SET! IT'LL MAKE YOU SMARTER!
... no... it makes you a TOOL.
With unix, when they change a technology it's only so that the technology will work better with everything else around it - with microsoft it's the opposite - it's an excuse to get you to adopt their proprietary technology and buy more books, pay for more certifications
etc etc etc.
That's why Unix rules.
I too am sorry for being a hardass, but I hate to see good guys like you wasting their life supporting a cause that just wants to take advantage of you, your creativity, your time, your money and your brain power.
I'm not going to respond, only because I'm more sick that I was earlier.
Just to say that I do believe in certification, but haven't gone after MS certs yet. I know you aren't really railing against certification, and I do understand where you're coming from (on all points).
Yeah, a more appropriate shell would be great, and I can see how it would solve issues for you coming froma Unix environment...
But I don't see how it solves issues for me
Feel free to convince me though, I'm not nearly in as grumpy of a mood as I was last night
did you mean sick as in... bodily sick, or sick to your stomach from the rant?
Well hey man, I hope you feel better. Get robust soon
I don't like how commercial certs are, but I don't throw it out all together. On the other hand, if I had to pay money to prove every program I was good at - and if I had to 'upgrade' those certifications every few years, I'de be very very poor.
take care dude
A good debate (heck, a good argument) is something I enjoy. Just a touch tired is all.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.