Imagining the CLI For the Modern Machine 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.
Mac only. (Score:4, Interesting)
Re:Mac only. (Score:5, Informative)
Re: (Score:2)
That's my understanding as well. Furthermore, we should be able to take it and run the backend on remote servers with differing OSes.
Advantages of CLI (Score:4, Insightful)
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 (Score:5, Interesting)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3)
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" (
Re:Advantages of CLI (Score:4, Interesting)
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 (Score:2)
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: (Score:2)
I hope this explains it for your.
Re: (Score:3)
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: (Score:2)
"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 :
And that would just be confusing.
Re: (Score:3)
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 ear
Re: (Score:2)
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 densi
Re: (Score:2)
So, my recommendation to this guy would be to buy himself a cheap dumb ASCII terminal and stop whining about w
Re: (Score:3)
You missed the biggest advantage (Score:4, Interesting)
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: (Score:2)
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
Style over Substance (Score:4, Interesting)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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.. :)
That's nice and all but... (Score:2)
Re: (Score:2)
That sounds like a good project... If you spec'd out the usage, you could probably get someone to hack it in.
Re: (Score:2)
Console apps can already respond to the mouse in useful ways.
You don't use console apps do you?
Re: (Score:2)
He's talking about the Bash Shell, not specific apps.
Re: (Score:3)
This is better how? (Score:2)
Re: (Score:3)
Re:This is better how? (Score:5, Funny)
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: (Score:2)
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 she
Close, but no Cigar... (Score:5, Interesting)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 ha
Re: (Score:2)
Everything is an object, including every file.
No difference, except in syntax .
Re: (Score:2)
You should see it under Plan 9 [bell-labs.com], where literally everything is a file, even things like windows, hardware, network connections, etc.
Re: (Score:2)
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
Re: (Score:2)
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: (Score:3)
I tried Powershell a few times, but it seems like if you're not already up to your nose in
Re: (Score:2)
No, because I know how to use the -exec option in find. ;-)
Re: (Score:2)
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... (Score:4, Insightful)
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.
Everything is an INCOMPATIBLE object (Score:2)
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 keyboar
Re: (Score:2, Informative)
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.
Being reflective you can also see the data structure instantly, clearly defined by type, even if t
Re:Everything is an INCOMPATIBLE object (Score:5, Interesting)
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 (Score:5, Insightful)
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 (Score:5, Interesting)
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: (Score:3)
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 ha
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:3)
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 [debian.org]. Try typing "ls -" then push tab twice. magic!
Re: (Score:2)
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 wo
Re:Close, but no Cigar... (Score:5, Insightful)
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 [bell-labs.com], 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: (Score:2)
"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 monolith
Simple Solution (Score:3)
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: (Score:2)
But think of the tweeps (Score:2)
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.
WHOOOOSH! (Score:3, Insightful)
"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: (Score:2)
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: (Score:2)
Re: (Score:2)
$ cat -v lena.png
(follow your bliss)
Re: (Score:2)
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: (Score:2)
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 emulato
Re: (Score:2)
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 greybear
Re:WHOOOOSH! (Score:5, Interesting)
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.
Oh, the Hypocrisy (Score:4, Funny)
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.
Why more grids?!? (Score:2)
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 t
Re: (Score:2)
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.
Pretty but how practical? (Score:3, Interesting)
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.
easy graphic output (Score:2)
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
Balls to TermKit (Score:2)
Unix is meant to be difficult - it keeps idiots out of the datacentre.
Ha ha, only serious.
Information density (Score:2)
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
GUI and CLUI: Two Great Tastes ... (Score:5, Interesting)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re:PowerShell (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
After the whole BSD TCP/IP stack swipe, us Mac/Linux guys get some wiggle room ;)
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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
Re:PowerShell (Score:4, Interesting)
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: (Score:3)
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
Re: (Score:2)
PowerShell is MPW with added complexity to the objects and data passed around.
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Typewriter? Fucking hipster.
Re:Meh. (Score:4, Insightful)
The kind of person that loves-vim-long-time is probably not looking for a graphic-enhanced shell, either.
Re: (Score:2)
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: (Score:3)
view already exists - it's equivalent to 'vi -R'
Re:cat crap (Score:5, Insightful)
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.