Evolution of shells in Linux (developerWorks)

Posted Dec 10, 2011 3:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
In reply to: Evolution of shells in Linux (developerWorks) by ccchips
Parent article: Evolution of shells in Linux (developerWorks)

>Their object model is still very weak; for instance, try to use their own tools to get the last logon date for an Active Directory user.
Easy:
>Get-AdUser -Filter * | Format-Table LastLogon,UserPrincipalName

You'll get a list of last login timestamps and users names.

You can argue that PowerShell does not yet cover all possible functionality, but it's not a deficiency of the idea itself. Just a sign or relative youth.

Relative youth?

Posted Dec 10, 2011 6:45 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

You can argue that PowerShell does not yet cover all possible functionality, but it's not a deficiency of the idea itself. Just a sign or relative youth.

Nope. It's an Achilles' heel. PowerShell is half-decade old already, so you can not say it's all that young. It's just not a shell replacement, it belongs to a long list of "universal glue languages" (which were rarely all that universal). Besides LISP on the LISP Machines or Oberon on Oberon OS (which is the only examples where "universal languages" were almost fully universal indeed) this list includes things like REXX, AppleScript, VBScript, etc. They are good in their "area of expertise", but please don't try to mix them with shells - because they are not shells despite the hype.

Why? Because they assume programs will offer specialized interfaces just for that one flavor or scripting. But developers of a lot of programs just don't care enough to do that! They may provide some kind of command line switches and/or offer some textual output (because it's easy), but why should they bother to offer all these other things? This is not what they are paid for!

Some programs don't include any scripting support at all (in this case even bash can do nothing), but more often then not they do include some scripting - because their authors need it for development purposes. But it's as minimal as possible, because it's side-show at best. And most such schemes and languages are horrible when they need to interact with programs which don't include nice-structured-interface-of-the-year. PowerShell is not an exception.

Relative youth?

Posted Dec 10, 2011 7:28 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

>Nope. It's an Achilles' heel. PowerShell is half-decade old already, so you can not say it's all that young. It's just not a shell replacement, it belongs to a long list of "universal glue languages" (which were rarely all that universal).

No. It IS the shell replacement. It also is a glue language.

>Why? Because they assume programs will offer specialized interfaces just for that one flavor or scripting. But developers of a lot of programs just don't care enough to do that! They may provide some kind of command line switches and/or offer some textual output (because it's easy),

Sure. And you can work with these programs just fine. It's not going to be as natural as working with native cmdlets, but it's good enough to work with legacy stuff.

For example, PowerShell's git integration is nicer than in bash/zsh and takes only a fraction of code for the similar functionality. See for yourself: https://github.com/dahlbyk/posh-git

>but why should they bother to offer all these other things? This is not what they are paid for!

Because writing a cmdlet is like 10 times easier than writing a command-line utility! It saves time! Especially if you are using .NET (which most large vendors already do at least for some functionality).

And it's already happening - all good software vendors for server-side apps on Windows already expose functionality using PowerShell. Like: VMWare, Amazon Cloud, MSSQL, etc.

It's apples to oranges...

Posted Dec 10, 2011 8:57 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

Because writing a cmdlet is like 10 times easier than writing a command-line utility!

Only if your program uses .NET - which is not always the case. In other cases you first need to write the command-line utility anyway and in addition you need to write the cmdlet. If you write command-line utility anyway then why bother with cmdlet at all?

Especially if you are using .NET (which most large vendors already do at least for some functionality).

Not especially. Only. If you don't use .NET then it's easier to write command-line utility - and while large vendors are prone to misallocation of the resources even Microsoft is ready to scale back this abomination as Windows8 shows. But it'll probably be 10 more years till it's finally dropped...

And it's already happening - all good software vendors for server-side apps on Windows already expose functionality using PowerShell.

s/good/buzzword-compliant/

PowerShell is obvious waste of the resources, but it's not a zero-sum game: most sensible solutions are not the ones which sell well thus sometimes you need to invest in the most buzzword-compliant approach. But it only makes sense if this approach slays buzzword. When it's no longer the case support dries up quite fast. As world becomes less Windows-centric and Windows becomes less .NET-centric it makes less and less sense to spend resources on PowerShell.

