Imagining the CLI For the Modern Machine

scc writes "TermKit is a re-think of the storied Unix terminal, where human views, input and data pipes are separated. Output viewers render any kind of data usefully. It may not be a new idea, but it's certainly a new take on it." I know you are quite comfortable in your shell of old, but this sort of thing sure gets my juices going. The best of both worlds.

Comments

PowerShell

[Anonymous Coward]

Windows PowerShell beats all.

Re:PowerShell

[Anonymous Coward]

Actually, this is quite straightforward copy of PowerShell. It looks like they ported Microsoft PowerShell to Mac. Fantastic.

Re:PowerShell

[ClioCJS]

I use 4NT based on 4DOS based on NDOS, so it's a 20+ yr legacy. Too bad nobody else uses it though....

Re:PowerShell

[The Dawn Of Time]

Yup, first thing I thought of reading the summary.

Almost funny, Unixy types taking an idea from Windows. I bet that's a hard one to swallow.

Re:PowerShell

[TooMuchToDo]

After the whole BSD TCP/IP stack swipe, us Mac/Linux guys get some wiggle room ;)

Re:PowerShell

[clang_jangle]

No, there's plenty of copycat software in the *nix world.

But back on topic, I think that to be taken seriously this has to be able to actually replace the console, which of course it can't as it runs in X. If it could do what he's shown with the framebuffer and no xserver it'd be more exciting, at least to me. Implement it as a real shell, so I can edit inittab and use on one or more ttys. I'd be impressed then. :)

Re:PowerShell

[19thNervousBreakdown]

I'm not always grepping for filenames. In fact, that's one of the least frequent things I grep for: I can do ls *blah* just fine. But maybe I don't want to fuck around with some syntax I'll only use once every four years, I just want all the files modified in 1997: ls -l | grep 1997. Yeah, that's not suitable for usage in a script, but it's easy, so if I'm not looking for a general, reusable, bullet-proof "solution" and am just looking for output, it's quick as hell.

The examples, while pretty, are ridiculous. If I want to display an image, I can open it in my GUI. If it's actually a common enough operation, I'll write a quick script so I can make it pop up by typing something: showimage blah.png. This, like powershell, forgets that CLIs are user interfaces, and tries to force a bunch of "correctness" that we don't need on us. If it needs to handle weird filenames with newlines and shit in them--here's the critical part that the author is missing--I'll use something stronger than bash. You don't need to use the same interpreter as your scripting language as you do to hack around in a CLI. As for piping from HTTP? Uh, sure, that's neat, but I've literally never needed to do it outside of a script, where the consideration is correctness rather than being easy to remember and quick to type. For regular usage, downloading a file is a wget away.

And why do we need an entirely new UI to fix things like -r and -R? Couldn't you just fix them independently with a small, testable, revertable-if-it-causes-problems patch? Maybe I'm just an old codger, but I don't get this. If you want to separate data handling from UI, separate them, don't try to mash them together into some abortion that's good at neither. Additional standard file descriptors for data exchange? Great, go nuts. Additional standard file descriptors for user frontends? Love it. Re-purposing FD{0,1,2}? You must be high.

Re:PowerShell

[Dog-Cow]

Well, natively, it runs in Cocoa, not X. And part of his premise is that we have graphical terminals that aren't limited to text. Assuming graphical capabilities is a very large part of his point.

And if someone ports WebKit to the terminal, his code will run there just fine.

Re:PowerShell

[EvanED]

That's not really fair on two points. First, TermKit combines two different "re"-envisionings of the shell. The first is object-piping. That is very Powershellish, though TermKit does things in a rather different manner behind the scenes. The changes have a few different tradeoffs which I'm not sure I fully appreciate.

The second part though is moving beyond a text interface, and Powershell really doesn't do this. There is a new terminal built around PS called POSH that is moving in this direction, but TermKit seems to take it even further.

In short, the ideas are not fundamentally new, but very little ever is. There are some specifics that appear to be, and he's actually gotten it working, which is a far cry from almost everyone who came before.

Re:PowerShell

[obarthelemy]

Great memories though. 4DOS under DesqView with QEMM386 was sooo much better than DOS 4.0 ! I remember multitasking WordStar and Lotus 123 with ease !

Then I met Framework and the path was set for Windows...

Re:PowerShell

[The Dawn Of Time]

Oh I don't think there's anything wrong with it myself, although I do have a little issue with the word "swipe" in relation to BSD-licensed code.

Re:PowerShell

[clang_jangle]

Well then it doesn't live up to its billing, does it? I get the distinct impression this is being touted as a "replacement for the tired, old CLI", but if you're on a server, embedded, or other platform where x simply doesn't make sense you'll still be using a real shell.

This is a terminal emulator app, not a "CLI replacement".

But anyway, having used powershell I don't really see the big deal. People go on lengthy diatribes all the time about "the CLI is dead, you're so 1980s" but in reality the CLI is where the power and flexibility live. Powershell brings nothing to the table I can't already get in bash or zsh. I can run fbida and see graphics in the CLI if I want, or use the svgalib driver to watch a video with mplayer. So graphics in the terminal is not a revolutionary concept, and this is nothing but gingerbread, AFAICT.

Re:PowerShell

[gilleain]

If I want to display an image, I can open it in my GUI. If it's actually a common enough operation, I'll write a quick script so I can make it pop up by typing something: showimage blah.png

Indeed; furthermore, on a mac you just need open blah.png and it will open in preview. Or open -a /Applications/MyViewer.app blah.png for some custom viewer.

Re:PowerShell

[ClioCJS]

I still use it for my windows stuff.. but i'm sure there's a lot of stuff it can't do. It still gets updated though. I'm a few version behind because, in case this was not yet obvious, I resist change :)

Re:PowerShell

[fusiongyro]

If you actually read the article, you would know that this is implemented in HTML on top of a small NodeJS HTTP server. There's nothing stopping the backend from being made into an SSL-authenticating web service, and then you can have TermKit shells on remote systems without the remote system having to run a GUI.

I think if you want VT-100 support in this program, you're not the target audience, or you're not seeing the possibilities.

Re:PowerShell

[fusiongyro]

I think you have this all wrong. This is not a terminal emulator app, it is an attempt at creating a novel text-based user interface with a lot of the graphical niceties Mac OS X users are accustomed to. It preserves the REPL-style interaction method but replaces text output with HTML output, and replaces line-of-text input with token input.

The author is not on a mission to wean Unix-lovers like us from our Terminal.app, he's trying to make something like it for our friends who admire the power of Unix but aren't able to commit to it.

Graphics in the terminal as you describe is a fundamentally different thing from what's being attempted here. Yeah, we have Ncurses and we have svgalib, but what we do not have is a set of Unix fundamentals that return graphical output to the command line interface, interleaved with the text of the commands. To do so would probably be impossible; svgalib takes over the whole screen, for example, and with ncurses you are dealing with characters rather than pixels. Think of it more as WebKit interpreting command output as HTML. So while a fair amount of the coding effort so far has been in creating the server and desktop app, as time goes on much more effort is going to be spent on wrapping existing Unix utilities to have them return HTML this thing can use, or developing alternatives to the Unix standbys that are substantially different and more amenable to new users and this interface.

One capability the author talks about wanting is a way to highlight the command line arguments based on their relative safety or syntactic correctness. This will obviously require introducing a lot of additional information that just isn't there by itself, much like completion patterns for bash or zsh.

In short, I think you've completely misunderstood what's going on here, and that's why you're missing the point.

Re:PowerShell

[icebraining]

And 'xdg-open' in most Linux distros.

xdg-open opens a file or URL in the user's preferred application. If a URL is provided the URL will be opened in the user's preferred web browser. If a file is provided the file will be opened in the preferred application for files of that type. xdg-open supports file, ftp, http and https URLs.

Re:PowerShell

[Guy Harris]

TFirst, TermKit combines two different "re"-envisionings of the shell.

Some potential users might find one of those ideas useful (realizing that having command output intended to be parsed by humans or by other commands can result in output that's not as human-readable as you'd like and not as software-parseable as you'd like, a notion that also showed up on LinuXML/XMLTERM and, as noted elsewhere, in PowerShell) and another not (the moving beyond a text interface). The latter doesn't personally interest me; if I want to tweak something from the GUI, there's already GUI code for that - if I want to do command-line stuff, I don't need each command-line token looking like a GUI widget with icons attached to them, I don't need pipe bars looking like big blobs, etc..

Perhaps there's a market for the second part, but I'm not sure what it is. If it helps people who could usefully use a command line learn it, without getting in the way of people not frightened by the command line, then it might be worth the effort.

Re:PowerShell

[mzs]

PowerShell is MPW with added complexity to the objects and data passed around.

Re:PowerShell

[thePowerOfGrayskull]

At first read I thought you wrote "I don't need pipe bars looking like big boobs" and started looking for the download link.

Re:PowerShell

[EvanED]

I've considered the first idea to be basically a no-brainer for some time and hopes it becomes common in the Linux world. I like the second idea, but you're right that it's less compelling. I'm also not enamored with some of the decisions he's made.

But I think looking beyond the standard terminal is something that does not get nearly as much attention. There's a lot of things you could do. For instance, I don't like reading actual text in the terminal, because the default line wrapping sucks and monospace font isn't very good for that task. There's other text formatting you could do as well, like bolds or different sizes or something. So it'd be nice to render that in proportional fonts. Or, from the link, the fact that we do progress bars with ======== is pretty silly.

I think there's a lot you could do to make the Unix CLI more friendly even for experienced users. That said, I'm not sure that TermKit is quite on-target with some of at least its default decisions.

Re:PowerShell

[skids]

Wow, you had the patience to read that whole screed? I couldn't get past the griping about fixed pitch fonts.

Because after all, looking for the one line in a fixed-field-width output stream is SOOO much easier when the columns don't line up anymore just because some ass decided to squeeze the I's and l's together.

Re:PowerShell

[Guy Harris]

I've considered the first idea to be basically a no-brainer for some time and hopes it becomes common in the Linux world.

I hope it becomes common in the UN*X world in general, not just the Linux world; the "commands should produce output that has too little extra columns etc. to be easily human-readable and too little syntactic help to be easily software-parseable" annoyance gets in the way in Solaris and *BSD and Mac OS X and... just as it does on Linux.

For instance, I don't like reading actual text in the terminal, because the default line wrapping sucks and monospace font isn't very good for that task. There's other text formatting you could do as well, like bolds or different sizes or something. So it'd be nice to render that in proportional fonts.

It generally doesn't bother me that much, but I guess if, as long as output that needs to line up vertically can be made to do so, variable-width fonts aren't too bad.

Or, from the link, the fact that we do progress bars with ======== is pretty silly.

Again, that's never really bothered me.

Re:PowerShell

[Cyberax]

"I just want all the files modified in 1997: ls -l | grep 1997"

So? Just do this. File information is transferred as JSON objects, and you can still do simple greps on them.

Re:PowerShell

[Guy Harris]

At first read I thought you wrote "I don't need pipe bars looking like big boobs" and started looking for the download link.

I suspect it wouldn't be that hard to customize TermKit to do that.

Re:PowerShell

[clang_jangle]

In short, I think you've completely misunderstood what's going on here, and that's why you're missing the point.

No, I don't think so... It's interesting, and I'm glad when people look into new and different ways of doing things, but it's doomed because adding yet another layer of abstraction for users to learn is not the way CLI geeks like to work, and everyone else just wants pointy-clicky-shiny and would rather die of festering boils than try to remember the string of text to type in.

I do applaud the effort, and maybe His Steveness will even be sold and replace Terminal.app with it, who knows? Most Apple users have never even seen Temrinal.app anyway, and there's already iTerm for serious CLI geeks using OS X, so it could probably be done. In fact, it sort of fits that the company that brought us AppleScript would do something like this. But as someone who already has zsh it's not very exciting to me at this time. Maybe that will change, but I doubt it.

Re:PowerShell

[Paracelcus]

I once user Quarterdeck's multitasker for my BBS nodes, before moving up to OS/2!

Re:PowerShell

[clang_jangle]

I did read it, and as impressed as you seem to be with "this is implemented in HTML on top of a small NodeJS HTTP server", that really doesn't tell us much. I gather you're not someone who groks the CLI, because you seem to be unclear about what comprises the difference between GUI and CLI environments. The distinction IMO (and probably the opinion of most CLI-centric users) is "this runs in a GUI, therefore it's a terminal emulator". Not vt100, but still a terminal emulator, as in it runs on top of the real interface, the CLI . So it might replace xterm or Terminal.app for some people some day, but it isn't going to revolutionize the CLI as some are thinking.

Re:PowerShell

[19thNervousBreakdown]

What format are dates transferred in? Same as the string that's shown in ls, where the year is shown or not shown based on when the mod date actually is, that requires machine parsing thus negating the entire point of the JSON encoding? No, that would be stupid. So, with time in the same field? Number of seconds since 1/1/1970? UTC? Floating point number of days since 1/1/1970, with 0.0 being noon? Or 12/31/1969 with 0.0 being midnight?

Here, let's do a best-case scenario where it's ISO 8601:

$ ls -l | grep 1997
modDate: "1997-05-02",
modDate: "1997-05-02",
modDate: "1997-05-02",
modDate: "1997-04-20",
modDate: "1997-03-15",

Awesome.

Re:PowerShell

[EvanED]

It generally doesn't bother me that much, but I guess if, as long as output that needs to line up vertically can be made to do so, variable-width fonts aren't too bad.

What I'm thinking is more adaptive... the application should specify how things should be rendered, the terminal should guess when it doesn't, and the user should be easily able to override either decision easily.

I strongly suspect that a program could make a really good guess as to whether to treat as text and render variable-width or treat as characters and render as monospace. There're a lot of hints: how much of the text is in an English dictionary (or other natural language), how much spacing there is between words, where hard line breaks fall, etc.

Re:PowerShell

[Qwertie]

What does this have to do with PowerShell? PS uses an ordinary character grid terminal, same as bash. It processes binary data (.NET objects actually) instead of text, but all user interaction is limited to 16-color fixed-width text. No graphics, no IntelliSense. TermKit is designed around traditional Unix commands and seems to have much loftier usability goals--syntax highlighting for your commands, easier escaping, showing you relevant documentation automatically... I love it. This is what PS should have been.

Re:PowerShell

[UnknownSoldier]

> I use 4NT based on 4DOS based on NDOS, so it's a 20+ yr legacy. Too bad nobody else uses it though....

I'm a big fan of 4DOS/4NT too, but you do realize 4DOS was around _before_ NDOS (Norton Dos). NDOS was a licensed version of 4DOS 4.

http://en.wikipedia.org/wiki/4DOS
"The last version of NDOS was bundled with Norton Utilities 8, and corresponded to 4DOS 4.03."

> Too bad nobody else uses it though....
Yeah, agreed. Bash still sucks in some ways compared to 4DOS/4NT. I miss the directory history popup (Ctrl-PageUp/Dn) I wrote a poormans 17-line bash script which is a replacement for CD. I'll have to post it sometime.

At least you can simulate the cd-up-directory ..{.} functionality in Bash

To move up 1 dir
    function ..() { cd ".." ; }
To move up 2 dirs
    function ...() { .. ; .. ; }
To move up 3 dirs
    function ....() { ... ; .. ; }

Cheers

Grrrr, stupid lameness filter for the bash up() function ....

Re:PowerShell

[ClioCJS]

hehe, i don't know bash at all, i always used zsh under unix, back in the day.

huh. Weird. My memory must be quite imperfect. I seem to remember running NDOS in 1988, but maybe it wasn't til 89 or 90. Weird!

I still use it constantly! I can do almost anything faster than in the point and click way. Except selecting SOME files (via some basis that can't be defined in a regex/wildcard) and dragging them... then gui wins. :/

Cheers.

Re:PowerShell

[TooMuchToDo]

"Swipe" = Used under proper license ;) Although, I argue that the BSD license doesn't even require attribution for use in distributed binaries.

Re:PowerShell

[shutdown -p now]

The first is object-piping. That is very Powershellish

Actually, so far as I can see, it's not really object-piping, but rather just piping of data with an external type metadata so that it can be treated as more than just a stream of bytes. And then there's a proposal to use JSON to pass around structured data (such as "ls") output - but that's still not quite objects.

On the other hand, I do rather like his approach. Especially the separation of "data" and "view" pipes - PS doesn't do that, it's always text (which is to say, a String object) in the end. Also, one other deficiency of PS is that, so far as I know, it doesn't have the concept of streaming objects - you pass around structures, but they're eager, not lazy. This thing still passes binary streams on the lowest level, so apps can stream properly and process data lazily if they deem it worthwhile.

Re:PowerShell

[EvanED]

And then there's a proposal to use JSON to pass around structured data (such as "ls") output - but that's still not quite objects.

I consider JSON to be close enough to objects to fit into that category, though you're right that there are differences. (The one that worries me is the weaker typing, but that's not inherently wrong especially for typical shell pipelines.)

Especially the separation of "data" and "view" pipes - PS doesn't do that, it's always text (which is to say, a String object) in the end

I did notice the separate pipes thing, and I don't know if I appreciate what exactly what he means; I think I'd need to see an example. I'm not sure I like the idea though, if what he means is that a command is going to produce both the text and data outputs, and the receiver just pays attention to whichever one it wants.

Also, one other deficiency of PS is that, so far as I know, it doesn't have the concept of streaming objects - you pass around structures, but they're eager, not lazy. This thing still passes binary streams on the lowest level, so apps can stream properly and process data lazily if they deem it worthwhile.

