| |||||||||||||
Evolution of shells in Linux (developerWorks)Evolution of shells in Linux (developerWorks)Posted Dec 8, 2011 17:05 UTC (Thu) by ccchips (guest, #3222)In reply to: Evolution of shells in Linux (developerWorks) by ccchips Parent article: Evolution of shells in Linux (developerWorks)
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....
(Log in to post comments)
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.
|
|||||||||||||