People will probably not drop already written things (albeit it may happen later), but new developments... I doubt it.

It's apples to oranges...

Posted Dec 11, 2011 0:07 UTC (Sun) by raven667 (subscriber, #5198) [Link]

Ok, we get it, you don't like (MS, .NET/C#, PowerShell) The idea that MS or the industry in general is moving away from VM style languages is just laughable as is the idea that .NET is an "abomination". We can certainly have a discussion on the merits but this isn't one.

It's apples to oranges...

Posted Dec 11, 2011 0:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>Only if your program uses .NET - which is not always the case. In other cases you first need to write the command-line utility anyway and in addition you need to write the cmdlet. If you write command-line utility anyway then why bother with cmdlet at all?

Nope. VMWare doesn't use .NET but its PowerShell management interface is top-notch. git doesn't use PowerShell but posh-git beats bash_completion in usability.

Have you actually managed something on new Windows Server platforms? Or do you think that Windows Server is still used only for file-servers?

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 16:44 UTC (Mon) by ccchips (subscriber, #3222) [Link] (8 responses)

LastLogon: 129681773131629678
LastLogonTimestamp: 129681773131629678

Quest Software fixed this in their product, which is, fortunately "free beer."

Somehow, I think we've been trolled. Smoke signals?

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 17:27 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Uhm. That's a timestamp in awful ActiveDirectory format. No need for third-party software.

http://msdn.microsoft.com/en-us/library/windows/desktop/m...

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 18:05 UTC (Mon) by ccchips (subscriber, #3222) [Link] (6 responses)

Ah, yes - so I hand the above link to a new system administrator who has to use Powershell, ask him to give me a list of Last Logon Dates for anyone who hasn't logged on in 30 days, and.....then what?

This issue should have been addressed *before* Microsoft releasted the Active Directory tools for Powershell, not after, and not by requiring some kind of conversion kluge.

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 18:31 UTC (Mon) by ccchips (subscriber, #3222) [Link] (5 responses)

Oh, and I did do some research into this. It is possible to do, but I don't find the solution to be any indication of how great Powershell is compared to the other UNIX shells. Yeah, there's a system function to convert this, but again, we're supposed to be making it easier for administrators to do their work, not requiring them to do research into date/time conversions from a "standard" tool.

It is good, as far as I'm soncerned, that Windows system administrators now have a decent shell to work with in their day-to-day activities, and I laud Microsoft for this. In my shop, it has been hard to get administrators to script *anything* before Powershell, as they were not willing to use Perl, Awk, Python, etc. And Powershell does have some interesting innovations. But it still strikes me as odd how a discussion of UNIX shells and their evolution turned into an argument about how great Powershell is compared to all the other methods people have used to perform system administration activities.

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 18:48 UTC (Mon) by raven667 (subscriber, #5198) [Link]

But it still strikes me as odd how a discussion of UNIX shells and their evolution turned into an argument about how great Powershell is compared to all the other methods people have used to perform system administration activities.

Well, it didn't start out that way, there was just one "PowerShell is neat" post and in response a flurry of negative responses were written which lead to a lively discussion.

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 21:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

That's mostly a problem of the tool itself. AD is just braindead in many respects. We just have to live with it.

Samba4 on Linux has the same behavior, btw.

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 21:34 UTC (Mon) by ccchips (subscriber, #3222) [Link] (2 responses)

Interesting.

Does Samba4 or related utility have the fix?

I was a bit surprised to learn about the [System.DateTime]::FromFileTime() function in Powershell. I did a lot of research into this previously and didn't see that.

Evolution of shells in Linux (developerWorks)

Posted Dec 12, 2011 21:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

No. Why should there be a fix?

LastLogon is a valid timestamp, just in a very braindead format (in 100-s nanosecond increments since 1601).

Evolution of shells in Linux (developerWorks)

Posted Dec 13, 2011 16:20 UTC (Tue) by ccchips (subscriber, #3222) [Link]

There should be a fix because people need to use that information, not dig around on the Internet, figure out how braindead the timestamp is, and come up with a scheme to read it in human-readable form. Quest Software fixed it by providing a conversion method.

I was asking about fixing *accessibility to the information.* Which is far more important to me than what shell handles what arguments, and how the pipelines work.