I'm not sure how PS works in this regard either, though I think calling it eager/lazy isn't quite right. (Can you tell I'm a PL person? :-)) The difference is more whether the commands run concurrently or not: if I say foo | bar, can bar proceed on foo's partial output? (True laziness would be that bar controls execution and foo only ever runs long enough to produce enough data to satisfy bar *right now*, then gets suspended again.)

Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.

Re:PowerShell

[shutdown -p now]

I did notice the separate pipes thing, and I don't know if I appreciate what exactly what he means; I think I'd need to see an example. I'm not sure I like the idea though, if what he means is that a command is going to produce both the text and data outputs, and the receiver just pays attention to whichever one it wants.

So far as I can tell from his description, the "view pipe" cannot be chained - it always goes directly to the terminal. This would be used only for those applications which need interactive user input, or for the formatter in the final step in the pipeline.

The difference is more whether the commands run concurrently or not: if I say foo | bar, can bar proceed on foo's partial output?

Yes, that is what I meant. "Streaming" is probably a more accurate term here.

Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.

When I explored PowerShell, I did not find the ability to write a cmdlet that could do processing on the output of the preceding one in the pipeline before it finished. The input is always an object, and so is an output (collections are objects themselves; text is a single String object). Logically, then, you need the preceding step to complete and return said object so that it can be fed to next step in the line. I didn't find any APIs that would permit streaming.

For text (or rather raw binary) data, as used by plain apps (not cmdlets) - yes, that streams same as it does in cmd.exe. Streams of objects - not so far as I know.

Re:PowerShell

[shutdown -p now]

Apparently, I was wrong about object streaming - it is quite possible, and I'm not sure how I missed it before. I think it's because practically no PS articles actually explain it as a distinct concept, you're kinda supposed to imply that it is there from what they show you.

From what I read so far, the output cmdlet can call WriteObject(), and input cmdlet would get a ProcessRecord() call for every such object written to its input.

I consider JSON to be close enough to objects to fit into that category, though you're right that there are differences. (The one that worries me is the weaker typing, but that's not inherently wrong especially for typical shell pipelines.)

The major difference is that PowerShell pipeline preserves object identities (since all cmdlets run in-process), whereas JSON is just data with no identity other than whatever is stored in that data.

Re:PowerShell

[fusiongyro]

but it's doomed because adding yet another layer of abstraction for users to learn is not the way CLI geeks like to work, and everyone else just wants pointy-clicky-shiny and would rather die of festering boils than try to remember the string of text to type in.

First of all, how exactly can an open source hobby project be "doomed"? Doomed to what, not receiving wide acclaim?

Secondly, it's a false dichotomy between users and you know it. What about all those people using LaunchBar and Quicksilver? They like typing commands and using a Mac, which is a combination you seem to think can't exist. LaunchBar's even commercial software! The truth is that there are lots of users who prefer the keyboard to the mouse but nevertheless find UNIX intimidating. There are also users who like UNIX but wish it were more graphical. Two of my closest friends are a designer and a small business owner, and they both have UNIX servers they have to occasionally do light administration on, and they would both much rather use this if they could. Logging in to a remote Linux box does not automatically open up Vim or Emacs for most people. Most of my compatriots would rather copy the file locally, edit it, and copy it back.

Opening the terminal does not make you an expert at it. There are plenty of people who agree that it is more productive yet still find it hard to use and don't have the time or patience to turn UNIX into their hobby. This program is a very interesting tool because it actually targets them, people who use UNIX without loving it or who simply haven't been corrupted into thinking that the only way is the UNIX way.

If you haven't yet, I hope you'll check out Plan 9 and see that even the authors of UNIX didn't see it with this much absurd reverence. There's no terminal in Plan 9, and the mouse plays a very big role in the interface, yet the very people who gave us shells, terminals, command line editing, "visual" editors and everything else you hold dear, did just fine without them and with having to actually click on things to get work done. The Plan 9 shell has no editing, no history, no curses interface. There's no vi clone, no pager. They were comfortable relying on the GUI to provide those features; they simply did not need all that stuff. It's quite an experience.

Re:PowerShell

[clang_jangle]

The point is that this is being hyped as a CLI replacement. It isn't any such thing. Sorry, I have no interest in the misconceptions, wild tangents, and manifestos you seem to be embracing. But just so you know, plan9 also has a CLI distinct from it's GUI. Sometimes it doesn't work, then you have to know how to use the plan9 CLI. Yes, I *have* used plan9...

Re:PowerShell

[benjymouse]

Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.

"objects/progressive" would be more accurate. Commands of the PowerShell pipeline are not running in separate concurrent processes. Rather, the cmdlets (usually) all run on the same thread within the PowerShell host. Objects are "pushed" through the pipeline in a depth-first manner, i.e. when a cmdlet produces an output object it is immediately pushed into the processing of the following cmdlet.

Some cmdlets (like e.g. group/sort) do not produce output objects until the "end" stage. Cmdlets live through 3 stages: begin, processing, end. When a pipeline is set up the cmdlets are initialized (the "begin" stage) from the last towards the first. During this set-up a cmdlet is allowed to produce output objects as the following cmdlet has already gone through its own begin stage. When all cmdlets are initialized (the first command of the pipeline completed its begin stage), the processing stage is invoked on the first command of the pipeline. This may produce output objects which are then immediately pushed onto the next cmdlet as input. When there are no more "input" objects the process stage ends and the "end" stage is invoked from the first command through the last. During this stage objects may also be produced. As the following cmdlets are still in the "processing" stage the output objects can be safely pushed through the pipeline.

But concurrent it is not.

Re:PowerShell

[Anonymous Coward]

You're very dense, aren't you?

Re:PowerShell

[amliebsch]

In Powershell, it is actually up to the cmdlet to process each object (or "record" in cmdlet parlance) as-it-comes or all-at-once, for obvious reasons; e.g., how could sort-object sort the objects until it has actually been passed all the objects to sort?

Which is to say that it is streaming when it makes sense to be, and not when it doesn't.

Re:PowerShell

[Broolucks]

I just want all the files modified in 1997: ls -l | grep 1997. Yeah, that's not suitable for usage in a script, but it's easy, so if I'm not looking for a general, reusable, bullet-proof "solution" and am just looking for output, it's quick as hell.

There are many, many ways that this could still work. If data is exchanged as JSON, grep could simply be outfitted in such a way that instead of returning lines that match, it returns records that match. For each record, it would try matching the string to all fields, recursively, and if there is a hit, the whole record is returned. I like this idea, if only because I have been known to deliberately cram a lot of information on single, hardly readable lines in the output of my scripts so that I could grep them.

Now, in the eventuality that you would want to use a tool that does not understand these fancy records, I do believe that the tool should still work as it always has (I assume you share the same concern). For this purpose, it would be reasonable to be able to tag programs as either understanding rich data or not. If a program outputs JSON to a program that is not marked as understanding it (by default, programs would be assumed not to support the feature), then the system could refuse to pipe one into the other, unless a *serializer* is provided to convert the JSON into the "normal" terminal output. For instance, the output of "ls" would simply revert to what it has been for the past forever years.

I do not know exactly what TermKit does, I will look into it. Worst comes to worst, I just might fork it and make it behave the way I think it should, if it is not too hard (if only for my own use).

The examples, while pretty, are ridiculous. If I want to display an image, I can open it in my GUI. If it's actually a common enough operation, I'll write a quick script so I can make it pop up by typing something: showimage blah.png.

Well, it doesn't have to be called "cat", but personally, I've always wanted a command that just displays an image directly in my terminal's output stream. I just want to *see* an image, I don't want to open a window (that I would close five seconds later with ctrl+w) and I don't want it to take over my console. I just want the image to be displayed, and my prompt to appear below it, ready to take the next command. Like for instance it would be really nice if "convert ..." displayed the image it created in the output stream. Then I could see it immediately, be like "oh crap, -rotate is clockwise", and fix my mistake immediately, or I could fine tune some parameters, because after every command, I would see the image, and the focus would already be on the prompt. It would save some time - not a whole lot, but it sure would be nice.

This, like powershell, forgets that CLIs are user interfaces, and tries to force a bunch of "correctness" that we don't need on us. If it needs to handle weird filenames with newlines and shit in them--here's the critical part that the author is missing--I'll use something stronger than bash. You don't need to use the same interpreter as your scripting language as you do to hack around in a CLI.

But if you could, why wouldn't you? No tool will be perfect for all jobs, but that doesn't mean we can't get better tools than what we have now. Take "ls -l", for instance. Instead of displaying a list of files in plain text, it could display the exact same information in a sortable table, in essentially the same space. Now, if I wanted to sort files with buttons, I guess I could start a GUI file manager like dolphin or whatever, but if I just want to know what the most recent file is and I forget what the option is, I'd enjoy being able to do it in the little div ls would produce. I wouldn't like to start a file manager, have a window pop up half a second later, do a bunch of clicks, memorize the name of the file, close the window, and type my next command.

I do

Re:PowerShell

[Jaykul]

Yeah, luckily, we've had this sort of graphical console on Windows for years from PoshConsole. http://poshconsole.codeplex.com/

Re:PowerShell

[EvanED]

Thanks for the info. Is the "concurrent it is not" an implementation detail, or is something that they could change without breaking (too many) cmdlets by running them in multiple threads or something like that?

Re:PowerShell

[benjymouse]

Is the "concurrent it is not" an implementation detail, or is something that they could change without breaking (too many) cmdlets by running them in multiple threads or something like that?

That would be an implementation detail. I believe I saw an interview with Jeffrey Snower (principal architect on PowerShell) where he said they were looking into parallel processing. Of course, if the passed objects are not thread safe themselves (or rather the methods/properties of the passed objects), cmdlets which passes on objects but also manipulates them after they have been passed may run into thread issues.

Re:PowerShell

[Anonymous Coward]

The point is that this is being hyped as a CLI replacement. It isn't any such thing. Sorry, I have no interest in the misconceptions, wild tangents, and manifestos you seem to be embracing. But just so you know, plan9 also has a CLI distinct from it's GUI. Sometimes it doesn't work, then you have to know how to use the plan9 CLI. Yes, I *have* used plan9...

Translation: "I don't want it, so it is doomed to fail and should not exist in the first place." Talk about your over-inflated sense of self-importance...

Cool.

[Awkward Engineer]

Everything goes in cycles. From terminal, to personal computer, to cloud. Here's terminal again. - www.awkwardengineer.com

Re:Cool.

[hjf]

Typewriter? Fucking hipster.

Mac only.

[The MAZZTer]

This saddens me, I would so want Windows and Linux ports. There's a brief mention that it should work with a normal web browser, and it appears to use node.js, but I am unsure what exactly to do. I haven't done any coding with node.js.

Re:Mac only.

[The MAZZTer]

Addendum: I think I figured it out. After reading the instructions more carefully I assume there are client and server portions, and it's the client portion that is mac-only, and that a WebKit browser should work there. The server portion is pure node.js stuff and the node.js runtime is cross-platform.

Re:Mac only.

[fusiongyro]

That's my understanding as well. Furthermore, we should be able to take it and run the backend on remote servers with differing OSes.

Repository blocked just as it got popular

[Anonymous Coward]

They took down the TermKit repository for no apparent reason, 'permission denied' when trying to git

Lame

Meh.

[Anonymous Coward]

Doesn't run vim. Mac-only. Lame.

Re:Meh.

[outZider]

The kind of person that loves-vim-long-time is probably not looking for a graphic-enhanced shell, either.

Re:Meh.

[CronoCloud]

Unless they use gvim.

Monad

[Anonymous Coward]

Not to praise M$, but isn't this exactly what the Monad shell for Windows does?

Re:Monad

[Anonymous Coward]

Yes, but it's called Powershell now.

Advantages of CLI

[Ironchew]

The big pros of a command line:
-Very low resource usage
-Automation via scripts

I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing. If you need interactivity, the GUI can handle that. It seems to me like this new interface will suck up too many resources doing something that admins won't be staring at.

But it's worth a shot. ;)

Re:Advantages of CLI

[Alternate Interior]

This looks cool when everything works, but what happens when you try to `cat` a JSON file with a syntax error? Terminal is already lowest common denominator. If you want a better/easier/user-friendlier way, they're out there, but it seems like doing it in the terminal layer is wrong.

Re:Advantages of CLI

[gstoddart]

I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing.

Not so much that I don't have to look at it, as that it lends itself very well to scripting and automation ... automation is good because it removes human error from it. The tools were modular enough that you just build what you needed as you went.

Once it's automated, you don't need to look at it I guess. But, certain kinds of chaining of operations based on the output of the previous stuff ... I still can't find good ways to do that in a purely GUI environment.

I can gin up a couple of shell scripts to do file tree comparisons and get rid of anything which didn't change, ignore anything which wasn't part of the manifest, and write as output a text file which I can use to generate a patch for a remote server. In fact, we did our configuration management for quite some time like this.

I think he's onto something interesting ... and he might be starting to bridge the two, but there are certain tasks that I have yet to find a better way than a series of UNIX command lines and shell scripts. A working knowledge of regexp and sed/grep can make an awful lot of things happen.

Re:Advantages of CLI

[ChienAndalu]

Exactly. I'm all for getting rid of terminfo, termcap, color escape sequences and all that crap, but text is still the best common denominator that works well for humans and programs.

Re:Advantages of CLI

[immakiku]

It's also speedier than the full blown mouse-driven GUI. This retains that one. Also ls/grep for navigating is sometimes better/sometimes worse than folder with icons for navigating. This seems to allow you to mix the two. I think the idea is very nice and can probably be tweaked to make it a viable default CLI.

Re:Advantages of CLI

[im_thatoneguy]

It's not a question of whether or not the command line terminal can do the same things, it still could, it's a question of how you build those terminal scripts.

SQL Queries for instance are pretty obtuse but there are some great tools to help you build them with interactive results.

Why I can't for instance just type ' Move "//path/file.ext" to "//newpath/" instead of mv etc... boggles my mind.

Sure mv is shorter. But why not offer an 'easy' path for those who don't have the shortened commands memorized? Is it really so hard to ignore the "to". It helps people interact with the computer more naturally and it takes an extra 1 second to type. It takes me more than a second to remember mv.

Re:Advantages of CLI

[Mr. Underbridge]

I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing

Some people (like me) prefer it because they can type known commands faster than they can navigate a series of menus. This would be a great addition to currently available terminals for folks like me. I would enjoy the extended graphical capabilities while still being able to type commands.

Note I said 'addition' - I sure as heck want my old-school terminal around at times. The density of text is nice for scrolling back through commands and system output, among other things.

Re:Advantages of CLI

[AchilleTalon]

I think the whole point from the author is to value all these pixels on his screen. That is the rational behind his article. Personnally, I just don't care wasting pixels on my screen as long as the job is done efficiently, what the command line most often does just fine with great flexibility and many options for those with enough knowledge of the Unix shell and all the powertools coming with it.

So, my recommendation to this guy would be to buy himself a cheap dumb ASCII terminal and stop whining about wasting pixels on his screen.

Re:Advantages of CLI

[seifried]

Other advantages are that the CLI works well over serial lines and SSH, especially low bandwidth and/or high latency connections (you can cut and paste a set of commands and just wait for them to return). Graphic interfaces suck really bad over low bandwidth/high latency (mouse jitter, did I click where I meant to click? did it register the click?). Plus the whole automation bit.

Re:Advantages of CLI

[gstoddart]

So, you'd like someone to write a natural language shell where you can describe what you'd like to happen, possibly badly, and the shell would magically know what you mean and do the right thing?

I can imagine such a system either completely failing to do what you wanted, or completely getting it wrong and messing things up ... so far, we're not so good at writing natural languages to tell computers how to do things.

It actually really is hard to just ignore the "to" and assume that you meant to type "move" (as opposed to "more" or "make" or "man") -- I'll settle for the precision of the way things are now over the mostly-kind-sorta way you describe now.

Then again, I've been coding for over 20 years, and have a lot of years of UNIX command line under my belt, and don't find SQL to be all that obtuse.

Re:Advantages of CLI

[EvanED]

I disagree. I view the big pro of a command line is composibility of programs -- and this doesn't do anything to hurt that. (At least once a few equivalents to the standard utilities are built up.) In fact, I personally suspect widespread use of something like this would make it easier to compose, but that would have to wait over time.

And while I don't know if it supports scripts, there's no fundamental reason it couldn't do that either.

Re:Advantages of CLI

[socz]

I also think he's onto something great. I've written scripts to add color to my console and found out after doing it for every program that you can handle that all in a few files. What he's done though, is done that for text and everything else. It looks very promising and I would be willing to give it a go when it's ready.

Re:Advantages of CLI

[gilleain]

So, you'd like someone to write a natural language shell where you can describe what you'd like to happen, possibly badly, and the shell would magically know what you mean and do the right thing?

COMPUTER : ENHANCE!

Also, applescript is where people should go for "move file 'myfile.txt' to directory 'somedirectory'". Ok, so not exactly that syntax, but still.

Re:Advantages of CLI

[camcorder]

How do you plan to i18n that thing than? It's ok for English, and even English might lack form in some phrases. Shell has its own language, and it's not a natural language. Whatever tongue you have, you can learn this language, but if you add natural languages into the equation, then you create a big chaos, since you need to implement syntax differently for vast majority of nations. Otherwise while it wouldn't boggle your mind, it would boggle mind of someone else.

I hope this explains it for your.

Re:Advantages of CLI

[arth1]

Is it really so hard to ignore the "to".

Without breaking millions of existing scripts, yes, it is.

Remember that files and folders may be named to too.
"mv 2 to tutu" means move "2" and "to" into "tutu".

What you need is your own command set, and nothing stops you from making that. Just don't name them the same as existing utilities.

