Hacker News Reader

Comment by jpk | Hacker News Reader

I find PowerShell a delight to script in, but terribly cumbersome to use interactively. The exact opposite is true for me when it comes to Unixy shells. I think part of the staying power (whether intentional or not) of composition via character streams is that in a text-based environment, humans also operate on character streams. We can structure things in machine memory as objects or lists or whatever, but when the information hits our meat cameras it's all just characters. When I run a command, the output I see is what I'll get when I pipe it somewhere.

I feel like PowerShell is a step forward in the sense that it's a new thing with a more consistent design than the cobbled, creaky Unix environments we've become accustomed to. But at the same time I feel like it throws away one of the most intuitive aspects of the Unix interactive shells (character streams).

View on HN

> I find PowerShell a delight to script in, but terribly cumbersome to use interactively.

That's because you can't be both! The shell wants to be both an API and a user interface, and these are two goals that are fundamentally at odds. An API should be structured, strongly-typed, unforgiving; a UI should be discoverable, intuitive and unconstrained by the needs for automation or programmability. Programmers are stuck in the idea that a command-line shell running in a terminal emulator (emulating hardware from the 70's) is the pinnacle of interaction design, which is extremely sad.

Couldn't there be a middle ground where command and object member names have nice short aliases, but they work on and produce objects instead of character streams? I find it questionable that the productivity of the unix shell is due to it being stream-only - it could easily fall back to a stream (using each classes representation function) if you output it to a stream receiver, like the terminal itself or a text file.

That's what I'd like to see, is to add a "--xml" or "--json" flags to any common command (such as ps, ls, grep, find, ...). And have appropriate handling in the shell for xml or json output.

Many FreeBSD utilities support a --libxo flag that produces structured output, although there isn't special handling in shells yet.

    % ls --libxo json
    {"__version": "1", "file-information": {"directory":[{"entry": [{"name":"bar"}, {"name":"foo"}]}]}
    }
    % ls --libxo xml  
    <file-information __version="1"><directory><entry><name>bar</name></entry><entry><name>foo</name></entry></directory></file-information>

Well I haven't really used PowerShell, but if it emits objects, can those objects not be printed in some form?

Is it not reasonable to think of objects as having a description of some kind. Think of URLs, for example.

    find -iname '*.c'

could emit file:// URLs rather than just filenames. Then anything can unambiguously understand the format of the output.

Yes, all Powershell objects can be cast to string ($strvar = [string]$var) or piped to Out-String.

But 'casting to string' isn't very specific. Does casting to string mean that you always get a unique identifier for the object? Does it mean you always get a dump of the object's contents?

You get a printout of the object - effectively calling its toString() method. Note that this is not a reversible nor standard process.

That's one of the main downsides of object-pipeline systems; in UNIX you can stop and serialise a pipeline to a file, then unserialise later. But you can't do this with object pipelines in Powershell because the objects have to be "live".

PowerShell itself ships with a large XML file that governs how certain types are displayed by default if none of the Format-* cmdlets are used, e.g. FileInfo objects are usually rendered in a table with just the most commonly used properties displayed, which makes the interactive use of Get-ChildItem (Aliases: dir, ls, gci) very similar to ls -l. Explicit piping to Format-Wide, or Format-List will override those defaults (they only apply if no formatting is specified).

Sure, everything can be made into strings at some point, but I've very rarely felt the need to do so in PowerShell (and regularly see on Stack Overflow that it only leads into problems down the (pipe)line if people try).

Reply on news.ycombinator.com