Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Imagining the CLI For the Modern Machine

CmdrTaco posted more than 3 years ago | from the now-that's-cool dept.

GUI 317

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.

cancel ×

317 comments

Sorry! There are no comments related to the filter you selected.

PowerShell (1)

Anonymous Coward | more than 3 years ago | (#36181724)

Windows PowerShell beats all.

Re:PowerShell (1, Informative)

Anonymous Coward | more than 3 years ago | (#36181910)

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

Re:PowerShell (2)

The Dawn Of Time (2115350) | more than 3 years ago | (#36182014)

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 (1)

TooMuchToDo (882796) | more than 3 years ago | (#36182072)

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

Re:PowerShell (1)

The Dawn Of Time (2115350) | more than 3 years ago | (#36182326)

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 (2)

clang_jangle (975789) | more than 3 years ago | (#36182158)

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 (1)

Dog-Cow (21281) | more than 3 years ago | (#36182296)

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 (1)

clang_jangle (975789) | more than 3 years ago | (#36182446)

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 (3, Interesting)

fusiongyro (55524) | more than 3 years ago | (#36182754)

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 (1)

fusiongyro (55524) | more than 3 years ago | (#36182632)

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 (1)

EvanED (569694) | more than 3 years ago | (#36182308)

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 (1)

ClintJCL (264898) | more than 3 years ago | (#36181920)

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 (1)

obarthelemy (160321) | more than 3 years ago | (#36182318)

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 (1)

ClintJCL (264898) | more than 3 years ago | (#36182492)

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 (3, Insightful)

19thNervousBreakdown (768619) | more than 3 years ago | (#36182292)

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 (1)

gilleain (1310105) | more than 3 years ago | (#36182486)

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.

Cool. (0)

Awkward Engineer (2178204) | more than 3 years ago | (#36181732)

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

LOL GO FUCK YOURSELF (-1)

Anonymous Coward | more than 3 years ago | (#36181838)

Lemming bloggers promote their shitty blog here. - www.gofuckyourself.com [goatse.cx]

Re:LOL GO FUCK YOURSELF (-1)

Anonymous Coward | more than 3 years ago | (#36182038)

Hey bud, goatse.cx is down for couple of years.
You should use gotase.ru instead or google for another mirror.
Also wrapping the link in some url shortener works well too, as slashdotters are too dumb to unwrap it.
(I usually use bit.ly, in the link chain, and on a good day I can get around 1000 victims).
Also putting hello.jpg on some hosting site like a blog, gets them down like a sugar+glue.

Re:Cool. (1)

hjf (703092) | more than 3 years ago | (#36182002)

Typewriter? Fucking hipster.

Mac only. (3, Interesting)

The MAZZTer (911996) | more than 3 years ago | (#36181736)

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. (4, Informative)

The MAZZTer (911996) | more than 3 years ago | (#36181896)

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. (1)

fusiongyro (55524) | more than 3 years ago | (#36182796)

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 (0)

Anonymous Coward | more than 3 years ago | (#36181772)

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

Lame

Oh, like a trannie? (-1)

Anonymous Coward | more than 3 years ago | (#36181778)

They also get my juices flowing, especially the Brazilian ones.

Meh. (1)

Anonymous Coward | more than 3 years ago | (#36181796)

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

Re:Meh. (3, Insightful)

outZider (165286) | more than 3 years ago | (#36182108)

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

Monad (1)

Anonymous Coward | more than 3 years ago | (#36181820)

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

Re:Monad (0)

Anonymous Coward | more than 3 years ago | (#36182458)

Yes, but it's called Powershell now.

Advantages of CLI (3, Insightful)

Ironchew (1069966) | more than 3 years ago | (#36181836)

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 (4, Interesting)

Alternate Interior (725192) | more than 3 years ago | (#36181902)

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 (0)

ChienAndalu (1293930) | more than 3 years ago | (#36181980)

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 (1)

gstoddart (321705) | more than 3 years ago | (#36181978)

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 (1)

socz (1057222) | more than 3 years ago | (#36182420)

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 (1)

immakiku (777365) | more than 3 years ago | (#36182128)

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 (1)

im_thatoneguy (819432) | more than 3 years ago | (#36182130)

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 (2)

gstoddart (321705) | more than 3 years ago | (#36182256)

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 (3, Interesting)

gilleain (1310105) | more than 3 years ago | (#36182518)

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.

You are a newbie only once in your life (1)

mangu (126918) | more than 3 years ago | (#36182332)

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.

Re:Advantages of CLI (1)

camcorder (759720) | more than 3 years ago | (#36182528)

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 (2)

arth1 (260657) | more than 3 years ago | (#36182808)

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 (1)

Mr. Underbridge (666784) | more than 3 years ago | (#36182134)

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 (1)

AchilleTalon (540925) | more than 3 years ago | (#36182166)

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 (2)

seifried (12921) | more than 3 years ago | (#36182224)

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 (1)

EvanED (569694) | more than 3 years ago | (#36182352)

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.

Style over Substance (3, Interesting)

spun (1352) | more than 3 years ago | (#36181840)

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 (1)

outZider (165286) | more than 3 years ago | (#36182278)

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 (-1, Flamebait)

spun (1352) | more than 3 years ago | (#36182462)

That assumes anyone would want to run it in another OS. It is a utility for Apple fanatics, not normal computer users. Really, only an Apple fanatic would even think something like this is useful or necessary.

Re:Style over Substance (1)

outZider (165286) | more than 3 years ago | (#36182622)

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 (1)

spun (1352) | more than 3 years ago | (#36182862)

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.

That's nice and all but... (1)

matunos (1587263) | more than 3 years ago | (#36181846)

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

Re:That's nice and all but... (1)

Aladrin (926209) | more than 3 years ago | (#36182358)

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... (1)

jedidiah (1196) | more than 3 years ago | (#36182618)

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

You don't use console apps do you?

This is better how? (2)

egyas (1364223) | more than 3 years ago | (#36181848)

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? (2)

Tikkun (992269) | more than 3 years ago | (#36181898)

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? (5, Funny)

discord5 (798235) | more than 3 years ago | (#36181928)

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? (0)

Anonymous Coward | more than 3 years ago | (#36182172)

LOLCLI?

Re:This is better how? (0)

Anonymous Coward | more than 3 years ago | (#36182010)

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? (0)

Anonymous Coward | more than 3 years ago | (#36182362)

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? (1)

grumbel (592662) | more than 3 years ago | (#36182844)

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.

Close, but no Cigar... (5, Interesting)

MarcQuadra (129430) | more than 3 years ago | (#36181850)

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... (2)

Microlith (54737) | more than 3 years ago | (#36182094)

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... (1)

hedwards (940851) | more than 3 years ago | (#36182160)

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... (1)

CannonballHead (842625) | more than 3 years ago | (#36182262)

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... (1)

hedwards (940851) | more than 3 years ago | (#36182624)

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... (1)

jbengt (874751) | more than 3 years ago | (#36182666)

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

Re:Close, but no Cigar... (0)

Anonymous Coward | more than 3 years ago | (#36182328)

> 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... (0)

Anonymous Coward | more than 3 years ago | (#36182178)

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... (0)

Anonymous Coward | more than 3 years ago | (#36182254)

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... (2)

happyhangone (599849) | more than 3 years ago | (#36182270)

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... (1)

profplump (309017) | more than 3 years ago | (#36182414)

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... (1)

EvanED (569694) | more than 3 years ago | (#36182468)

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... (0)

Anonymous Coward | more than 3 years ago | (#36182584)

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... (2)

jandrese (485) | more than 3 years ago | (#36182668)

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.

Everything is an INCOMPATIBLE object (1)

mangu (126918) | more than 3 years ago | (#36182510)

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 (0)

Anonymous Coward | more than 3 years ago | (#36182678)

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 (1)

amliebsch (724858) | more than 3 years ago | (#36182718)

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 (2, Informative)

Anonymous Coward | more than 3 years ago | (#36182730)

'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:Close, but no Cigar... (1)

Twillerror (536681) | more than 3 years ago | (#36182566)

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... (0)

Anonymous Coward | more than 3 years ago | (#36182748)

nooby

Re:Close, but no Cigar... (1)

yarnosh (2055818) | more than 3 years ago | (#36182838)

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... (1)

fusiongyro (55524) | more than 3 years ago | (#36182848)

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).

Simple Solution (2)

Haedrian (1676506) | more than 3 years ago | (#36181932)

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.

But think of the tweeps (1)

suso (153703) | more than 3 years ago | (#36181960)

But if we moved to this model, how would I give tips on climagic [twitter.com] ? 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 (0)

Anonymous Coward | more than 3 years ago | (#36182434)

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?

cat crap (1)

Anonymous Coward | more than 3 years ago | (#36181966)

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

Re:cat crap (1)

suso (153703) | more than 3 years ago | (#36182266)

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 (4, Insightful)

dzfoo (772245) | more than 3 years ago | (#36182696)

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.

WHOOOOSH! (3, Insightful)

blair1q (305137) | more than 3 years ago | (#36182074)

"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! (1)

he-sk (103163) | more than 3 years ago | (#36182494)

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.

military might fails miserably, peace declared? (-1)

Anonymous Coward | more than 3 years ago | (#36182162)

that sounds better but just in case;

no wonder it's to be decreed this day that the god given chosen ones' holycost must be extendead until at least 2025, because of our fear, & the # of us, which both are big. disarmament is catching on all over the globe. so we'll clearly be at some advantage, & the rest of the world will continue to bow down, suck up, & just re-fear us in general. it worked for us until it didn't, now it's not our fault if a lot more death & destruction is done because THEY won't listen/give us their resources, even though we need them to keep the dream a lie for another day. when self-importants of our guys get nailed, it's ALWAYS 'former' head..., alleged, unproven blah blah blah. innocent until ,,, unless. terrorific example of regimes run amok.

still waiting? more stand-up talknician routines. more threatening now? will the FSF guys be arrested for sex crimes too? julians, adrians, everybody's at risk, of being arrested, or worse. scary? 13 year old tagged by ss.gov at school for unapproved tweeting. so we're safe from him now. the key to the bells & whistles of just one city is way too much trust to put in one human. our/our planet's fate however, is different?

same old; how many 1000 babys going up in smoke again today? how many 1000's of just folks to be killed or displaced again today? hard to put $$ on that. the cost of constant deception, to our spirit? paying to have ourselves constantly spied on & lied to by freaky self chosen neogod depopulationers? the biblically styled fatal distraction holycost is all encompassing, & never ends while we're still alive, unless we cut them/ourselves off at the wmd. good luck with that, as it's not even a topic anywhere we get to see, although in real life it's happening everywhere as our walking dead weapons peddlers are being uncontracted. you can call this weather if it makes you feel any better. no? read the teepeeleaks etchings.

so, once one lie is 'infactated', the rest becomes just more errant fatal history.

disarm. tell the truth. the sky is not ours to toy with after all?

you call this 'weather'? what with real history racing up to correct
itself, while the chosen one's holycostal life0cider mediots continually
attempt to rewrite it, fortunately, there's still only one version of the
truth, & it's usually not a long story, or a confusing multiple choice
fear raising event.

wouldn't this be a great time to investigate the genuine native elders social & political leadership initiative, which includes genuine history as put forth in the teepeeleaks etchings. the natives still have no words in their language to describe the events following their 'discovery' by us, way back when. they do advise that it's happening again.

who has all the weapons? who is doing MOST of the damage? what are the motives? are our intentions & will as the ones who are supposed to be being represented honestly & accurately, being met? we have no reference to there being ANY public approval for the current mayhem & madness pr firm regime style self chosen neogod rulership we've allowed to develop around us, so we wouldn't have to stop having fun, & doing things that have nothing to do with having to defend from the smoke&mirrors domestic frenetics, of the unproven genocides. rockets exploding in syria fired from Libya? yikes?

the zeus weather weapon is still being used indiscriminately against the population, our rulers' minions are fleeing under fire.

the whore of babylon has been rescued by the native elders. she has the papers of challenge authored by the hymenical council, & is cooperating wholeheartedly with the disarmament mandate.
disarm. thank you.

censorship, or convenience?
Due to excessive bad posting from this IP or Subnet, anonymous comment
posting has temporarily been disabled. You can still login to post.
However, if bad posting continues from your IP or Subnet that privilege
could be revoked as well. If it's you, consider this a chance to sit in
the timeout corner or login and improve your posting. If it's someone
else, this is a chance to hunt them down. If you think this is bogus, you are right moderation@slashdot.org with your MD5'd IPID and SubnetID, (which have been maliciously edited from time to time for effect by /.censory)
which are always changing, you butthead

Inspirational project (0)

Anonymous Coward | more than 3 years ago | (#36182240)

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.

At the end of the day, Unix just has bad usability (-1)

Anonymous Coward | more than 3 years ago | (#36182378)

That explains why this is a epic fail.

Oh, the Hypocrisy (3, Funny)

VortexCortex (1117377) | more than 3 years ago | (#36182384)

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.

Security (0)

Anonymous Coward | more than 3 years ago | (#36182410)

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

I mean, from the attacker perspective...

Why more grids?!? (1)

mothlos (832302) | more than 3 years ago | (#36182422)

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?!? (1)

Hatta (162192) | more than 3 years ago | (#36182652)

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?!? (1)

TobesWSU (614010) | more than 3 years ago | (#36182794)

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.

Awesome (0)

Anonymous Coward | more than 3 years ago | (#36182498)

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? (2, Interesting)

bl8n8r (649187) | more than 3 years ago | (#36182506)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?