Re:Advantages of CLI

[greed]

Well... What he's describe has been done, somewhat; others have mentioned AppleScript and other more-human-language environments. I'll go down a different path....

The AmigaDOS CLI had named parameters for its commands, completely different from the UNIX positional-and-switch model. So the MOVE syntax was:

Rename From/A/M To=As/A QUIET/S

What that means is:

- From is an argument (/a), that can be used multiple times (/m).
- To is an argument (/a) with an alias (As).
- Quiet is a switch.

If parameters can be inferred from position, the names may be omitted. (So, "to" is mandatory and single, so after QUIET is pulled out of the list, the last item is "to", and everything before it is "from".)

So, you could do a simple:

rename myfile yourfile

Or

rename myfile TO yourfile

Or

rename FROM myfile TO yourfile

Or even

rename TO yourfile FROM myfile

If you had a parameter that was the same name as an argument name, then you HAD to use the named form.

rename FROM from TO to

(Obviously, he'd want an alias setting move=rename, too.)

Re:Advantages of CLI

[Anonymous Coward]

To illustrate this, I've seen Chinese coders who can't speak English for shit but sure do speak code.

Re:Advantages of CLI

[thePowerOfGrayskull]

"Sure mv is shorter. But why not offer an 'easy' path for those who don't have the shortened commands memorized? Is it really so hard to ignore the "to". It helps people interact with the computer more naturally and it takes an extra 1 second to type. It takes me more than a second to remember mv.

But what if your two files are named "move" and "to"? Then you'd have :

move move to to

And that would just be confusing.

Re:Advantages of CLI

[Darinbob]

Best command line was on Lisp Machines. The dividing line between command line and GUI and editor and operating system was very blurry.

Re:Advantages of CLI

[simoncpu was here]

What happens if you want to move multiple files? You'll type it like this:
Move *.htm to /newpath

The shell would then expand it to:
Move file1.htm file2.htm file3.htm to /newpath

This will result in an error because the file "to" doesn't exist (or, if it exists, it will be moved without your permission). If you want to remove ambiguity, the current mv syntax works fine.

Re:Advantages of CLI

[khoonirobo]

Copied from somewhere, but you should get the drift.

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Re:Advantages of CLI

[michael_cain]

Two historical thoughts:

There was a bunch of related research done at Bell Labs (around the same time that UNIX was coming out of the research organization) about command line interfaces. The conclusion was that there were two largely incompatible demands. Beginners wanted verbose languages and menus from which they could pick options. Experts (eg, those who had to use the system for hours every day to do their job) wanted minimalist interfaces that used as few keystrokes as possible.

Many of those early systems were accessed from clunky terminals. Typing on a Model 33 teletype, for example, is something that one does slooooooowly. A few extra characters per command typed really does turn into noticeably less work accomplished per hour or day. Amazing how long things intended to get around the limitations of the hardware can persist.

Re:Advantages of CLI

[Draknor]

That's exactly the point -- why, after 40+ years of computational progress, are we STILL using the lowest common denominator?

Yes, text works - no arguing that, its not going away.
But the point is -- we have these powerful, cryptic CLI systems, or these prettier-but-less-powerful GUIs -- why can't we have both?

The power of the CLI, with a more intuitive, aesthetically-pleasing, GUI sitting on it that doesn't require point'n'click.

Re:Advantages of CLI

[ChienAndalu]

Because then it is not the greatest common denominato. All your other tools want text as input, not those shiny pictures.

Look at the piped commands here: http://www.commandlinefu.com/commands/browse

Tell me how this is supposed to work if there is a picture in the pipe.

Re:Advantages of CLI

[david_thornley]

You'd wind up with something that nobody uses. People have tried that sort of thing before.

Using a common English word instead of an abbreviation sounds like a good idea at first, but it really doesn't buy you anything. That was the idea behind COBOL; while FORTRAN programs said I = I + 1, COBOL programs would say ADD 1 TO I. COBOL's still around, but of the first four big languages (FORTRAN, ALGOL, COBOL, Lisp) it is the least copied, and has had the least influence.

"mv" doesn't just mean move. It can move, rename, or (when crossing file systems IIRC) copy. Giving it an English name wouldn't hurt, since nobody does Unix shell stuff on an ASR-33 teletype any more, but people would have to learn that "move" meant certain behavior on Unix that didn't always go along with the name.

It would be possible to define words like "to" as no-ops, but people who use the shell would ignore it, and would sometimes get confused when they'd named a file "to" for something like "terminal orders". Unlike "move" instead of "mv", this would do some small real harm. Alternatively, what happens if I'm on a Russian box, and "k" is a no-op, and "mv" is represented by the Russian equivalent of "move" (which escapes me now, and likely can't be printed here anyway).

We can't stick NLP in there. People have to be able to type system commands and know what they'll do. Any sort of AI will add unpredictability, which is not what we want in a system command processor.

So, you'd have to learn something specific, whether it be "move" or "mv". You'd be running risks by making "to" a no-op, since that could lead to surprising behavior. If you use the interface, you'll learn it well enough, and you'll appreciate having to type fewer characters. If you can't wrap your head around "mv", you probably can't use "move" effectively either, and should stick to a GUI.

Re:Advantages of CLI

[badboy_tw2002]

At least pretend to read the article. He's not putting "pictures in the pipe". Its structured text (JSON) that has a data and view components. At least try to come up with something other than the most obvious dismissal in the shortest amount of time possible.

Re:Advantages of CLI

[Broolucks]

To me, the big pro of a command line is actually the usage paradigm: I type a command to get information, the information is displayed so that I can read it, and then the focus is on the prompt, leaving me free to do my next thing. I do stuff, I get a report about what was done, and once again, the focus is on the prompt, and I choose what to do next. The CLI, to me, is a log of command/report/command/report/etc., where at each step I can tell the computer what to do next.

Now, do I want pictures in my CLI? The answer is yes. I want to be able to type "show picture.jpg", and then have the picture pop up in the CLI, and then have a prompt for my next move. Yeah, yeah, I can open an image viewer from the command prompt already. But here's the thing: I do NOT want to open a window, because first, it is not as snappy, second, it means I have to close that goddamn window once I'm done looking at the picture (which will be a mere few seconds later in 99% of cases), and third, the image is nowhere to be found in my interaction log. It is not the end of the world, but I will gladly take what I can get.

Low resource usage has little relevance nowadays and all the prettifying should be on the client side anyhow - I mean, if you used this remotely, the remote node would produce html, and you would render it. This is not X, this is not a huge amount of traffic by any means, and worst comes to worst, html or json remain readable. This has nothing to do with automation either. The only difference is that instead of having a stream of text, you would get a stream of objects. If piping is done well, if existing programs work, if I can make compatible scripts painlessly, and if there is a pure text fallback (you never know in what pickle you will get), I will gladly take it.

Re:Advantages of CLI

[Anonymous Coward]

You would throw an exception in the JSON formatter, and fallback to the generic plain text output handler.

I'll add that, thanks.

Re:Advantages of CLI

[hitmark]

Copyright, patents, and a whole lot of "not made by us"-ism, that's why.

Re:Advantages of CLI

[Anonymous Coward]

What you need is your own command set, and nothing stops you from making that.

Nothing apart from his incompetence, you mean?

Re:Advantages of CLI

[Mr Z]

What happens when you send a malformed terminal escape sequence to a more traditional xterm? In the worst case, you can effectively 'hang' xterm... Try sending the "set titlebar" escape and forget the ^G. ;-)

Re:Advantages of CLI

[hitmark]

Sounds like Archy: https://secure.wikimedia.org/wikipedia/en/wiki/Archy

Re:Advantages of CLI

[ChienAndalu]

If there is a picture in the terminal, I imagine that to be the program output. If I am not seeing the real program output, what use is this terminal anyway.

Re:Advantages of CLI

[Arancaytar]

There is no such thing as a greatest common denominator.

Re:Advantages of CLI

[badboy_tw2002]

So you can't grasp that there can be two representations of data - machine readable and user viewable? Amazing.

Re:Advantages of CLI

[Jonner]

Command line interfaces are intended to be looked at. Shells such as the Bourne shell wouldn't have such terrible syntax for writing scripts if they hadn't been designed primarily for interactive use. If you only want a non-interactive interface, design a nice API and/or IPC protocol.

Style over Substance

[spun]

RAM and bandwidth are cheap, why not add tons of bells and whistles? They may not make anything more functional, but they make it more fun, and that's what counts, right? Oh, it's only for Mac? Well that makes perfect sense.

Re:Style over Substance

[outZider]

If you read carefully, it runs on WebKit, but uses OS X to show it off. They've already got it working in a browser, some enterprising soul will just need to generate a small WebKit component to run it on another OS.

Re:Style over Substance

[outZider]

I think it's neat, and I don't own any Apple machines anymore. It's a neat perspective, and something I'd like to try out, though I wouldn't necessarily see it usable for day to day activities.

Then again, trollin' is fun, I suppose.

Re:Style over Substance

[spun]

Trolling Apple users is always fun. But actually, yeah, I agree that it's a neat perspective and something I would maybe try out, but never something I would use day to day. I'm an old fuddy duddy cli purist that way. Give me putty and some text configuration files over the "Windows, Icons, Mouse Pointer" interface any day.

Re:Style over Substance

[outZider]

I agree, it'll be hard to pry the CLI from my cold, dead fingers.

But I'm always game to try out something that rethinks what I'm doing. Gnome 3 became a permanent fixture that way.. :)

Re:Style over Substance

[inKubus]

Right, and underneath it all there's the same text pipes, showing what's actually happening. *sigh*, Kids today. That being said, the shell is just an interpretation of the machine code, with different memory values mapped to strings, so what's one more map if someone wants it.

Re:Style over Substance

[Jonner]

Things have come a long way from the original Mac, which had no command line at all.

That's nice and all but...

[matunos]

...can I just get ncurses capability in my bash shell, so it will respond to mouse clicks?

Re:That's nice and all but...

[Aladrin]

That sounds like a good project... If you spec'd out the usage, you could probably get someone to hack it in.

Re:That's nice and all but...

[jedidiah]

Console apps can already respond to the mouse in useful ways.

You don't use console apps do you?

Re:That's nice and all but...

[Aladrin]

He's talking about the Bash Shell, not specific apps.

Re:That's nice and all but...

[ArsonSmith]

yea, so I could mouse over ~Documents and see /home/user/Documents

or something???

Re:That's nice and all but...

[matunos]

No... so I could click somewhere on the command line and the cursor would move there.

This is better how?

[egyas]

Forgive me, but I just don't see the "usability" aspect. How is this more "usable" than what I have now? What the author calls "raw" data, I call data. To me, that is WAY more usable than what the author has posted.

Re:This is better how?

[Tikkun]

But they can cat an image and see a picture of a cat with a caption! That is totally more usable! ;)

Re:This is better how?

[discord5]

But they can cat an image and see a picture of a cat with a caption! That is totally more usable! ;)

I can has xterm?

Re:This is better how?

[Anonymous Coward]

It's better because it's new, half-finished, probably created by because someone couldn't figure out how the old one worked, plus it with be full of new bugs.

Any new piece of software that ends with Kit is usually shit. Just look at ConsoleKit, DeviceKit / udisks, PolicyKit / polkit, PackageKit. Unfortunately, the developers of these type of projects usually insist on forcing everyone to use their solution, and exterminating all previous software.

Re:This is better how?

[Anonymous Coward]

LOLCLI?

Re:This is better how?

[Anonymous Coward]

It's better because it's new, half-finished, probably created by because someone couldn't figure out how the old one worked, plus it with be full of new bugs.

Any new piece of software that ends with Kit is usually shit. Just look at ConsoleKit, DeviceKit / udisks, PolicyKit / polkit, PackageKit. Unfortunately, the developers of these type of projects usually insist on forcing everyone to use their solution, and exterminating all previous software.

The parent is 100% correct. Anything named *Kit should really be named *Shit.

Re:This is better how?

[grumbel]

What the author calls "raw" data, I call data.

I call it a mess of in-band-signaling. Simple example, how many files do you see here:

$ ls
test test test

That are two files, not three, one is called "test test". The "data" contains no actual information to tell you that, that information got lost while converting it to plain text. With an advanced shell those wouldn't just be letters on the screen, but actually objects that you can click with your mouse, pipe into other applications, pipe into a file and do other things with it, while still have the shell recognize that they are files, not just strings of text.

Implementing that in a proper way that is flexible and powerful is of course not easy, but there are certainly many areas where the current shell just isn't all that great and could need improvements.

Re:This is better how?

[Anonymous Coward]

I call it a mess of in-band-signaling. Simple example, how many files do you see here:

$ ls
test test test

That are two files, not three, one is called "test test". The "data" contains no actual information to tell you that, that information got lost while converting it to plain text. With an advanced shell those wouldn't just be letters on the screen, but actually objects that you can click with your mouse, pipe into other applications, pipe into a file and do other things with it, while still have the shell recognize that they are files, not just strings of text.

Implementing that in a proper way that is flexible and powerful is of course not easy, but there are certainly many areas where the current shell just isn't all that great and could need improvements.

Stop being a damn disingenuous troll. Or, if you actually believe what you just typed, then I'm sorry it's such an incredibly tremendous burden of just typing "ls -l". Or do what I do which is just stat the directory inode.

Not to ignite any sort of flame war here, but the reason I'll take vim over gedit, notepad, or textedit is that my hands never have to leave the keyboard to do any point and clicking. The speed with which I can interact with text is much, much faster than it would be pointing and clicking my way through any mess of objects.

Re:This is better how?

[grumbel]

Or, if you actually believe what you just typed, then I'm sorry it's such an incredibly tremendous burden of just typing "ls -l".

You seem to lack the ability to think a bit more abstractly and not grasp the simple example. Hint: The problem is a very real one and regularly pops up when using "find", thats why there is "find -print0", "xargs -0" and so on. With proper objects you wouldn't need special switches for commands (which some commands don't even provide) and stuff would just work safely by default. Try to split the output of "ls -l" with "gawk" when dealing with files containing a newline if you want to have fun.

The speed with which I can interact with text is much, much faster than it would be pointing and clicking my way through any mess of objects.

Except that has absolutely nothing to do with anything I mentioned. Being ABLE to click on objects is something very different from being REQUIRED, I am not saying that you should be required, but that you should be able to and there is absolutely no good reason why you shouldn't.

Close, but no Cigar...

[MarcQuadra]

I like some of this idea, but frankly, it doesn't go far enough. Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

I would pay good money for a PowerShell implementation on Linux, and even more if Linux internals were exposed in the same way that WMI objects are on Windows.

And this is from a thirteen-year Linux veteran.

Re:Close, but no Cigar...

[Microlith]

Or instead of implementing a new language on Linux, how about doing something like a ruby or python shell, with a linux-specific library?

