Recent Features
| |||||||||||||
Evolution of shells in Linux (developerWorks)Evolution of shells in Linux (developerWorks)Posted Dec 8, 2011 15:01 UTC (Thu) by ccchips (guest, #3222)In reply to: Evolution of shells in Linux (developerWorks) by Cyberax Parent article: Evolution of shells in Linux (developerWorks)
No, it isn't. It's different. It's sort of a polyglot (some Perl, some Python, some bash, object pipelines instead of text pipelines.
I think they have some good ideas, but it has many deficiencies; for example, you have to go "around the block" to get byte-stream-oriented input redirection; it doesn't integrate well with *existing* tools that use text-based output. "cmndlet" B may not be dependent on the byte-stream output format of cmdlet A, but it *is* dependent on cmdlet A's object definitions. 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.
They have problems with directory management. They don't have a working "du" type tool that produces objects as output, and the workarounds they do have barf if the paths are too long. They pride themselves on ease-of-discuvery, but try to discover all those .net classes without going on the Web to look up the objects and their meanings.
On the other hand, when the object model does work, it's very easy to get things done, and you can count on data formats between pipeline elements.
I enjoy working with Powershell, but I also enjoy working with Bash, Perl, Python, and several other tools. I'd like to see a working Powershell implementation in the *nix world, or if nothing else, some interest in object-oriented (or mixed) pipelines.
(Log in to post comments)
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 15:20 UTC (Thu) by felixfix (subscriber, #242) [Link]
Every once in a while I come across some program that spits out several lines per record, and wished there were some way to use it in a pipeline. What it needs is some way to group lines into single lines and break them apart again, and two new pipeline utilities come to mind. The collector would group input lines based on command line criteria, such as a count or a pattern, and print them as a single line formatted per more command line args. The splitter would split each input line into several lines based on similar command line args.
Then programs which print several lines per record could be used with pipelines. It wouldn't be perfect, but all it would take is the two utilities, which I am, alas, too lazy and/or uninspired to write. The problem comes up too seldom to take the time to write it, and I have always found simple work arounds.
Evolution of shells in Linux (developerWorks) Posted Dec 9, 2011 0:32 UTC (Fri) by wahern (subscriber, #37304) [Link]
You mean cut(1), paste(1), and join(1)?
They can be rather awkward to use, but I believe do what you want.
Evolution of shells in Linux (developerWorks) Posted Dec 9, 2011 5:03 UTC (Fri) by jthill (guest, #56558) [Link] sed does exactly what you want. For instance, to accumulate aptitude show's output one package per line:sed -nr '/^Package:/!{H;$!d};x;s/\n/\x0/gp'
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 17:05 UTC (Thu) by ccchips (guest, #3222) [Link]
I just encountered another serious (in my opinion) deficiency in Powershell.
I have a "cron job" (scheduled task) and I want the job to send *all* the output to a text file, *including* all error messages. The only way I could track down an error in my script was to run it from the console and read the error message (in red) from the screen.
Not good.
This is just one example where a potentially very powerful shell fails in critical situations. Object model or no, the Powershell team should *pay attention* to the needs of system administrators everywhere, not just the point-and-click/read the screen types.
And there's no good reason why migrating Bash users should have to go around the block several times to do things that have been extremely simple for years:
foo <bar.txt >result.txt
vs.
get-content....blablabla....out-file....
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 19:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>I have a "cron job" (scheduled task) and I want the job to send *all* the output to a text file, *including* all error messages. The only way I could track down an error in my script was to run it from the console and read the error message (in red) from the screen.
Uhm. PowerShell supports standard text redirection. What exactly do you need?
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 20:41 UTC (Thu) by ccchips (guest, #3222) [Link]
I need the equivalent of:
foo >bar 2>&1
to have *every* text line from standard output and *every* error line that would sho up in red on the screen, as the result of the above command.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 20:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
You'd be surprised, but the equivalent of "foo >bar 2>&1" in PowerShell is:
> foo >bar 2>&1
Yep. It works just as in Unix.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 20:59 UTC (Thu) by ccchips (guest, #3222) [Link]
Ok, well I just tried "2>&1" on that job and it worked. Stupid me. I was looking for instructions rather than experimenting.
However, I did find a different problem; things go really wrong if you try something like this:
dir | get-content
because "get-content" takes a list of objects from the input pipe that are interpreted as file names.
Still, my first problem is solved, I have egg on my face, and so it goes. I never said I didn't like Powershell--I enjoy working with all of the common shells (except maybe MS-DOS Command prompt) and would like to see Powershell be more easily integrated with existing tools.
I suspect there is a way to get "dir | get-content" to act more like UNIX shells would, but we could argue all day about the merits.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:59 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
> Uhm. PowerShell supports standard text redirection.
What do you think this PowerShell pipeline puts into foo.txt?
echo hello > foo.txt
If you guessed ASCII "hello" or "hello\n" or "hello\r\n", you'd be wrong. Horribly wrong.
PowerShell converts everything to UTF-16-LE, prepends a BOM, and puts the result in foo.txt. This behavior is almost too horrible for works. PowerShell even mangles the output of *native* programs, e.g.
ipconfig > ipconfig-out.txt
In cmd, ipconfig-out.txt contains ASCII. When the same pipeline is run in PowerShell, it's UTF-16-LE-with-BOM. This encoding is more verbose, less commonly supported, and (because of the BOM) far less friendly to splicing and concatenation. This behavior is just awful.
As a lemma, PoewrShell will also mangle the output of programs that produce non-text output: consider
ps2pdf < foo.ps > foo.pdf
foo.pdf will take each "line" of ps2pdf output, convert it to UTF-16 as best it can, then dump the result in foo.pdf. The result looks like a PDF sent through a meat grinder.
(Don't tell me you're supposed to use some cmdlet for doing the conversion: the point of a shell is to work with existing programs. If I wanted to use a library, I'd use a different programming language.)
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 22:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
That's the way Windows works. Sorry.
You can change default encoding to UTF-8 with "$OutputEncoding = New-Object -typename System.Text.UTF8Encoding". Binary mode is more tricky, you have to add "-encoding byte" everywhere.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 22:27 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
> That's the way Windows works. Sorry.
Thus my original point: I'll consider using PowerShell only after the critical issues I've identified are fixed. Until then, Unix shells (even running under Cygwin) are superior by far.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 22:51 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Windows exists in a parallel universe where at some moment soon a great wizard will appear and banish everything outside the Basic Multilingual Plane so that they can go back to UCS-2 where things were simpler (yet conveniently incompatible with stodgy old Unix).
People who are never going to be happy about LLP64, UTF-16, or various other arbitrary yet defensible differences from Unix will never be comfortable on Windows. This isn't even a religious war, it's some fundamental cultural difference just like the relationship between directions and time.
For me "bringing forward" a meeting will always make it sooner, and UTF-8 will always be the more intuitive and sensible encoding. So no Windows for me.
Evolution of shells in Linux (developerWorks) Posted Dec 10, 2011 3:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>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] 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]
>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] 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 (guest, #3222) [Link]
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]
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 (guest, #3222) [Link]
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 (guest, #3222) [Link]
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]
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 (guest, #3222) [Link]
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]
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 (guest, #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.
|
|||||||||||||