I mean, if you really want to hide all the information in an unbrowseable, non-human-readable object space instead of via a filesystem (where you can at least poke around manually,) there are ways to do so with existing technologies (since it's nothing new on Linux, but shiny new on Windows.)

Re:Close, but no Cigar...

[hedwards]

I'm trying to figure out what precisely is wrong with the "everything is a file" philosophy. Seems to me that it's still around here after all these years and still works well, that it's probably doing something right.

Re:Close, but no Cigar...

[Anonymous Coward]

I would pay good money for a PowerShell implementation on Linux,

You are a veteran and you don't know the iPython system shell http://ipython.scipy.org/doc/manual/html/interactive/shell.html

Re:Close, but no Cigar...

[Anonymous Coward]

Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

"Coolness" aside, what can be done with these objects that cannot be done with the files? As in, what end result can be achieved, I don't care about syntax.

Re:Close, but no Cigar...

[CannonballHead]

Seems to me that it's still around here after all these years and still works well

That argument doesn't work though. I assume most people here think Windows doesn't "work well." Well, it's still around here after all these years, too... ;)

"Everything is a file" may be fine. Who is to say something better can't be made? Maybe everything-is-an-object allows for something better... that doesn't mean everything-is-a-file is wrong. Just maybe it can be improved or a new paradigm can be used.

Re:Close, but no Cigar...

[happyhangone]

Agreed... PowerShell is how a consistent command line interface should be done. Piping objects it's a joy instead of dealing with spacing and grep-everything...
You can even have them being human readable for all those object-scared-people out there. Or hey, lets implement the same thing in python or ruby. Lets begin from 0. If you want all to be a file, so lets be it but at least that the commands have options and structures consistent between them. I hate all those arcane command line options that are not consistent even between commands that are supposedly to do similar things. All just preserved in the name of history and old scripts... ("ps aux" and "ps -aux")

Re:Close, but no Cigar...

[Anonymous Coward]

> unbrowseable, non-human-readable object space

What?! Obviously you have never used a real object oriented system such as those inspired by lisp or smalltalk where everything is browsable and human-readable.

Re:Close, but no Cigar...

[profplump]

What happens in PowerShell when that object you're piping out of program 1 isn't one of the supported object types in program 2?

Re:Close, but no Cigar...

[EvanED]

The same thing that happens when the text format output by one program isn't understood by the text input format of a second.

Object piping isn't a magical cureall for compatibility between programs, but don't pretend that text is either. What objects do is eliminate the need to parse stuff in what is half the time a broken manner. (Ever run something like "find ... | xargs" without using -print0 and -0? It's buggy.)

Re:Close, but no Cigar...

[Twillerror]

I'll continue this because powershell cmdlets have a general standard.

The whole verb-objectype syntax is pretty cool...but not really needed in the linux community, but what is cool is that they all behave the same way.

Every linux command works a little differently. Wouldn't it be nice if ever command had a --getCMDLineOptionsJSON that returned JSON that bash could use to auto complete...powershell's "tab" will autocomplete --arguments.... At the very least it would nice if they all implemented --version

It wouldn't be hard to port either. We could have objls which would be "object" ls. I've always considered the human readable -> binary -> human readable ->binary of Unix to be old school. The computer should be able to pipe information around in a binary format versus a giant chunk of ascii\unicode.

Kudos for MS for doing something cool....but of course then they went and screwed it up. The security around powershell is very very stupid. Issuing powershell commands remotely is equally stupid. Powershell over SSH...come on MS...get SSH standard for christ sake.

Re:Close, but no Cigar...

[Anonymous Coward]

You fall back to text. To tell the truth, it does not happen that often.

So the WORST case is that you deal with parsing text rather than that being the default case.

Re:Close, but no Cigar...

[hedwards]

The argument works, Windows for a long time wasn't as good as the competition and it was very clear to anybody that had used anything else. The only people who thought that it worked well were individuals who didn't actually have to fix it. I remember times when the CDROM would inexplicably disappear or the monitor resolution could only be changed via a registry tweak which would have to be applied every time the computer loaded. Fixing those sorts of problems shouldn't even be necessary. Consequently, I have to say that it's not really a negotiable point that Windows wasn't working well. Nobody in their right mind would suggest that an OS which does that is working well.

And if you've been paying attention MS implicitly agrees, which is why there's little if any actual code left in Windows from the 9x era and before, the code was just crap and didn't work reliably. Whereas for some other OSes, there's still code going back a lot longer than that, with just fixes and extensions where needed.

When they come up with something that's even more flexible and even more useful, then I'll consider.

Because you're greatly increasing the learning curve and decreasing the actual usefulness when you do it. The previous model lasted so long because the main limitation was ones imagination. With the objects version, all of a sudden you have to know a lot more in order to get started. I've tried to get started with it, and quite frankly, the learning curve is a headache for those that don't know a lot about programming, whereas previously you needed to know very little to get started and could readily tweak the output.
 

Re:Close, but no Cigar...

[jbengt]

Everything is a file, including every object.
Everything is an object, including every file.
No difference, except in syntax .

Re:Close, but no Cigar...

[jandrese]

You have to convert them down to text or octet streams I think.

I tried Powershell a few times, but it seems like if you're not already up to your nose in .NET it is pretty hard to use and wildly verbose. It also seems like it was a little painful on the commandline, more of a scripting language than a shell. I felt like I would need an IDE with autocomplete to really get anywhere in it.

Re:Close, but no Cigar...

[Anonymous Coward]

nooby

Re:Close, but no Cigar...

[yarnosh]

My first impression of PowerShell was that it was too much of a programming language and not enough of a shell. Similar to the a Ruby on Rails application console. Great access to the internals with application objects, arrays, hashes, regular expressions, etc, but pulling in data from outside is kind of a pain. I dunno though, I never cared to use Windows enough to figure PowerShell out.

Re:Close, but no Cigar...

[fusiongyro]

I agree that that would be cool, though I consider this fundamentally different. But I don't think we're going to see a useful PowerShell for UNIX simply because in UNIX the only thing you can rely on is files. There is no inherent object model underneath everything that you can tie everything together with. On Windows, particularly since reinventing everything with .NET, there is usually an object model underneath, so it makes sense to reimagine the shell from an OO perspective (not too OO though, or it would be Transcript in Smalltalk).

Re:Close, but no Cigar...

[fusiongyro]

You should see it under Plan 9, where literally everything is a file, even things like windows, hardware, network connections, etc.

Re:Close, but no Cigar...

[benjymouse]

"Coolness" aside, what can be done with these objects that cannot be done with the files? As in, what end result can be achieved, I don't care about syntax.

With PowerShell those objects are .NET or COM objects. Just about every application on Windows is built upon one of these object models. This means that PowerShell can directly use the same building blocks which make up the applications. The applications become scriptable by default without the need to create CLI specific tools to manipulate the objects. Word, Excel etc. are all built this way and lends themselves to "automation" through the object model.

On Unix/Linux the applications and tools are monoliths executing in separate processes. On Windows the equivalent applications are built from discoverable components which can be used by scripting tools such as PowerShell. Important here is also the fact that PowerShell instantiates objects in-process so that even if they are designed around manipulating memory structures this will work even when combined on a command line in PowerShell.

So, the fact that "everything is an objects" means that your reach from the command line is greatly enhanced. You can script objects of applications which were never designed with CLI scripting in mind.

Re:Close, but no Cigar...

[Anonymous Coward]

You can script objects of applications which were never designed with CLI scripting in mind.

Oh... so you mean it's something like this and this. And to think, I was all ready to be impressed.

Re:Close, but no Cigar...

[Anonymous Coward]

What happens in Linux when program 1 outputs text formatted such that program 2 can't grok it? What happens in Linux when you pipe a binary stream from program 1 where program 2 is expecting LF-formatted ASCII text? It fails, and usually not in an obvious way.

Object interoperability is all about contracts and/or base assumptions about operations that are legal and/or appropriate to the object. A text stream is the same way, except the assumptions you can make are very few and far between. 7- or 8-bit characters, arranged in lines of indeterminate length, delimited by LF. Or CR. Or CRLF. Depends on where the text originated. That's it.

So what useful work can you do based on such limited assumptions? Very little.

Unless of course program 2 starts to make assumptions about the output of program 1, such as "the first line is a comma-delimited list of field names, the remaining lines are comma-delimited values, the third column is an integer that represents timestamp, etc etc". At that point, you are in the realm of passing semantically meaningful data using a very limited stream format, one that is not self-defining, and doesn't always fail gracefully in the aftermath of mismatched assumptions.

So GIGO has bad effects when you are using text streams, just as it would if you hand off objects that don't obey the interface(s) that are expected downstream.

But hey, objects are bad. Text is good. Rah rah.

Re:Close, but no Cigar...

[oakgrove]

Piping objects it's a joy instead of dealing with spacing and grep-everything...

I like grepping. Its regular expression syntax gets me exactly what I need everytime and since I actually took the time to learn how to use it, it's like second nature.

I hate all those arcane command line options

They may be arcane to you that doesn't mean they are arcane to somebody else. PowerShell is extremely verbose compared to Bash. That seems pretty arcane to me.

("ps aux" and "ps -aux")

Kind of a silly quibble there.

Re:Close, but no Cigar...

[rk]

No, because I know how to use the -exec option in find. ;-)

Re:Close, but no Cigar...

[oakgrove]

The same thing that happens when the text format output by one program isn't understood by the text input format of a second.

What, I use another tool from the toolkit to filter the text into what I need? That's second nature and very easy once you take the time to learn what is available and how to use it. Kind of like with every other tool on a computer aimed at experts and power users.

Re:Close, but no Cigar...

[Anonymous Coward]

ps... smokes something.. it aint cigars, but it is green though!

ps works for configuring ms services and parts of windows. scripting can be done in ps, but to be able to really get stuff done, you're better off writing a real program. Which is often a lot easier to troubleshoot than scripting ps. ps really does some weird stuff.. even return in a function doesn't really work.. return doesn't do anything in function, it always passes every output of the fuction as return value.. plain stupid really.

objects in ps are often a hell! one command creates an string, pipe it.. and ik becomes an array. get-childitem *| do something works on files, but if you use it in the registry, all items matching the wildcard are wrapped in one object after piping. no known command can edit it.

u usualy end up doing a lot of stuff in batch.. why, it just works with readable error...

Re:Close, but no Cigar...

[Anonymous Coward]

(Ever run something like "find ... | xargs" without using -print0 and -0? It's buggy.)

which is why I run "find ... -exec command {} \;" instead...

Re:Close, but no Cigar...

[jpate]

Every linux command works a little differently. Wouldn't it be nice if ever command had a --getCMDLineOptionsJSON that returned JSON that bash could use to auto complete...powershell's "tab" will autocomplete --arguments.... At the very least it would nice if they all implemented --version

here you go. Try typing "ls -" then push tab twice. magic!

Re:Close, but no Cigar...

[EvanED]

Then you can use another tool to filter the object from the first to the second if you have object piping. And it'll probably be easier because you don't have to parse crap.

Re:Close, but no Cigar...

[benjymouse]

here you go. Try typing "ls -" then push tab twice. magic!

While cool, bash completion still only works for commands for which the completion has been defined. In PowerShell cmdlets, functions, aliases and even script files inherently interact with the shell to provide metadata about parameters, types, defaults etc so that

• tab-completion is defined by the very same declarations that drive parameter parsing. As soon as you declare a parameter for a command, function or even your own script file, tab completion is working
• help is integrated and will document the parameters using the same declarations, regardless of whether you actually provide textual descriptions for the paraneters (help documentation is integrated and you can document parameters with a simple comment convention - which goes for both cmdlets, functions and script files).
• tab-completion will also *dynamically* reflect on the actual objects if invoked for a .NET, COM or WMI object.

Re:Close, but no Cigar...

[EvanED]

Good thing those don't always do the same thing then. (Though fortunately I now have access to a new enough version of Grep that my main use case for where they differ is obviated.)

Re:Close, but no Cigar...

[Anonymous Coward]

What happens in Unix when the text you're piping out of program 1 isn't in the supported format of program 2?

Re:Close, but no Cigar...

[oakgrove]

That's not what I asked and has nothing to do with the comment I replied to. Also, you'll have to forgive me for my lack of confidence in your

probably

.

Re:Close, but no Cigar...

[Anonymous Coward]

Powershell objects are emitted by native powershell commands ("cmdlets"). External EXEs emit whatever they emit (strings, binary data, etc) and get consumed by the pipeline usually as an array of strings, but it can just be data. Native commands run as a thread in process so they can pass their objects (which are really just .net objects with a few layers of powershell classes on top) around transparently.

If you like grepping (which I do), .net regex matching is available with the -match operator anywhere you need it.

If you want your legacy EXE to emit "real" objects, you could munge the output into the appropriate XML format and then import it to powershell via import-clixml. That would get you appropriate typing.

Re:Close, but no Cigar...

[oakgrove]

What happens in Linux when program 1 outputs text formatted such that program 2 can't grok it?

Um, there are commands like sort, grep, cut, et al whose sole purpose is to format text on the command line.

You are obviously not new to this so why are you trying to be misleading?

Re:Close, but no Cigar...

[shutdown -p now]

I like some of this idea, but frankly, it doesn't go far enough. Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

Not everything makes sense as an object, though. I think this guy rather got it right - he uses binary streams as a fundamental data type, and then JSON on top of that for structured data (but that is a convention between programs, not forced by the shell itself). Ultimately you still get typed data flying around - where that makes sense (e.g. for output of ls). Only it's in a standardized language-agnostic format, which can still be parsed as text if need be (i.e. it has a canonical text representation, which is what is passed through the pipe).

Re:Close, but no Cigar...

[benjymouse]

Oh... so you mean it's something like this and this.

Nope. Nothing like that at all. I believe you misunderstand what automation is about. It is not about controlling an application user interface. That is brittle and error prone. Rather, automation is about accessing and controlling the model of the application and performing the actions directly.

Re:Close, but no Cigar...

[Anonymous Coward]

It is not about controlling an application user interface. That is brittle and error prone.

Please, enough with the hyperbole. Based on my years of experience writing scripts with both dogtail and xdotools (and xmacro), that is pure strawman bs.

Re:Close, but no Cigar...

[oakgrove]

While cool, bash completion still only works for commands for which the completion has been defined. In PowerShell cmdlets, functions, aliases and even script files inherently interact with the shell to provide metadata about parameters, types, defaults etc so that

tab-completion is defined by the very same declarations that drive parameter parsing. As soon as you declare a parameter for a command, function or even your own script file, tab completion is working

Maybe so but when the command is defined in bashcompletion it's done. At the end of it, whether it's "easier" in PS or not, it boils down to the same thing. The guy up the thread was completely ignorant to the fact that you could have tab completion of parameters in bash at all which is what was corrected and rightfully so.

help is integrated and will document the parameters using the same declarations, regardless of whether you actually provide textual descriptions for the paraneters (help documentation is integrated and you can document parameters with a simple comment convention - which goes for both cmdlets, functions and script files).

Help works very well on *nix for the command line. Just type "man $COMMAND" and get educated. If you want your script to have that you can. Or you can just put the documentation inside of the script. Again, it boils down to the same thing.

Re:Close, but no Cigar...

[garethjrowlands]

You need to pick a better example for powershell verboseness. The powershell for "ps aux" is "ps".

Re:Close, but no Cigar...

[lakeland]

Oh it is good, but everything is an object buys you everything is a file and a few extra things - it's even better :)

Re:Close, but no Cigar...

[Anonymous Coward]

Don't go liking this PowerShell too much. If you dig into it you'll see that a shell which displayed images and such using WPF was built using PowerShell something like three years ago.

http://blogs.msdn.com/b/powershell/archive/2008/05/25/powershell-and-wpf-wtf.aspx

Re:Close, but no Cigar...

[waveclaw]

. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

It is pointing out the obvious that a file is kind of object, with a certain defined behavior, strong namespaces and associated methods?

Systems like Plan9, where everything literally is a file make the painfully obvious. The only changes would be to make file properties be just more files that appear to live bellow the filename as if it were a directory and get rid of completely foreign namespaces like the network interfaces.

There is some extra syntatic sugar with object systems. The 'object' systems use dot delimited dereferencing for system enforced sub-classing - runtime resolution of the thingy being talked about. The file system's path separators are only meaningful on the filesystem meta-level for object...er...file isolation. Otherwise we are dithering over path separators to namespaces: /path/to/thingy instead of container.subelement.thingy.

Of course, PowerShell has the advantage of an actual design and uniform implementation. Even the traditional Unix utilities produce completely unique output formats that often require regular expressions to pull out meaningful data or at least massage the pipe. This is a possible consequence of unregulated organic growth.

Now, the author of TermKit has a valid point in his article on the sofware's design: not enough file handles are used by traditional Unix utilities. STDOUT and STDERR are both used to produce human-readable and machine-readable output. Instead make STDOUT,STDERR (FD 1 and FD 2) machine-only and FD 3 and 4 be used for human-consumable output. This could be much more flexible. (Of course, like most standards, nobody would have used it in the sake of rolling the next great thing.)

But this highlights that trivially parsable output combined with pure file semantics gives you the benefits pure 'object' environments like Powershell gives to users. So it appears the inconsistency between terminal applications is the real issue, not some mythical object-ness that Powershell proponents claim files don't have. And TermKit's plugins / adapters "fix" that.

After all, what are programing languages but syntactic sugar in our heads, mere mental layers on top of high and low voltages running through some hardware?

Re:Close, but no Cigar...

[Anonymous Coward]

Could you give a concrete example? Like I want to configure X driver: PowerShell vs linux:bash?

I can't imagine anything that PowerShell makes easier than bashNix does. Different syntax... but easier?

Thanks!

Re:Close, but no Cigar...

[Anonymous Coward]

You're missing my point. The GP example was passing an object to a program that didn't understand the object's interfaces. The inference was that this isn't a problem if all you do is just pass text around. Because hey, it's just text, everything knows what to do with text, right?

My point, which has been echoed by other posters, is that it's not just text. It is semantically meaningful information that has been rendered as LF-terminated ASCII text. So while every little shell app might know how to accept text on stdin, it doesn't mean it will work right unless you send it text that satisfies the shell apps's assumptions about the information embodied in the text, and the specific way in which is it formatted. If those assumptions are wrong, things will break, just like if you hand off an object to a Powershell script that doesn't meet the expectations of that downstream script. Classic GIGO, and things will break regardless of the format of the information being passed around.

As to your pointing out of the obvious (use text reformatting utilities such as grep, cut, etc to massage the text before you send it to program 2), the GP's point invalidates that too. All you are doing is adding a "program 3", which is the reformatting process that occurs between program 1 and program 2. If program 1 outputs text in a format that program 3 doesn't expect, it's attempt to reformat it for program 2 is going to break. And you can use the same translation paradigm in an object-based system, where you have an intermediate program which projects the objects emitted by program 1 into a representation that is recognized by program 2. Same deal, different method of operation.

At the end of the day, if you are going to make two pieces of software cooperate, there must some baseline agreement for the data exchange. If one side does not adhere to that agreement, then things will break. The Unix "pipe a bunch of text around" philosophy doesn't help you.

Re:Close, but no Cigar...

[Anonymous Coward]

The UNIX philosophy is actually "everything is a byte stream". Obviously, a socket can not have rwx------ permissions.

While that's still a powerful concept, it's a far cry from what a true OO system can deliver. Something as simple as an image is already a pain. Is an image a bitmap, or a JPEG file, or a PNG file, or ? With a bytestream, these options are mutually exclusive.

In general, with a byte-stream interface, you always incur serializing and deserializing costs, even if it would be entirely unnecessary. UNIX adds the extra level that its common serializing format also is used to communicate with users. So, while this TermKit solves the latter, it fails to address the former.

Re:Close, but no Cigar...

[Eil]

Now, the author of TermKit has a valid point in his article on the sofware's design: not enough file handles are used by traditional Unix utilities. STDOUT and STDERR are both used to produce human-readable and machine-readable output.

I disagree with this assertion and with the author's belief that another channel is needed for command-line programs. The inventors of Unix (and the systems that came before it) thought very hard about how to get data in and out of programs and they didn't make a mistake when they settled on three channels (stdin, stdout, and stderr).

stdout can produce human- and/or machine-readable output, depending on the program and depending on how you invoke it. With no special arguments to the contrary, most programs should assume that they are being run interactively and that all input is provided by and all output is produced for humans. If you want machine-readable output (as input to another program, for example), require the use of a flag to do so. If you want both at the same time, then produce human-readable output on stdout and use one of the many interprocess communication facilities that modern operating systems already provide.

But it is a rare (and likely broken) program that produces exclusively machine-readable output on stderr by default. stderr is what programs use when to report an error message when something goes wrong. stderr is on a separate channel for the explicit reason that errors should not be used as input to the next script in the pipeline, if there is one. It doesn't matter whether the program was run interactively, in a pipeline with other programs, or via a script. Error messages should always be human-readable.

Re:Close, but no Cigar...

[Jonner]

I would pay good money for a PowerShell implementation on Linux, and even more if Linux internals were exposed in the same way that WMI objects are on Windows.

And this is from a thirteen-year Linux veteran.

It's surprising that a thirteen-year Linux veteran wouldn't have discovered Python, which also is based on the idea that everything is an object, and has run on Windows and any kind of *nix for many years before PowerShell showed up. Its standard library has a huge amount of functionality built in and PSI - Python System Information looks like an easy way to get at system information. The enhanced interactive shell IPython has a lot of time saving features compared to the default one. Even on Windows, I'd rather use Python than PowerShell, since it has easy access to all the same COM and WMI objects that PowerShell does.

Simple Solution

[Haedrian]

The Simple solution in my opinion is to simply have the GUI windows, with a section at the side for terminal.

Whenever the user ls (or dir)'s from the terminal, the GUI changes. If you click on something in the GUI, the terminal automagically puts in the exact path to the object in the GUI.

Best of both worlds, might be fun to do.

Re:Simple Solution

[Cryolithic]

I'm fairly certain you can (could?) do this in KDE, but it may have been a Konq feature that never made it to Dolphin

Re:Simple Solution

[Haedrian]

Now that you mention it.. the wikipedia page for Konsole says

"Can open Dolphin or the user's preferred file manager at the terminal program's current directory"

So... close enough.

Re:Simple Solution

[dotancohen]

KDE's Dolphin has this. I use it regularly. Just open Dolphin and press F4 (or View->Panels->Terminal).

The only problem is that cd doesn't update the file manager display. But clicking the file manager does perform cd in the terminal.

Re:Simple Solution

[dotancohen]

I just filed a bug on it:
https://bugs.kde.org/show_bug.cgi?id=273674

Re:Simple Solution

[vgerclover]

Not only that, if you are using Dolphin and go to View > Panel > Terminal (F4), you get a Terminal Panel embedded to the file browser, which is affected by the changes in the file browser (cd /Directory/I/just/entered). I guess it is missing the opposite and maybe changing the folder view panel style when doing ls with different flags. There are definitely possibilities there without throwing away bash just yet :)

Re:Simple Solution

[Anonymous Coward]

You know that this is quite standard behavior of, e. g., KDE (F4)? Although I liked the KDE 3 way more where the terminal opened in an extra window and did not cd while cd-ing in the GUI file manager. Couldn't live without.

Re:Simple Solution

[Rennt]

So... yet another Midnight Commander clone? :p

Re:Simple Solution

[Anonymous Coward]

Although I liked the KDE 3 way more where the terminal opened in an extra window and did not cd while cd-ing in the GUI file manager. Couldn't live without.

You can still get the windowed behaviour with Dolphin. All of the panels (the terminal, information, places, folders) have two window controls visible: one to close and one to embed or split the pane from the window. Personally, I prefer keeping it embedded, because of the next trick: Shift-F4 spawns a new konsole at the current location. It doesn't follow Dolphin's path like the embedded one, and behaves more like what you want.

I find them both useful for different things, so I keep the F4 one embedded as a reminder that it will follow Dolphin, and use shift-F4 when I don't want it following Dolphin's path.

Re:Simple Solution

[Anonymous Coward]

I think something like that already exists, but I can't recall where I saw it. Either it was some IDE or possibly in some file manager. Still, I agreee that it's an interesting idea to enhance regular programs with a terminal.

Now that I think of it, you can do that in the program Splunk, except that Splunk is a local search engine for logs rather than a general-purpose program/terminal. You either manipulate the search query manually, or you click events in the search result to drill-down (which basically creates a filter). Splunk's search queries follows a similar syntax as the command line, with results being piped from one command to the next.

Re:Simple Solution

[Anonymous Coward]

So when you have 14 different terminals open on your screen at the same time, which one is updating the pretty bit? Or do you also have 14 different graphical file display windows open for each of your 14 current working directories?

Re:Simple Solution

[Anonymous Coward]

Second, I don't know why I didn't see the older posts already covering KDE/Konqueror/Dolphin when I submitted my redundant (06:31PM) post. Well, screw you, /.

First (and more important), thanks for the shift-F4 bit! I didn't know this and somehow I didn't have the time reading about all the shortcut changes when first encountering KDE 4. I'll give it a try next time I see Dolphins around. May the Terminal be with you.

Re:Simple Solution

[Anonymous Coward]

Good luck getting it to behave in a way you like. I hated Dolphin at first, but mostly I just hated its defaults. Once I got around to digging into the settings and shortcuts I found a lot to like. Being able to split off all the panels, rearrange them, and even group them into tabs made a huge difference for me, as did enabling the filter bar by default in the settings.

I actually like Dolphin more for most things, now, though I still use Konqueror when I want more complicated view splits. View splitting is rudimentary compared to konq, but I'm okay with that as long as both programs are available. :)

But think of the tweeps

[suso]

But if we moved to this model, how would I give tips on climagic? I'd start having to post links to screen shots. I kid. Sounds like this guy is trying to turn the command line into the multilayer net with protocols between the programs.

Re:But think of the tweeps

[Anonymous Coward]

Sounds like this guy is trying to turn the command line into the multilayer net with protocols between the programs.

In other words, ruin it. Have they run out of ways to ruin GNOME, so decided they better get started on the command line?

Re:But think of the tweeps

[Jonner]

There have always been protocols between programs run on the command line, but they've been ad-hoc. This approach works fine for simple stuff, but when you get a little complex, it starts being a pain. This is certainly not the first attempt to improve on that ad-hoc IPC model. For example, check out Infopipes, XML Pipeline and Hartmann_pipeline. I don't know if any of those is any good or if they're intended to be used interactively in a shell.

cat crap

[Anonymous Coward]

If i cat something, it is because I want to see the source, not the interpered result.

Re:cat crap

[suso]

I don't think you could keep the old command names, they'd have to be remade. Probably a program called view would be better suited for displaying the intended content in various ways (including reformatting if you want using style configuration) that also has a flag for raw data view or a separate program for that.

Re:cat crap

[dzfoo]

Also, the purpose of "cat" is to concatenate files, not display; it just happens to output to STDOUT so that it can be used as part of an efficient tool chain workflow. By consequence, using "cat" on a single file will output its contents to the terminal. This is a useful side-effect, but not its main function.

          -dZ.

Re:cat crap

[arth1]

view already exists - it's equivalent to 'vi -R'

Re:cat crap

[shutdown -p now]

His variety of cat is the same - the only difference it has from the traditional Unix one is that it slaps a Content-Type on the output stream, guessing it from the extensions of input files (if any). Displaying the image is done by the terminal itself, once it spots Content-Type:image/* in the output of cat.

WHOOOOSH!

[blair1q]

"You can cat a PNG and have it just work."

Uh, no, Doctor Disorthogonality, you broke it. When I cat a PNG I want to see the bytes, not a picture. If I want to see the picture I'll firefox or gimp the PNG, then it will just work.

And fixed-width fonts for data are ideal. Using a variable-width font and trying to od anything is a freaking nightmare.

Re:WHOOOOSH!

[he-sk]

Especially, when you can simply `open` it on a Mac (opens in Preview.app) or `display` it on Linux (using ImageMagick). I just tried it, by catting a PDF file and that turned out to be rather annoying, because it broke scrolling in the terminal window.

Some of the features are nice, for example the filename completion (way better than pressing tab). But it's missing automation, so basically it's useless.

Re:WHOOOOSH!

[yarnosh]

I'm pretty sure you DON'T actually want to see the bytes of a PNG on your terminal. I've ruined countless terminal sessions by accidentally catting binary.

Re:WHOOOOSH!

[blair1q]

$ cat -v lena.png
(follow your bliss)

Re:WHOOOOSH!

[bobetov]

Whoosh back at you. cat a png, and the *data* is bytes. The *ui* is a display based on the type of data being shown - in this case, an image.

That's really the core idea - separating what data-centric tools see, and what users see.

Re:WHOOOOSH!

[Guy Harris]

When I cat a PNG I want to see the bytes, not a picture. If I want to see the picture I'll firefox or gimp the PNG, then it will just work.

And fixed-width fonts for data are ideal. Using a variable-width font and trying to od anything is a freaking nightmare.

If by "od" you mean the od command, trying to od anything involves piping it to od. When I cat a PNG I usually type ^C pretty quickly; if I want to see the bytes I'll pipe it to, err, umm, od.

But, yes, there are places where variable-width fonts are suboptimal, even in pure GUI apps; Wireshark would have to do a bit more work to ensure, for example, that the entries for bitfields within a byte/word/etc. line up when using a variable-width font. In a world with variable-width fonts in the terminal emulator, commands such as od might have to explicitly indicate "hey, this is a table with numbers in it, don't fuck it up" (and commands that haven't explicitly adopted any of the Shiny New Stuff might have to be assumed to require that its output be displayed in a fixed-width font).

Re:WHOOOOSH!

[mr_da3m0n]

Just being devil's advocate here, but did you actually read the article? Only the view intereprets the bytes which makes sense. If you pass it over a pipe, bytes are sent. I think that is what you meant, because no one actually like cat'ing a PNG in their terminal to see a bunch of garbage that may even break the terminal until you reset it. Or maybe that is a very obscure use case you have?

He separates view from data. Which is okay. Not something I particlarily like or find it useful, being a unix greybeard at heart, but it doesn't break it as you suggest. I suggest you read it over in detail again and don't stop at the first sentence.

Re:WHOOOOSH!

[yarnosh]

Great, so now I have The Matrix scrolling on my screen....

Re:WHOOOOSH!

[Anonymous Coward]

When I cat a PNG I want to see the bytes

Why (or how often) would you want to see the bytes?

Re:WHOOOOSH!

[blair1q]

Considering I cut-n-pasted what looks like about the 98th sentence, I call shenanigans.

Re:WHOOOOSH!

[blair1q]

Because that's what cat is supposed to do (every time).

If he wanted object-oriented polymorphism, he should have implemented something like this:

$ ls
foo.png readme

$ foo.png display
{outputs the picture}

$ foo.png cat
{outputs the bytes}

Re:WHOOOOSH!

[TeknoHog]

Using a variable-width font and trying to od anything is a freaking nightmare.

Yes, a fixed-width font does make it clearer whether I'm taking 2.0 mg or 0.2 mg of acid.

Re:WHOOOOSH!

[dotancohen]

The point is that cat would be like a double click: it would just open whatever file in the default application.

Re:WHOOOOSH!

[Novus]

In practically any sane terminal emulator, you're not seeing the bytes, you're seeing a picture generated from these bytes by interpreting it as text with embedded control codes. This is merely an extension of that concept; instead of just "clear the screen" and "switch text colour to red" you also have "display the following PNG". Considering that there are tons of different sets of escape sequences in use, one more would hardly be a problem. Since the author suggests that the metadata identifying the data type (MIME-style) would be separate from the actual data, legacy programs would presumably just ignore the additional information and behave like they used to.

Re:WHOOOOSH!

[Estanislao Mart�nez]

The point is that cat would be like a double click: it would just open whatever file in the default application.

Actually, no, that's not the point. The point is that data and user views are separated, so that cat sends bytes, and the program that receives cat's output then decides how to treat them. If the recipient is the terminal, then the terminal displays the content as an image.

Re:WHOOOOSH!

[Anonymous Coward]

But when you cat a png in an existing shell you DON'T see the bytes. What actually happens is your terminal flashes and beeps like mad and then you have to reset it. That's REAL useful, huh?

Re:WHOOOOSH!

[mr_da3m0n]

Ah I see. You have apparently also ignored all of the contents of my reply but the last sentence. I think I'm starting to see a pattern here.

Re:WHOOOOSH!

[SBFCOblivion]

feh the picture!

Re:WHOOOOSH!

[blair1q]

We already have a program like that. It's called exec(2). You invoke it by typing the name of the file into the shell. But that only works for files with magic numbers matching executable types. .png is a data type, not an executable type. You'd have to do a #!/usr/bin/gimp at the beginning of the .png file to get it to work, but then it wouldn't be a .png file.

Maybe data should be data and executables should be executables. If you don't have "progname datafilename" as your syntax, you don't need a CLI at all, and double- or single-clicking the file should "open" it. And then you're talking GUI, not CLI.

cat(1) has a very specific thing it does, and that's good and in keeping with the original design philosophy of orthogonality among the basic set of binaries. Crufting it up with a lot of modal behavior is counter to the point of Unix.

Re:WHOOOOSH!

[blair1q]

No, I didn't ignore what you said, I just considered it moot.

If cat doesn't do what cat normally does, then how do I get what cat normally does? Now I have to write another program to get around the change you've made in the behavior of a program that always did what I wanted done. And now when I use cat on any file type that isn't plaintext, I have to know what will happen to that data instead of what cat is designed to do. It makes me feel about the simplest possible unix command the way I feel about .exe files I've just downloaded but never clicked on: like I'm about to be in a situation where I want to slap the reset button.

Re:WHOOOOSH!

[StikyPad]

"You can cat a PNG and have it just work."

Uh, no, Doctor Disorthogonality, you broke it. When I cat a PNG I want to see the bytes

Uh, no, when you cat a PNG you're seeing an ASCII (or maybe UNICODE) representation of the bytes. What you've done is to confuse the rendering of the data for the data itself. All this guy has done is gone back in and said "you know, we can render things intelligently instead always as text." And it's pretty brilliant IMO.

When you want to see the bytes represented as ASCII, then either use the appropriate syntax in TermKit, or don't use TermKit at all. Or re-alias the commands. It's sad when people poo-poo an idea simply because it's different, as if different == wrong.

Re:WHOOOOSH!

[Anonymous Coward]

if anything you should treat it like an executable so cat still works and typing foo.png is essentially aliased to gthumb foo.png

Re:WHOOOOSH!

[marcosdumay]

Try "reset".

Re:WHOOOOSH!

[Anonymous Coward]

If you wanna see the bytes, you don't cat it, you hexdump it.

Re:WHOOOOSH!

[drinkypoo]

The author is also guessing mime types from the extension instead of using magic :(

I mean, if you're going to make it look like it knows what it's doing, maybe it should know what it's doing

Re:WHOOOOSH!

[yarnosh]

I've been in many situations where that doesn't fix it. In some Linux terminals it would completely screw up the text, turning everything a garbled mess.

Re:WHOOOOSH!

[mr_da3m0n]

I still think you're not fully getting the point I was making. The behavior of cat doesn't change in theory. The behavior of the terminal when confronted with a bunch of garbage matching the mimetype of a png is what changes. It present it in a useful form. It is exactly like ansi escape codes for color output, no more no less. I still have no idea why you'd want to see the garbage in the first place, because it is just that, garbage. It's not even the bytes in the file, it's the bytes mistakenly interpreted by your terminal, which results in bleeps and borps, and other terrible fuckups until you reset it. If you pipe or redirect the output stream to something else, you're still working with data, because the view isn't involved.

It's simply a different view on the same data. This is what I meant by separation of view from data, which *is* in general, a good idea. Again, I am not saying I would love to see this in my shell. I'm just saying it isn't necessarily broken.

In short, it basically makes your terminal, the view layer, handle the garbage graciously and display the png. It doesn't mean that cat can now render pngs. If that was the case, it would indeed be broken because I don't expect cat to do this. I expect cat to con(cat)etnate files and toss the output to stdout.

It is a subtle difference, but it is quite significant, and indeed the difference between broken and just arguably useful.

Re:WHOOOOSH!

[Novus]

You're missing the point. cat is not supposed to distinguish between file types nor behave differently based on the file type; the only change to its behaviour is to propagate the MIME type information (which, unfortunately, is guessed from the file's extension rather than a proper MIME type field in the filesystem). The terminal is the one that does all the interpreting, and, as I mentioned, this already happens, albeit to a lesser extent.

Re:WHOOOOSH!

[blair1q]

I still have no idea why you'd want to see the garbage in the first place

Because I debug.

Re:WHOOOOSH!

[Jonner]

The "cat" command is certainly the wrong choice for displaying an image since it's purpose is to concatenate streams of bytes, something everyone seems to have forgotten. What would it mean to concatenate two or more images? Superimpose them? Make a collage of them? Make an animation with each image a frame? However, a command like "open" or "display" might make sense.

Re:WHOOOOSH!

[illtud]

I'm pretty sure you DON'T actually want to see the bytes of a PNG on your terminal. I've ruined countless terminal sessions by accidentally catting binary.

'reset' is your friend.

Re:WHOOOOSH!

[illtud]

I'm pretty sure you DON'T actually want to see the bytes of a PNG on your terminal. I've ruined countless terminal sessions by accidentally catting binary.

'reset' is your friend. ...and 'preview' is mine. furrfu.

Re:WHOOOOSH!

[yarnosh]

Doesn't always work.

Re:WHOOOOSH!

[illtud]

Didn't know that. Never had it fail for me, YMMV of course.

Inspirational project

[Anonymous Coward]

Ever since I got my Nokia N800, it has been obvious to me that an xterm on a mobile device is extremely limiting. So when I saw the TermKit post on LWN, I went right to the blog article. The idea is extremely inspirational. I would love to see someone do a tablet/handset shell/term project that incorporated some of TermKit's ideas. Scared to death that TermKit has grep and ls implementations. Love the idea of 'cat foo.png' to see an image in the terminal.

You are a newbie only once in your life

[mangu]

why not offer an 'easy' path for those who don't have the shortened commands memorized?

Because you would be encumbering every one with a verbose syntax. After just a few times you'll feel it quite easy to remember that 'move' is 'mv'.

Once you learn the short way to do it you don't want to spend the extra effort in the long command. You may think it only takes one second to type, but you forget how many thousands of times you'll be using the same command again in the future.

Oh, the Hypocrisy

[VortexCortex]

From TFA, (WRT why terminal interaction is flawed):

This has lead to "somewhat parseable text" being the default interchange format of choice. This seems like an okay choice, until you start to factor in the biggest lesson learned on the web: there is no such thing as plain text. Text is messy. Text-based formats lie at the basis of every SQL injection, XSS exploit and encoding error. And it's in text-parsing code where you'll likely find buffer overflows.

?
Thus says the guy who's implementing a HTML5 + CSS + JS client / server terminal wrapper. Hey, FYI, your whole TermKit stack is made of parsed text. Indeed, the only way to access your API is via parsed text. As if Webkit (that TermKit is build on) never has any "buffer overflows". Pffffft. Added complexity, more surface for bugs to appear, 'nuff said.

Also -- No thanks. I already have a window manager. I agree that occasionally mouse input is the right choice, and an environment that embraces both text terminal and GUI elements is neat, but I just couldn't stand to read any more of the Hypocritical remarks...

He talks about displaying objects and passing them around as JSON objects -- Yeah, JSON is a textual representation of an object that must be parsed to be displayed.

P.S. Only available on Mac? What the duce? It's just a HTML / CSS + JS interface -- If the guy had any brains you could just point any browser at it and he'd have saved the time of writing a complete client... unless... the goal is to take some elitist (noob) stance regarding UI.

More "Text is Sloppy" hypocrisy:

TermKit's input revolves around tokenfield.js, a new snappy widget with plenty of tricks. It can do auto-quoting, inline autocomplete, icon badges, and more. It avoids the escaping issue altogether, by always processing the command as tokens rather than text. Keys that trigger special behaviors (like a quote) can be pressed again to undo the behavior and just type one character.

The behaviors are encoded in a series of objects and regexp-based triggers, which transform and split tokens as they are typed.

Uhhhggg.

Re:Oh, the Hypocrisy

[Anonymous Coward]

Yeah, there definatey seems to be something wrong with the dev, here. He seems inconsistent if not completely delusional.

Read some of the comments on TFA. He brags about having years of UNIX admin experience, but doesn't seem to grasp core concepts... why certain commands output the way they do and how that output is useful in practical application.

Re:Oh, the Hypocrisy

[VortexCortex]

Yeah, there definatey seems to be something wrong with the dev, here. He seems inconsistent if not completely delusional.

Read some of the comments on TFA. He brags about having years of UNIX admin experience, but doesn't seem to grasp core concepts... why certain commands output the way they do and how that output is useful in practical application.

No. You are WRONG. I think (hope) the dev is just making this whole project as a humorous joke...

Look closely, at TFA. Notice anything, that hints at this very premise? No? Take a real good look at the last picture in the "Pipes" section. (Just above "Synchronous Interaction" section). Pay close attention to the highly revered JSON object source code...

{
"foo": "bar",
"meh": "teh",
"lol": "wai",
"list": [ { "lol": "lulz", "fail": "json" } , "wtf" ]
}

Yes...
Meh, LoL wai? LoL, lulz. Fail JSON, WTF
indeed.

Re:Oh, the Hypocrisy

[WWWWolf]

Added complexity, more surface for bugs to appear, 'nuff said.

Well, that's almost true. The problem isn't increased complexity, it's that it's a more complex interface that isn't probably as well defined as the current std{in,out,err} interface is. It's possible to have a more complex interface and make it sufficiently bug-free, but in order to get there, it should be well-defined and not "hackish".

Basically, the bottom line is this: everyone knows Unix shells are limited in what they can display, but this is how they were designed and this is how you're stuck with. It may be simple, but at least we know it has been implemented in a way that we know is hard to mess up. If you want to reimagine how Unix shells operate, you need some pretty big changes in application side and come up with a well-defined, likewise hard-to-mess-up interface.

This isn't to say that such an interface couldn't be implemented with backwards compatibility (just look how well some X11 apps cooperate with command line tools). And, of course, losing backwards compatibility would be foolish because, like it or not, Unix shells do work just fine right now and graphical bells and whistles might not be appropriate for all uses.

Re:Oh, the Hypocrisy

[Anonymous Coward]

Man did his statement go over your head.

HTML and JSON are better than plain text because they have more structure. They're more easily parsed. His whole argument was based on having structured, content-typed output for machines and rendered, human-friendly output for users. Instead of using a compromise that's hard for machines to parse and hard for humans to read.

Humans hose themselves with escaping issues all the time in Unix, probably because the list escapes and the list of characters that need escaping vary based on context.

Quit hating and go back to your terminal if you want - it's not like TermKit is going to take it from you.

Security

[Anonymous Coward]

This seems to be a really interesting opportunity for fun security problems. :)

I mean, from the attacker perspective...

Why more grids?!?

[mothlos]

I don't understand why there is such a push to use grids to display sorted lists. Unity, Gnome 3, Android, Windows Explorer, iOS, MacOSX, etc. (even posix CLI commands such as ls): all of them have default settings to take a list of elements and then break the list up into meaningless rows and display a grid. I find it far too easy to miss important elements in these grids and I observe this behavior in others. Why are grids so damn popular?

Note that in this instance I am not complaining about grids where the user can create an arbitrary organization (such as a desktop not set to auto-arrange), but when the computer is taking a list of items and organizing it for you in a grid.

Re:Why more grids?!?

[Hatta]

This is absolutely correct. It is easier to find an object in a 1d list than a 2d matrix. With a list, you start at the top and move down. You are guaranteed to find your item. With a matrix, you have to reposition your eyes frequently.

Sorted lists are objectively better for usability. Period.

Re:Why more grids?!?

[TobesWSU]

I prefer lists for file browsing with a bunch of files, but to play devil's advocate in a lot of the situations you mention lists would result in a lot of wasted horizontal space.

Re:Why more grids?!?

[spauldo]

You could always put alias ls='ls -1' in your .profile, if lists are your thing. There were a lot of older terminals and systems (including DOS) that didn't have scrolling capability, so the grid layout allowed people to see more without having to resort to using more.

I like the grid layout for most stuff, personally (talking in general, not just in ls), but it might just be because I'm used to it.

I do know that iOS is pretty list heavy once you get off the springboard, and the little I've seen of my girlfriend's Android seems to be the same. On desktop systems, lists are a huge waste of horizontal space, especially given our monitors tend to be wider than they are tall, but I know that in older GNOME and Windows Explorer you can change your view to lists, and I wouldn't be surprised if Unity and MacOS had that option as well.

Awesome

[Anonymous Coward]

Some tool found a way to both reduce contrast AND waste visual space in a text terminal. Ooh, and he got rid of that useless rate and ETA information in wget. Bonus.

Pretty but how practical?

[bl8n8r]

I like the simplicity of Xterm. It works well with SSH, can talk to endless serial devices (like console terminal login on headless stuff) and can run over a modem. All I need is twm and Xterm and I have a nice lightweight X desktop on a server for installing Oracle. There aren't a lot of dependencies so I can keep the software footprint small. Updates are faster and few.

Now in KDE on a desktop, something like Termkit might be more practical. Don't forget though, eye-candy comes at the expense of resources. You can't have all that bling without giving up cpu or ram. In the end, is the payoff worth it to be able to run a screensaver in your terminal?

All the work that went into the Compiz bling; it's cool but I just don't use it. The exploding windows are neat, I just don't see the point in having a desktop that contributes to my distractions.

Re:Pretty but how practical?

[Anonymous Coward]

I do think you're missing half the point of compositing managers (e.g. compiz) - done in moderation, they can be quite neat. Small touches like window shadows actually makes it slightly easier to understand what you're looking at; the more"solid" drawing and updating can be nicer, and I have come to see the use in a zoom-out window presentation for finding one of multiple windows. (Bonus points for letting you type a few letters and only showing windows with matching titles).

As for resource usage, eh. Even if it takes a hundred MB or two extra, that's only a few percent of the total ... and quite often, the machine in question is just a front-end anyway.

Re:Pretty but how practical?

[Anonymous Coward]

On the compiz part: I think you've been dazzeled by the bling bits. The important thing about compiz is that it is offloading the desktop to your GPU, leaving the CPU free to do more important stuff. But the GPU has far more power than you'll ever need for a desktop, so you get the bling "for free". If you don't like the bling, you can turn it off, and you'll still get improved performance out of your computer. ;-)

Re:Pretty but how practical?

[Anonymous Coward]

If you try dwm and st you may never look to twm and xterm again :)

Re:Pretty but how practical?

[Jonner]

I like the simplicity of Xterm. It works well with SSH, can talk to endless serial devices (like console terminal login on headless stuff) and can run over a modem.

I think you're confusing xterm (one of many X11 terminal emulators) with the shell (typically Bash) running inside it. The shell is what accepts commands you type and interprets them. Terminal emulators only display the output from programs such as shells and ssh and forward keys you type to those programs. Any X11 program, including xterm can run on a remote machine and display on the X11 server controlling your display, but it would be a foolish waste of network bandwidth to run an xterm remotely rather than running just a shell remotely via ssh running in the terminal emulator.

Everything is an INCOMPATIBLE object

[mangu]

Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object'

The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them. With plain text you can see the data structure at a glance, you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

Plain text is output to the screen and input from the keyboard. Any program that writes text to the console can send data to any program that reads text from the keyboard. This means development and testing is simple, you do it one module at a time, type the input and watch the output. And you can very easily combine different programs in a way that no one tried before.

I don't think powershell offers any advantage over the way Unix has been working for forty years.

Re:Everything is an INCOMPATIBLE object

[Anonymous Coward]

You don't know what you are talking about. Standard .Net objects are mature and widely supported and if you do run into a case where you need them to be human readable it is trivial to get them in text form,

Re:Everything is an INCOMPATIBLE object

[amliebsch]

Every object has a mandatory .ToString() method, so that ultimately every object can be boiled down to plain text if you want to. Between this and a liberal use if IEnumerable interfaces, a basic formatter can make sense out of a staggering number of objects.

Re:Everything is an INCOMPATIBLE object

[Anonymous Coward]

'Objects' have this terrible problem that you always need a specific program to read and write them.

Except that in PowerShell all of the objects are reflective and automatically have a textual representation, even if one is not provided by the author.

With plain text you can see the data structure at a glance, you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

Being reflective you can also see the data structure instantly, clearly defined by type, even if the author never wrote any documentation. Moreso, as all programs are similarly reflective, you can tell all parameters that it can accept as well as all data that it can return without documentation.

Plain text is output to the screen and input from the keyboard. Any program that writes text to the console can send data to any program that reads text from the keyboard.

PowerShell programs are fully capable of streaming text as well as intermixing object streams with text streams.

This means development and testing is simple, you do it one module at a time, type the input and watch the output.

As you can in PowerShell.

And you can very easily combine different programs in a way that no one tried before.

As you can in PowerShell, except that you don't have to concern yourself with additionally parsing and reformatting those text streams in order to allow them to be consumed. Moreso, as virtually all of the object models that exist within Windows is available within PowerShell as objects, including WMI, LDAP, COM and .NET, you can combine disparate libraries into a single command line treating all objects as equals and without having to write any additional plumbing code.

Re:Everything is an INCOMPATIBLE object

[Anonymous Coward]

How about "everything is a doorstop"?

Re:Everything is an INCOMPATIBLE object

[deoxyribonucleose]

Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object'

The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.

...

I don't think powershell offers any advantage over the way Unix has been working for forty years.

You know, check it out. Everything actually has a text representation as well, which anyone who doesn't understand a particular object-with-values can drop back to. Despite what you may think, sometimes Redmond actually can innovate, and do it well.

Well,,, apart from the language still having no formal specification and (therefore?) some unfortunate irregularities in the implementation. That's one thing they really didn't have to copy off other shell languages!

Re:Everything is an INCOMPATIBLE object

[benjymouse]

The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.

Not true. Objects can be rendered on the terminal as well. PowerShell does this all the time. For some object types a certain format/method has been registered, but for all other types PowerShell just falls back to default rendering - which is to render the properties. You don't need *any* specific program to write objects in PowerShell. Never. One distinct advantage of this is that you can actually *choose* exactly how you want the objects written without relying on each and every little CLI tool to include a whole battery of output options.
ls|ft lists files/dirs in a table (ft is alias for Format-Table): Each property in its own column.
ls|fl lists files/dirs in a list (fl being an alias for Format-List): Each property on its own line.
ls|fw lists files/dirs in "wide" format (fw is an alias for Format-Wide): Multiple columns with just the name.
The cool thing is that ps|fl works similar: It lists processes with properties on separate lines.

you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

PowerShell builds upon .NET, COM and WMI, which are all models which supports discoverable objects. One of the first cmdlets a powersheller learns is the gm cmdlet. gm is an alias for Get-Member. This cmdlet reflects and documents the types with properties, methods, events etc of the objects piped to it on the command line. No need for external out-of-date documentation.

This means development and testing is simple, you do it one module at a time, type the input and watch the output. And you can very easily combine different programs in a way that no one tried before.

Well, that is the same way with PowerShell. Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal using the default or registered format (or you can control the format). But PowerShell takes it a few steps further, e.g. defining common infrastructure for transactions as well as risk control such as executing all cmdlets in simulated "whatif" or "confirm" mode in a unified way and based on context so that cmdlets executing within a script will inherit the mode from the script invocation. The fact that *all* cmdlets support the -WhatIf parameter lets you try out even potentially state-changing scripts and cmdlets before actually executing them.

I don't think powershell offers any advantage over the way Unix has been working for forty years.

Frankly, based on the above it doesn't seem like you know enough about PowerShell to pass that judgement. And having worked for forty years doesn't mean that it cannot be improved. I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.

Re:Everything is an INCOMPATIBLE object

[oakgrove]

Everything actually has a text representation

Half of the power in Bash is the ability of the various commands to not only output to text but to take their input as common text from standard in or a file. Usually the text is passed around and filtered between several discrete commands before whatever it is you are doing is accomplished. In PowerShell, can text be passed around, piped, grepped, sorted, etc. as well as in Bash?

Re:Everything is an INCOMPATIBLE object

[Anonymous Coward]

> 'Objects' have this terrible problem that you always need a specific program to read and write them

Clearly you've been brainwashed by C++ morons to think C++ "objects" are objects at all. Real OO-systems are thoroughly inspectable.

Re:Everything is an INCOMPATIBLE object

[benjymouse]

Well,,, apart from the language still having no formal specification and (therefore?) some unfortunate irregularities in the implementation.

The language specification: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=509b77d0-5e5f-4194-a2d0-61648abfd093

What irregularities? Could you give some examples, please. Honest question here - I'm not claiming that PowerShell is perfectly regular and I would appreciate any insights.

Re:Everything is an INCOMPATIBLE object

[deoxyribonucleose]

Half of the power in Bash is the ability of the various commands to not only output to text but to take their input as common text from standard in or a file. Usually the text is passed around and filtered between several discrete commands before whatever it is you are doing is accomplished. In PowerShell, can text be passed around, piped, grepped, sorted, etc. as well as in Bash?

As I said, take a look at it. With three decades of use and development behind it, I'd expect Unix to have several tools which haven't been replicated for PS. Yet. But there's nothing can't be done (since everything also is text), and quite a number of things that can be done a great deal more easily and robustly, thanks to being one level of abstraction higher than raw text.

A good idea is a good idea, no matter its source.

Re:Everything is an INCOMPATIBLE object

[deoxyribonucleose]

The language specification: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=509b77d0-5e5f-4194-a2d0-61648abfd093

I sit corrected. This is great news -- I think I checked last autumn.

What irregularities? Could you give some examples, please. Honest question here - I'm not claiming that PowerShell is perfectly regular and I would appreciate any insights.

Sorry, I may just be rumour-mongering. Something I read over at StackOverflow, I think... and can't find it now. Confession: I've mostly been admiring the idea of PS rather than cutting my teeth on any serious hacking around.

Re:Everything is an INCOMPATIBLE object

[mangu]

Objects can be rendered on the terminal as well

Rendering them is different from the object itself.

Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal

Again, rendering is not the object. I can have a list of different operation I need to do, passing things from one program to the other. If all I can see is the rendering of the last command I cannot see what is actually being passed from one command to the next one.

Developing is incremental. The power of Unix is that this simple fact is everywhere. I need to see all the processes:

ps aux

Which ones are owned by boris?

ps aux | egrep '^boris'

What are the process numbers and creation time?

ps aux | egrep '^boris' | awk '{print $2, $9}'

OK, sort that by process number

ps aux | egrep '^boris' | awk '{print $2, $9}' | sort -n

In Unix I build up my commands step by step. What I learn in one place can be used somewhere else. The same sort command I use for process numbers is the one I use for my phone book.

If I can't remember exactly how awk works I can test it by typing

echo "1 2 3 4 5 6 7 8 9 10 11" | awk '{print $2, $9}'

It would not work if 'echo' showed a representation on the terminal that is not exactly the same thing it pipes to 'awk'

I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.

That's a shortcoming of windows, not an advantage of powershell.

Re:Everything is an INCOMPATIBLE object

[NullProg]

Despite what you may think, sometimes Redmond actually can innovate, and do it well.

Trouble is Redmond didn't innovate. Powershell is a weak copy of IBM OS/2 Workplace Shell / System Object Model (SOM).

See here: http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%5CToolkt40%5CWPSGUIDE.INFl

Enjoy,

Re:Everything is an INCOMPATIBLE object

[wasabii]

Every example you just posted requires you to actually examine the output of each of the commands, and apply brittle and convolted text parsing structures like grep and awk. All of if these break when the author alters the output text format. PowerShell has none of those limitations. If an author of ps adds a new property to each object, he does not need to be concerned with previous users of his cmdlet, because nobody is actually parsing his output. His output is strongly typed objects. If a previous user didn't consume his new property, it doesn't matter, they'll continue to not consume it.

Instead of building scripts based on brittle text parsing, they are built on a self documenting model that provides. There is no text parsing. That's extra work. Why do it?

Re:Everything is an INCOMPATIBLE object

[wasabii]

And if your last statement is to say that object orientation is somehow inferior to an OS based on poorly defined text output, then you've just pretty much written off most of computer science since the '70s.

Re:Everything is an INCOMPATIBLE object

[benjymouse]

Trouble is Redmond didn't innovate. Powershell is a weak copy of IBM OS/2 Workplace Shell / System Object Model (SOM).

IBM OS/2 Workplace Shell is nothing at all like PowerShell. Did you see the word "object" and just assumed it had to be the same thing or a copy of it?

Is it because you cannot tolerate the mere thought that somebody at Redmond actually came up with a cool innovation over the traditional shells?

Re:Everything is an INCOMPATIBLE object

[amliebsch]

In powershell it is basically the same, except you can filter and sort with anonymous methods. So, for examle,

ps | where-object {$_.Processname -eq "iexplore"}

The neat thing about this what you are piping out the end is objects, not something like a list of PIDS. Now, this is an array (IEnumerable) of objects, so Powershell will automatically use a Format-Table that shows the objects and their properties.

[Censored by stupid junk filter]

  But it's still objects being piped out the end, so you can execute methods directly on them, e.g.:

ps | where-object {$_.Processname -eq "iexplore"} | foreach-object {$_.Kill()}

With the expected result.

Re:Everything is an INCOMPATIBLE object

[oakgrove]

Every example you just posted requires you to actually examine the output of each of the commands, and apply brittle and convolted text parsing structures like grep and awk.

Translation: it's foreign to me and I don't want to learn it. There is nothing convoluted about any Unix command once you learn how to use it. Grep and awk are second nature to many people. That's a particularly weak and, quite frankly intellectually dishonest argument when presented to expers and power users like many people on Slashdot are.

All of if these break when the author alters the output text format.

The core utilities have been going strong for 30-40 years and most changes have only added features not taken old ones away. You have no idea what the future has in store for PS so that too is a weak argument.

Instead of building scripts based on brittle text parsing, they are built on a self documenting model that provides. There is no text parsing. That's extra work. Why do it?

There is nothing PS can do that can't be accomplished by streams of text. The Unix model is very simple, every argument I've seen against it has amounted to little more than strawman bs,and unlike your flavor of the week utility, it will be here long after we are all long gone.

Re:Everything is an INCOMPATIBLE object

[Anonymous Coward]

Translation: it's foreign to me and I don't want to learn it.

So far that seems to be the only argument being made against PowerShell.

Look, nobody here is arguing that PowerShell is better than bash or other shell scripting environments. It was brought up only because this TermKit project seems to share similar aspirations. Then a hoard of people got wind that something that Microsoft was involved with was mentioned somewhere and felt the need to poo-poo it with arguments that are fully demonstrative of ignorance of the product and how it works.

Lastly, as mentioned, PowerShell works just fine with stdio as output by any normal process. All of its functionality is a superset of what is available in UNIX scripting. In either case, the power lies not with the shell. That serves only as the glue to compose other utilities together.

Re:Everything is an INCOMPATIBLE object

[oakgrove]

Is it because you cannot tolerate the mere thought that somebody at Redmond actually came up with a cool innovation over the traditional shells?

I think it's more the arrogance and presumptuousness with which you PS boosters speak of its supposed superiority as if it is a forgone conclusion. We get it, you like it. It uses objects. Some people prefer the text stream and don't see the objects as superior. I know, what a concept, right? For people well versed in bash, grep, awk, cut, sed, etc. are very comfortable and efficient tools. You people remind me of the mono-ites that just can't bear the thought that someone doesn't see your pet project as the holy grail of computing.

Re:Everything is an INCOMPATIBLE object

[oakgrove]

Look, nobody here is arguing that PowerShell is better than bash or other shell scripting environments.

Yes. Yes, they are. And the arrogance and presumptuousness is quite galling. That is why you are getting the backlash.

Lastly, as mentioned, PowerShell works just fine with stdio as output by any normal process. All of its functionality is a superset of what is available in UNIX scripting. In either case, the power lies not with the shell. That serves only as the glue to compose other utilities together.

No it is not. PS does not have the ability to parse text and pass it to stdin like the bash utilities cut, grep, sed, awk, xargs, etc. can.

All of its functionality is a superset of what is available in UNIX scripting. In either case, the power lies not with the shell. That serves only as the glue to compose other utilities together

Fine, it's a superset. Ipython is a superset of bash which wipes its ass with powershell every day of the week and twice on Sunday.

Re:Everything is an INCOMPATIBLE object

[oakgrove]

ps | where-object {$_.Processname -eq "iexplore"} | foreach-object {$_.Kill()}

Golf clap. Bash:

$ killall firefox

Re:Everything is an INCOMPATIBLE object

[Anonymous Coward]

PS does not have the ability to parse text and pass it to stdin like the bash utilities cut, grep, sed, awk, xargs, etc. can.

It sure as shit can.

get-process | egrep '\bnotepad' | set-content -Path notepad.txt

That calls the PowerShell cmdlet get-process, pipes the output using the default rendering over stdout to egrep from cygwin which then pipes stdout right back to the PowerShell cmdlet set-content. Couldn't even bother doing the most basic research on the subject?

Re:Everything is an INCOMPATIBLE object

[wasabii]

Translation: it's foreign to me and I don't want to learn it. There is nothing convoluted about any Unix command once you learn how to use it. Grep and awk are second nature to many people. That's a particularly weak and, quite frankly intellectually dishonest argument when presented to expers and power users like many people on Slashdot are.

I know them. I've been using Linux since the mid 90's. i write kernel drivers for fuck's sake. PowerShell commands are self discoverable. Man pages are auto generated from thedocumentation stored with the commands themselves. If anything is weak it's your argument that I don't know the commands.

The core utilities have been going strong for 30-40 years and most changes have only added features not taken old ones away. You have no idea what the future has in store for PS so that too is a weak argument.

Well, you just made my point for you. In that sentence you acknowledge that I'm right. Only a small set of core utilities have had non-altered output for the last 30 years. I'd like to point out that 'ps' at least has been altered a few times in the last decade. ifconfig, same. Replaced with 'ip'. So you admit, Unix utilties break when the author changes them.

My entire point about powershell was that you don't have to know what changes are in store in the future. Didn't I mention that? You can add properties without requiring downstream users to be concerned with it. That's the point I made. You missed it, I guess.

There is nothing PS can do that can't be accomplished by streams of text. The Unix model is very simple, every argument I've seen against it has amounted to little more than strawman bs,and unlike your flavor of the week utility, it will be here long after we are all long gone.

There's nothing that C can do that can't be accomplished in assembly. Really? This isn't even an argument. It's a basic fallacy.

Re:Everything is an INCOMPATIBLE object

[wasabii]

Cool. So how do I kill all processes consuming more than 800MB of RAM?

Re:Everything is an INCOMPATIBLE object

[wasabii]

ps | where-object {$_.VirtualMemorySize -gt 800000000} | ForEach-Object { $_.Kill() }

Re:Everything is an INCOMPATIBLE object

[wasabii]

Bad question. Consider it "with a vmm size > 800Mb"

Re:Everything is an INCOMPATIBLE object

[benjymouse]

ps|?{$_.vm -gt 800mb}|kill

Re:Everything is an INCOMPATIBLE object

[oakgrove]

$ ps -eo pid,rss | numgrep /800000..80000000/ | kill `cut -f1 -d' '`

Re:Everything is an INCOMPATIBLE object

[renoX]

>> Objects can be rendered on the terminal as well
> Rendering them is different from the object itself.

There is a similar issue with the text passed in Unix pipes: think about space vs tab, characters which have several encoding, etc.

The mapping between the displayed text and what is passed in the 'pipe' is never 1 to 1, you learned to deal with it in Unix, I don't think that this is more difficult with the PowerShell.

Re:Everything is an INCOMPATIBLE object

[deoxyribonucleose]

Despite what you may think, sometimes Redmond actually can innovate, and do it well.

Trouble is Redmond didn't innovate. Powershell is a weak copy of IBM OS/2 Workplace Shell / System Object Model (SOM).

See here: http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%5CToolkt40%5CWPSGUIDE.INFl

Enjoy,

Cool, I thought, some prior art. Then I actually looked: Workplace Shell is about traditional GUI applications programming, not shell scripting, and at least from your link did nothing to even support passing objects around in a pipes-and-filters design (much less propose object based pipes-and-filters as the primary design principle). Nope, until further notice, Redmond is still officially innovative.

Again, try it out. Text manipulation has its strengths, but the more tools you are able to use, the more problems you are able to solve.

Terminal Emulation?

[yarnosh]

Maybe if it could emulate a plain color terminal so I could run things like vi, screen, etc. But only being able to type commands seems a little restrictive.

You missed the biggest advantage

[Alef]

You missed the biggest pro of them all, central to the Unix philosophy: Composition of simple tools to do complex tasks.

With a GUI, you are bound to whatever the GUI designer has included, and basic features are replicated endlessly in different GUI:s. For example: If I want to process five files with some program in a command line, I can list them with ls or find, type them manually, or cat the list from a file, just to name a few ways. With a GUI, you often have only the Open File Dialog, built right into the processing program, and that's it. In that case, creating the list of files is not separated from processing them.

Re:You missed the biggest advantage

[overlordofmu]

+1 for you

And it is written in/uses java/javascript?

Let me get this straight. He doesn't like wasting pixels. So, he re-imagines a time tested tool that uses MORE pixels to display the same data. Now it does display non-text in the terminal, but why? If you already have a GUI (which you must for this CLI) why not "xdg-open FILENAME" instead of "cat FILENAME"? And it wastes CPU cycles with a pointless java abstraction when it could run on the bare metal.

All I see is it doing is the exact opposite of its inferred goal of using pixels more efficiently while introducing a GUI/java dependency when there is normally no need of it.

Less flexible, requires a GUI, runs more slowly than native machine code all while doing nothing new. I agree that it looks very nice, but it sacrifices function for the sake of its form.

This appears to me to be a pretty toy and an interesting proof of concept but ultimately a step backwards. Am I missing something?

easy graphic output

[fusiongyro]

This seems to be completely the wrong crowd for this development (it is hugely upvoted on Reddit, though), but one reason this may be an improvement is simply that it can combine the speed of writing a command-line program with the visual appeal of a web or GUI application. Speaking personally, there are many times I write a command line program simply because I don't want to invest the time and effort in a GUI program and a web app just isn't appropriate for the task. With this system, I could just output HTML instead of text, and now I've got a nice looking semi-graphical app that's still quick to write and easy enough to use.

View out Vs. Data out

[theunixbomber]

I'm not sure I'm getting the view out and data out thing. I guess I understand the idea, but if I'm seeing different output then what the next command in the pipe chain is seeing, then how do I know that its receiving the right data in the right format?

will suck up too many resources

[Anonymous Coward]

will suck up too many resources

What are you using? A 66mhz g3?

Balls to TermKit

[ilikejam]

Unix is meant to be difficult - it keeps idiots out of the datacentre.

Ha ha, only serious.

Information density

[Lulu of the Lotus-Ea]

The reason terminals are so useful is because they have greater usable information density than really any other interface. The article desperately misses this in its lead about the 2.3 megapixels of display space, and the presumed potential information content. But a terminal has quite a lot of information in it! Far more information--from a human usability POV--than the oversized icons this TermKit uses to adorn every small bit of textual information.

For example, on my MacBook Pro, using a pretty large font size, I run a 90x48 terminal (with multiple tabs, but that's a different issue). This terminal occupies approximately half of my display (sometimes I put another one next to it, though there's slight overlap at my screen size, font size, frame elements, dock/menu bar, etc). Now, as we can see using the 'calc' utility I wrote for systems I work on:

    505-Documents % calc 90x48 # result on stdout, canonical form of expression on stderr
    90x48
    4320

Well, 4k-ish characters isn't that many positions (but it's not tiny already), but each of those characters might be any of approximately 256 values. Saying exactly how many it is is a little tricky though. Many of my tools (e.g. the bash prompt itself, ls, less with lesspipe, vim, etc) colorize output, making for multiple easy distinguishable ways the letter 'A' might appear. On the other hand, while high-bit characters are not generally usefully or frequently displayed, modern terminals *do* display many thousands of Unicode characters potentially. So as an approximation, we might say that there are approximately 1.1M easily distinguishable states of my terminal. I know, of course, that, most of the time most of the characters that display are along the left edge of my terminal, and the right side is largely blank. But nonetheless, there are at least a couple 100k states that are both plausible and importantly EASILY distinguishable... not *instantly* distinguishable, of course. Obviously, my eyes need to flit back and forth a while to compare, say, the file sizes and permissions of a bunch of things that show up in an 'ls -l' display. But it is still at least an order of magnitude more information than I'd discern with equal ease using TermKit (or, say, using a GUI file manager like Finder) to look at the same 'ls -l' directory.

Obviously, the theoretical information content of a high-res display is enormous. If I even have a 16-bit display, running somewhere over 1.5 megapixels (my screen is apparently slightly lower res than Steve Wittens') that's something like... well, more than the number of particles in the universe, possible states (e.g. (2**16)**(1680*1050)). But in fact, as a human, I really can't meaningfully distinguish nearly any of those states. I can't even *see* individual pixels, nor distinguish very close colors very well. But even within my actual perceptual threshold, I cannot give direct meaning to a slight color difference in some small part of the GUI screen, except in very broad categories that contain a few bits of information each. My recognition and discernment of the meaning of *characters* of my native language is far greater than some other graphical abstraction.

Re:Information density

[Lulu of the Lotus-Ea]

Oops... my case is actually FAR stronger than I wrote. The actual number of distinguishable states of my terminal isn't 256*4320. It is 256**4320. Which is to say, around 4e10405. That is also VASTLY more than the number of particles in the universe, which is a measly 1e84 or something.

Re:Close, but no Cigar...or Cigarette, either

[Anonymous Coward]

The *nix philosophy can be more accurately stated as "Everything is a file, except when it's not, and the meaning and syntax of the file can only be understood by examining the source code of all the programs that might potentially want to read or write it, as well as all the documentation, and location of the file in the file system hierarchy, and the ownership of the file and the permissions on the file, and what kind of filesystem it's sitting on, and how the filesystem was mounted, and by the way, and streams aren't files and files aren't streams, and it's not very consistent between various *nix variants." OK, that's files, now let's rant about programs' I/O, which is even more random. :-)

You COULD make everything neat and parseable and self-descriptive and consistent, but then it wouldn't be like UNIX(tm), it would be a Plan-9y sort of thing.

ToString

[mangu]

Every object has a mandatory .ToString() method

Two possibilities:

A) ToString lists exactly all the properties of the object. Then *why* have the object at all, why not use the string itself?

B) ToString does not list exactly all the properties of the object. So, what if you need something that ToString does not list?

I see this problem with Python objects, they have a __str__ method and a __repr__ method. They are useful as a reference, but they are often incomplete. Unless you have a good documentation you cannot rely on them.

Re:ToString

[amliebsch]

A) ToString() will usually return the "obvious" string representation of an object if there is one (such as the localized date time of a DateTime object). Otherwise, it will return the name of the object type. The full list of properties is always available through reflection, so you can query an object and get a list of its properties, in case you are looking for something other than what ToString() returns.

B) Then you request the property by name. Example, if you want the integer year of a date instead of its full localization, you request $Date.Year instead of just $Date. As an alternative, you can pipe objects to a formatter, like Format-List, which will show a Property:Value list of all the object's properties.

Documentation is not as much of an issue because you can take an object and pipe it to "gm" (or "get-member") to see a list of its public properties and methods via reflection, or with the formatter as above.

I think I see another commercial in the making

[Anonymous Coward]

I don't always re-implement basic Unix commands, but when I do, I do it in javascript.

Re:I think I see another commercial in the making

[MROD]

Surely these days it's, "I don't bother re-implementing basic Unix commands, I write a hardware emulator in Javascript and boot a new copy of Unix in it."

Having a somewhat similar idea

[harry666t]

Having a somewhat similar idea.

Well, not exactly, but it's been a long time since I've suspected that there is something fundamentally flawed about the idea of having a cellular grid of glyphs trying to pretend that it is a teletype.

The first problem is that no input (no new commands) is accepted while a previous one is still being executed. Of course shells allow the user to place a job in the background, but if it outputs any text (or does some tricks to update text that is already on the screen), your input and output are melding into a mess.

Another thing is that there are layers of abstraction over the raw terminal emulator interface, like readline or curses. The first tries to make editing a command a smaller pain, the other one's role is essentially to turn the terminal emulator running on top of a grid of character cells... back into a grid of character cells.

I think it's time to get rid of terminal emulation. It's 2011. I consider myself a Unix geek (of a younger generation), and I haven't seen a real serial terminal even in a museum. Of course I'm sure that some of you guys have one at home, maybe even hooked up to your box's serial port. But hold on, because what I'd like to propose would be backwards compatible - it could easily be emulated on top of curses, and still would be able to be interfaced with via stdin/stdout/stderr.

Well, the idea is to take our 80x25 grid of characters and provide a completely raw, low-level API to it. API like, "put glyph 0x41 in position 0,0". curses can do that, but it's two unnecessary layers of abstraction, so better just take an X terminal emulator, rip out all the terminal emulation code, and provide THAT api over it. Now, the second step is to let a library manage this area - if you want to emulate a VT100, just put a VT100 widget in there. If you want to run a curses-based program, it would make sense to port ncurses to use this backend. But the most interesting thing (IMHO) is the new (old) text user interface that I've conceived.

Basically you have your cellular grid split into two non-overlapping areas, one short at the bottom, and one tall, taking up the rest of the vertical space. The bottom one is an input buffer, the other one holds the output. Seems familiar? Of course, that's how all chat programs and IRC clients have been looking like since the beginning of the time. Also, this resembles how Emacs handles its minibuffer, or if you stretch the idea even further, that's the relationship between dmenu and the rest of your X display. So it's a well-tested paradigm.

So, what else exactly does it change? As I said before, you can run all of your commands automatically in the background, and they could keep updating the output with useful information as they go. No more need for readline - or rather, it would get integrated with the input buffer. Or possibly something else, I suspect that it would be quite possible to embed an Emacs or Vi buffer in there. Also, as the output buffer is just a widget reading commands' stdout&stderr, we could let it interpret the output and format it in various ways.

There is lots of lots of really fancy stuff that one could possibly do with such an UI. The raw grid area could be split into more areas, so that you could have all sorts of statusbars or sidebars displaying realtime stats (like screen or tmux do). If the terminal window is running over a graphical display, I would dare to say that doing what TermKit does would be even funny&profitable (although I'd probably do many things differently than TermKit... I have a deep hate for all things web). It could be abstracted to let software run unchanged both under graphical and text-based displays.

I have lots of other funny ideas in my mind, but can't really shape them into words (or code) yet.

Re:Having a somewhat similar idea

[Anonymous Coward]

Basically you have your cellular grid split into two non-overlapping areas, one short at the bottom, and one tall, taking up the rest of the vertical space. The bottom one is an input buffer, the other one holds the output. Seems familiar?

Sounds like the terminal emulator on Apollo's Domain workstations. . . I think it was called "pad"? You could freeze the bottom input area to compose a complicated, multi-line command, then release it to allow the input to go to the shell. It was great when constructing a for loop on the fly. The bottom input area would also not submit the input until the previous command finished running. And so you could also take your time editing a command while something was spewing output. It was kind of neat, actually.

Re:Having a somewhat similar idea

[VortexCortex]

Another thing is that there are layers of abstraction over the raw terminal emulator interface, like readline or curses. The first tries to make editing a command a smaller pain, the other one's role is essentially to turn the terminal emulator running on top of a grid of character cells... back into a grid of character cells.

You have very good ideas... They've been around for a LONG time. Great minds think alike. Ncurses let's you do all of what you're talking about, but you have to write some code to achieve the effects -- the terminal(emulator) just displays text/color/styles, it's up to the application (in this case the command shell, BASH?) to provide the features you're looking for....

With ncurses you can create movable, overlapping windows with "drop shadows" (darken background of bottom & right bordering text), independent scrolling areas, progress bars, animations, simple-music/sound effects, Space Invaders, Brickout, Tetris, etc. all able to interface with the keyboard & mouse (if the terminal supports it: see terminfo). In fact, text based GUIs, and even ANSI art were the norm just prior to the Internet/HTML explosion... For my late 80's / early 90's era BBS I coded up just such a windowed interface (sans mouse input) for "high speed" 14.4Kbps users -- It had features today's Web2.0 sites are just now catching up to (I still have CP437 committed to memory as a result).

Don't worry, you're not the only one who wanted to re-design the system... I wrote half of a terminfo parser (to detect which escapes to use for the features the terminal supports) to achieve similar ideas myself before I discovered ncurses -- Hey, I didn't know any better; I was a newly converted *nix user / MS DOS hold out & reluctant Win user at the time... Now, I've learned that the biggest part of being a "unix geek" is communicating with & hanging out with other "geeks" (esp. online) -- Sometimes the geek network is much better than any other search engine (New-fangled "social networks" have just recently begun to capitalize on these effects).

Well, the idea is to take our 80x25 grid of characters and provide a completely raw, low-level API to it. API like, "put glyph 0x41 in position 0,0". curses can do that, but it's two unnecessary layers of abstraction, so better just take an X terminal emulator, rip out all the terminal emulation code, and provide THAT api over it. Now, the second step is to let a library manage this area - if you want to emulate a VT100, just put a VT100 widget in there. If you want to run a curses-based program, it would make sense to port ncurses to use this backend. But the most interesting thing (IMHO) is the new (old) text user interface that I've conceived.

Well... Get to Coding! (just kidding, you actually don't have to). However, if you did start out on such a project (as I did) you would realize why there are so many messed up layers -- it's for backwards / forwards / cross-terminal compatibility. I was a die-hard DOS coder, I feel your pain -- My DOS text GUI applications had access to the text memory buffer: Every other byte was a FG/BGcolor&blink byte, with character bytes interleaved (ASCII +cp437), and it was simple. A breeze to work with, but it wasn't very cross platform.

Perhaps you would like to check out GNU Screen? (Since it does just about everything you mentioned).

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. Each virtual terminal provides the functions of the DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g., insert/delete line and support for multiple charact

Re:Having a somewhat similar idea

[harry666t]

Hi, first, thanks for your reply :D

I think you didn't get all of my ideas. I know both ncurses and screen and for me they are signs that the basic concept (layers upon layers) is flawed. I think I'm too young to say I remember DOS well, but I've been playing with toy kernels and writing directly into memory under 0xb8000. I even wrote some kind of a very dumb terminal emulator.

So, look, for example. If such "splitted terminal" would be the primary interface provided by Linux right after boot, in the text mode, we could ask the user for login credentials while the rest of the system is booting (like starting XDM before any other services, but come on, XDM (and other DMs) sucks). This of course would need lots of changes in the kernel, and then probably a new /bin/login. On the other hand, the shell wouldn't need any changes (maybe except spawning it with a "run non-interactively" flag, so that it doesn't display prompts or load the command completion code). Well, and yes, command completion, editing, etc would need to be provided by a plugin in the input buffer, not by the shell itself.

> It's the command interpretor shell that does IO with the terminal,
> and it doesn't have to be re-written: It can be wrapped in another
> layer and/or extended to add even more features.

Nyet, I don't think so. In my opinion, it breaks the "one tool for one job" rule of Unix, and features should be *removed* from it. So it provides a language for scripting and for command execution, AND provides completion, editing, etc. Ever tried to switch to a less-mainstream shell, like Plan9's rc? rc as a language is superior to sh in almost every aspect (save for backwards compatibility), but its line-editing, history and completion capabilities are severally lacking. But let's say you move all of that functionality to the terminal's input widget. The widget would just look at the grammar of the shell (you still need to tell HOW to complete stuff...) and that's it. If somebody is willing to spend some time hacking a completer for it, you could even run Perl as your login shell, with zero changes to the executable.

> Well... Get to Coding!

I will, not kidding.

I like the suckless.org philosophy. They create lots of very small, neat, high quality software, while taking care to keep the design simple and the source code understandable. Never thought I'd be running a window manager with my own patches, but here I am with dwm (http://dwm.suckless.org/). Oh, and they have a terminal emulator in under 2000SLOC of C (http://st.suckless.org/). I guess the "rip out the VT100 emulation and see where can we go from there" part is one boring evening away (not tonight - we're gonna drink vodka).

> However, if you did start out on such a project (as I did)
> you would realize why there are so many messed up layers --
> it's for backwards / forwards / cross-terminal compatibility.

One nice thing is that every well-written program should already support this kind of terminal. If it knows what TERM=dumb means, and if it uses standard isatty(3), there's nothing more to be done to get it working. Actually I just ran "aptitude update|cat" to see if it behaves properly when it can't assume it's OK to update something it already printed, and it ran just fine. Even "aptitude dist-upgrade|cat" behaved like a good citizen when it had to ask questions interactively.

Moreover, Unix seems to be a very flexible toy. You'd think that using svscan (http://cr.yp.to/daemontools/svscan.html) as a drop-in init replacement shouldn't work, right? Well, there's a guy that just hacked some additional initialization&shutdown scripts and it seems to work (http://code.dogmap.org/svscan-1/). Regarding terminal-oriented programs, I recently wrote a simple script that would use Google to translate its stdin into another language. Then wrote a simple GTK program with three buffers, one to type in a command, one which's contents are sent to command's stdin, an

Geek

[spam4rakesh]

I am a geek and thats just my *character*

yo dawg, I heard you like CLIs...

[Thud457]

Anybody who is housemates with cats knows full well there there is more than one output path.
STDIN frequently doubles as STDERR.

GUI and CLUI: Two Great Tastes ...

[gilgongo]

I've often wanted to have a CLUI that works with my GUI. Imagine I'm in Photoshop, mousing or tablet-ing away, and I have a layer on my canvass. Rather than trying to remember where in the menu structure a bunch of commands are in order to manipulate that layer, I just bring up my CLUI and type something like "resize 50%, flip, gamma -20" Or how about in Word: "Find foo replace bar, insert header from page 2-", and so on?

Why are we forced to find commands in mouse-driven menu bars (of worse, "ribbons" and whatnot) when they could be available any time in the app you are using?

Re:GUI and CLUI: Two Great Tastes ...

[Anonymous Coward]

You mean like the quake console:

(almost dead)
[Esc]
give health
give ammo
[Esc]

Whew! I may be a cheater, but I'm alive.

Re:GUI and CLUI: Two Great Tastes ...

[Anonymous Coward]

I've often wanted to have a CLUI that works with my GUI. Imagine I'm in Photoshop, mousing or tablet-ing away, and I have a layer on my canvass. Rather than trying to remember where in the menu structure a bunch of commands are in order to manipulate that layer, I just bring up my CLUI and type something like "resize 50%, flip, gamma -20" Or how about in Word: "Find foo replace bar, insert header from page 2-", and so on?

Why are we forced to find commands in mouse-driven menu bars (of worse, "ribbons" and whatnot) when they could be available any time in the app you are using?

There are "actions" in Photoshop and "macros" in Word that do this, although they're not quite as fluid as what you're proposing.

Engineering apps like Simulink often have a command line that works just like that. It's pretty neat, but you usually end up sawing your commands in a file anyway.

Re:GUI and CLUI: Two Great Tastes ...

[jordan_robot]

Agreed. I've been wanting this for a while; sort of like an autocad cli interface for the os (which is imho one of the most efficient interfaces ever). Unfortunately, my programming skills are limited to scripting languages, basic C and lisp. I have very little idea where to start to implement a true system like this. And that's just at the system level, it doesn't even get into making this interface work with other applications. The best I can think is to hack a macro system that sends keypresses to the application in question, but having to change focus back and forth would be a pain. And the most beneficial aspects of this system (specifying specific values for certain commands) would be impractical to send to the application. Add to that many application commands and tools don't have shortcut key equivalents. If anyone else has other thoughts, please let them be known.

Re:GUI and CLUI: Two Great Tastes ...

[Anonymous Coward]

Maya does this in the extreme, and is awesome for it...

Re:GUI and CLUI: Two Great Tastes ...

[drewm1980]

There are people who memorize key commands for accessing menu items so thoroughly that they use the keyboard almost exclusively even in gui programs. Also, there ~are programs with a build-in application specific shell; cad programs have a long tradition of this. Gvim is also a good example, illustrating both a built-in shell, as well as menus that make a wide variety of commands easily discoverable for noobs.

Re:GUI and CLUI: Two Great Tastes ...

[Anonymous Coward]

Or you could use keyboard shortcuts "Find foo replace bar" is a simple CTRL+H foo TAB bar ENTER

Re:GUI and CLUI: Two Great Tastes ...

[Anonymous Coward]

* Vim,
* Vimperator and
* ViEmu

Re:GUI and CLUI: Two Great Tastes ...

[Anonymous Coward]

It's been said that Google is the best example of such a modern CLI. But parsing is famously hard, or in other words, humans suck at CLIs. For starters, the approach you suggest is troublesome with i18n. There are two main options: either you do or you don't. Microsoft Office tried it, with the result that their Excel files were incompatible between different versions. If you don't, your German customers will also have to use "resize 50%, flip, gamma -20" even though the "resize" menu option is called "Größenänderung" there.

Re:GUI and CLUI: Two Great Tastes ...

[snadrus]

Some of my first GUI experiences was learning AutoCAD. Along with the Mouse UI, type always goes to the command line on the bottom. Simple commands there visibly enter you in to extended processes with questions if you didn't specify on the command-line. Then you usually are given ways to chain this command with others (end of a line starts another line). After that, Unix command lines mostly appear to miss the questions. Questions would hang automated scripts, so you wouldn't want them in the commands, but in the shell.

Re:GUI and CLUI: Two Great Tastes ...

[Pentium100]

I have a German Psion Series 5, the function names in its version of Excel are German, but if I copy the file to another Psion with English interface, it works and the formula names are in English.

So, I guess you could have the localized commands, but do not save them as text, save them as a command number (or something like that) instead, so that a different language version of Excel could then insert the English command names.

XMLTerm

[Pseudonymus Bosch]

Talking about those who do not know history, XMLTerm in 1999.

Copy and paste

[lulalala]

Not sure about Linux, but in Windows Command Prompt I can't copy & paste conveniently.
I have to right click the mouse to select 'paste'.
And when I want to copy, I need to right click and select 'mark' and then mark the areas, then press Enter.
I wonder if I missed something obvious, because if there is some hot keys I can save a lot of time.

WHOOOOSH!-What's in a 'cat'?

[Anonymous Coward]

The operative question is out of all the atomic operations one can do to an object, which are most likely to least. For example with an existing PNG one can either view, or change, with the former being less destructive especially in the context of "Cat".

mahahaha

[Anonymous Coward]

hahahahahaha! this made my day! what a ridiculous concept. only a mac user could come up with a gay tinkertoy like that! this guy has clearly not understood, how cool a text terminal really is. i do nearly all my stuff on a terminal (even sound and video editing and to some extend image processing) and will never cease to do so, because it's the fastest and most efficient way a human can work on a computer. it's fucking powerfull, don't you get it?

That's how AutoCAD etc works

[dbIII]

There is a text command window where you can type "tan to" and then click somewhere near the curve and your line will make a nice tangent to the curve. QCAD does it as well and I'll be the things AutoCAD was written to replace had it as well.

Just use emacs

[leighklotz]

Actually, if you use Emacs, ^X-^F lena.png works fine.

Install procedure doesn't work

[Douglas Goodall]

Installation procedure doesn't work, too bad. The GIT fetch of the package fails over some certificate issue. Blah... http://tech.slashdot.org/story/11/05/19/1648200/Imagining-the-CLI-For-the-Modern-Machine?utm_source=headlines&utm_medium=email#

Very good points

[benjymouse]

Very good points. Plan9 is certainly interesting.

However, there is a few obvious but important differences between "everything is a file" and "everything is an object": Encapsulation and reflection. In PowerShell ps produces a sequence of System.Diagnostics.ProcessInfo objects. This type has methods like Kill (terminate the process), Refresh (refresh the properties for CPU usage, mem usage etc), WaitForExit, WaitForInputIdle etc. When the objects are self-discoverable (reflective) it alleviates the need for specific external commands.

Consider how the COM object Excel.Application comes with methods for manipulating workbooks/sheets, calculating etc. This allows you to directly use the very same objects and methods as used internally by Excel:

$app = new-object -com Excel.Application
$app.DisplayAlerts = $false
$wb = $app.Workbooks.Add()
$ws = $wb.Worksheets.Item(1)
$ws.Cells.Item(1,1) = "Life, the Universe and Everything?"
$ws.Cells.Item(1,2) = "=6*7"
$ws.Calculate()
$question = $ws.Cells.Item(1,1).Text
$answer = $ws.Cells.Item(1,2).Text
$app.Quit()
echo "$question $answer!"

Also consider how the objects can be designed for use within an application as well as on the command line. Although not obvious at first, this is a major point which will help drive automation and scriptability. Exchange has since version 2007 used used the very same "command" objects within the GUI as are scriptable on the command line. Because the commands are handling in-memory objects with no text/JSON/xml serialization when combined they are suitable for applications as well as CLIs.

And irony is ...

[ThePhilips]

Ironically, most of the time I drop into the shell on my Windows box is when I get annoyed by all the stuff which gets in a way of doing work.

File Manager of Windows 3.1/3.11 was quite useful. And fast. Original Win95's Explorer half so useful but still OK, since keyboard support was OK. But Win2k/XP made a step back by essentially breaking the keyboard shortcuts, by introducing bunch of useless sidebars. Win7 made the Explorer essentially a nice frontend for the Picasa and Mercurial - I personally can't use the new Explorer for anything else - it is simply way too unpredictable in both behavior and performance.

Re:And irony is ...

[neminem]

Really? I hated 3.1's file manager. 95/98/XP-with-optional-shiny-turned-off's file manager was way better. Win7 did indeed take a jillion steps back, however, which is why my Win7 computer now runs explorer++ (it still has a couple annoying bugs, but way fewer of them than native Win7 explorer's. Plus, they might actually get fixed at some point, since it's still being actively maintained).