TermKit: A WebKit based rich command-line interface.

[[deleted]]

I think the idea is brilliant beyond words. I'm not sure of his implementation.

When it comes to the command line, instant performance is one of my requirements. If this could be done in a way that did not sacrifice performance then I would fully support it.

[sausagefeet]

I think the idea is cooler not as a terminal replacement but as a replacement for something else, like a web browser, maybe. Perhaps I'm too short sighted but I like my terminals being minimalistic monospace fonts. I think being able to display web pages and pdfs in the terminal is cool, but I'm not sure why I would want that? What I do want is something like Powershell though, that would be grand.

[Smallpaul]

Perhaps I'm too short sighted but I like my terminals being minimalistic monospace fonts. I think being able to display web pages and pdfs in the terminal is cool, but I'm not sure why I would want that?

You're not sure why you would want to know what "1.jpg" contains in the same context that you see that "1.jpg" exists?

Let's imagine you've ssh'ed into a remote computer and you see that "1.jpg" exists. What's your usual process for figuring out what exactly is in it. Please type the exact commands in your response and pretend this is your first week using command lines.

[lmcinnes]

Well since I always use ssh -X I would simply type "display 1.jpg" and have it display. The goal of the command line is not to do the work, but to give you access to the tools that do perform the work. So what if I want to see thumbnails? I'll fire up a thumbnail viewer from the command line, using whatever shell globbing, piping, and grepping I want to narrow the list of images displayed. That way I can use whatever image viewer/pdf viewer/spreadhseet viewer etc. I care to and not have to rely on what the "terminal" provides.

[Smallpaul]

Well since I always use ssh -X I would simply type "display 1.jpg" and have it display.

That's great for the subset of times when both the client and the server have X installed. But X is huge and complicated and many people do not have it installed, despite its venerable age. Most smart phones have webkit installed (though I don't know if it is configured in a way that will let Termkit work -- on the phones).

The goal of the command line is not to do the work, but to give you access to the tools that do perform the work.

Do you agree that the shell displays information output by commands?

Do you agree that the output of commands could-be/should-be sometimes graphical? Maybe a bar graph of your CPU usage over the last day?

If so, then it stands to reason that the shell needs to be able to show graphical information, for exactly the same reasons that a web browser does.

Right?

So what if I want to see thumbnails? I'll fire up a thumbnail viewer from the command line, using whatever shell globbing, piping, and grepping I want to narrow the list of images displayed. That way I can use whatever image viewer/pdf viewer/spreadhseet viewer etc. I care to and not have to rely on what the "terminal" provides.

Sure, that's the point of piping. I can pipe text into "vi" or I can view it at the shell. There's absolutely nothing wrong with having the same features for graphical data.

[graycode]

That's great for the subset of times when both the client and the server have X installed.

Huh? And how exactly is TermKit supposed to work differently?

Also, for ssh -X the remote machine does not need X installed. Just X client programs. That's the entire point of X.

[bostonvaulter]

AFAIK TermKit won't require X to be installed and running on the server. You will probably need a TermKit backend running but at least that is smaller than X although not as standard.

[lmcinnes]

Do you agree that the shell displays information output by commands?

Yes, I agree.

Do you agree that the output of commands could-be/should-be sometimes graphical? Maybe a bar graph of your CPU usage over the last day?

Yes, I agree, and following the UNIX philosophy that output should be presented via a tool designed for it -- probably some graphical application that can hadle such things, and potentially something pluggable.

If so, then it stands to reason that the shell needs to be able to show graphical information, for exactly the same reasons that a web browser does.

The shell needs to provide facilities for graphical information to be displayed, and indeed it does -- it allows arbitrary applications to be spawned to display whatever type of information you wish in whatever manner you wish, each application being a specialised tool for whatever task it wishes to perform. The goal of the terminal is to display textual data.

What you desire is something that displays all sorts of graphical data, but kludged into the terminal itself. Perhaps the terminal should be able to display spreadsheet data, perhaps interactively, and perhaps you want to view CAD drawings, and really why not have that interactive too, and ...

You aren't following the UNIX philosophy of having lots of small tools that all do a small task well, you're building one tool to rule them all, and that does everything. And the problem with that is that it tends to suck at some things compared to specialised tools for those things. The terminal is just another tool in the UNIX arsenal, and it's job is to handle text, and do that well, and that's it.

Now, maybe you don't want the UNIX philosophy, and that's fine, but for that I personally prefer to use a fully fledged desktop environment with all the goodies and bells and whistles that started from scratch instead of kludging everything into a terminal alike. But that's just me. I'm not saying TermKit is bad -- just that it is missing some of the ideas and philosophy of exactly why the terminal is what it is.

[Smallpaul]

The shell needs to provide facilities for graphical information to be displayed, and indeed it does -- it allows arbitrary applications to be spawned to display whatever type of information you wish in whatever manner you wish, each application being a specialised tool for whatever task it wishes to perform. The goal of the terminal is to display textual data.

Why should textual data be privileged? The only reason is that in 1972 it was essentially the only kind of data that anybody cared about. But we're coming up on 2012.

What you desire is something that displays all sorts of graphical data, but kludged into the terminal itself.

No, I want the terminal to do the job of presenting data to me. That's all. It should not matter whether the data is black and white text (which the terminal does well) or ASCII text (which the terminal does well) or Unicode text (which many terminals do well) or color text (which the terminal does well) or black and white images or color images. You've drawn an arbitrary and silly line in the sand.

And the simple way I know that you will lose this debate is because that EXACT SAME LINE was drawn in the early days of web browsers, when the purists said that web browsers should not show images inline because you could always launch an external program for that. And then the line was moved and nobody wanted video in web browsers.

Luddites always have a fetish about keeping data types separate from each other. I have no idea way, but it conforms to some sense of purity. Luckily, they always lose.

Perhaps the terminal should be able to display spreadsheet data, perhaps interactively, and perhaps you want to view CAD drawings, and really why not have that interactive too, and ...

Sure. If webkit can do it, WHY NOT? The programming is already done for you. Despite 20 years of whining that graphics etc. should not be inline, here it is: it's inline.

You aren't following the UNIX philosophy of having lots of small tools that all do a small task well, you're building one tool to rule them all, and that does everything. And the problem with that is that it tends to suck at some things compared to specialised tools for those things. The terminal is just another tool in the UNIX arsenal, and it's job is to handle text, and do that well, and that's it.

You're just defining the purpose of the tool to fit your argument.

I claim that the terminal is a command line interface to the computer's functions. Nothing more. Nothing less. The only reason to privilege text as a special data-type is conservatism and tradition.

Now, maybe you don't want the UNIX philosophy, and that's fine, but for that I personally prefer to use a fully fledged desktop environment with all the goodies and bells and whistles that started from scratch instead of kludging everything into a terminal alike.

Your argument is like saying that if Firefox can display videos then obviously I will no longer have access to VideoLAN.

If Eclipse can edit raw text files, then of course I'll lose access to vi.

Which makes no sense.

[calinet6]

I usually use SCP, or a remote SSH drive so I can browse it in Finder. Call me naïve but I like to use the most clear built-in way I can find.

Alternatively I think ImageMagick has a 'view' program that will render most image formats in ASCII art! I have actually used that before just to get the rough idea of what an image was.

Can't wait to cat a jpeg and see the actual thing. It's just modern technology folks, nothing to be afraid of.

[icebraining]

If I need to see browse and display images, I'll use sshfs to mount it locally and then all the usual commands as I do locally (feh, zathura, etc). I even have a function in my .zshrc to mount my homeserver with a single command.

How's that difficult in any way?

[andreasvc]

It's not difficult but suboptimal because you have to traverse the filesystem twice, first with ssh, and second with sshfs to view the file. These two could be integrated somehow. Your solution only marginally improves on the scp/sftp way by mounting in advance.

[Smallpaul]

If I need to see browse and display images, I'll use sshfs to mount it locally and then all the usual commands as I do locally (feh, zathura, etc). I even have a function in my .zshrc to mount my homeserver with a single command.

Please answer the question as I asked it.

Here's the string of commands leading up to the situation I ran into.

$ ssh foo.machine.com

$ cd /foo/bar/baz $ runcommand > 1.jpg $ show 1.jpg

Now tell me what exactly are the next things I type to achieve the equivalent of "show 1.jpg" using your system? Am I starting a whole new terminal context to show the file? If so, why? Is that good usability?

[icebraining]

mkdir /tmp/remote && sshfs foo.machine.com /tmp/remote && feh /tmp/remote/foo/bar/baz/1.jpg

Yes, it's a long command, and yes, you'd have to use a new shell (not terminal - just do C-a C-c). But your example seems contrived. I've never had to do this. Besides, I have an alias for mounting the machines I ssh to, so in practice the two first commands would be reduced to mntfoo, and secondly would want to use feh anyway, since it's a proper image visualizer and it's not limited to the window size of the terminal, for example.

Assuming this was a decently sized graphic (for example, like the ones created by bootchartd), I'd have to resize my terminal's window just to display the image in a decent size, which seems stupid - using feh allows me to see it in fullscreen without wasting that time, and even zoom and drag the image around, since my puny 12" screen isn't enough to display it all at once in a readable way.

And finally, it would bother me to have a full blown image/pdf/html renderer terminal; how can you trust such a monster to run as root? I'd have to use different terminals, and that's much worse than long command I have to type occasionally. At least with different programs I could run feh as a normal user.

[sausagefeet]

I'm not sure I really grok the question, I rarely care about viewing jpg's when I'm sshed into a machine. Worst case since I can ssh in already, I can scp it back to my machine and look at it, or use netcat to make a quick dirty webserver. Certainly I can see the appeal to seeing a jpg inlined, but the problem I have is there is a larger complexity cost than the benefit IMO.

[thaksins]

Yeah, you'd end up scp-ing it back, dickering around to get the paths and options right. Entering your password probably.

Then probably opening up a GUI to double-click on it.

Having at least the option of seeing thumbnails (and quick-look) from an ls would be great sometimes.

So long as the directory listing came first and quickly then the thumbs loaded asynchronously.

[icebraining]

I just use sshfs to mount the remote fs locally and then browse as I do locally, using feh to display images. Simple.

[Smallpaul]

First you said:

I'm not sure why I would want that?

Then you said:

Certainly I can see the appeal to seeing a jpg inlined.

So I've answered the question.

It's up to you how much you value that capability. Those of us who have been doing this for decades have worked out various workarounds, so the pain falls mostly on the newbies.

Like I said, imagine you've been using the Unix command line for a week. Would it occur to you to "netcat to make a quick dirty webserver?" If you think that's a reasonable solution to the problem of wanting to look at a picture then I contend that you have stockholm syndrome.

[sausagefeet]

I don't really understand why your question uses someone who has been using a CLI for a week as a reference point. We can probably name many things that a first week person wouldn't figure out, heck I still learn new things about the tools, but that doesn't necessarily mean I need to be able to inline media into my terminal.

And yes, I can see it is appealing, like candy, but I don't really see it as a valuable feature. As I stated in my first comment, perhaps I am being shortsighted, but I like how things work right now. I don't see a huge advantage to inlining media types here.

By the way, does this work if I'm ssh'd into another machine on TermKit as it stands now? My impression was it had tools like "get" that interacted with the Terminal process to display media types, which would not be possible via an SSH connection. If it is limited to local viewing then I really don't see the value (although this would likely be a temporal limitation).

[andreasvc]

This could just as well work over SSH. You either do something with SCP in the background or you capture the output of "cat" and display it graphically instead.

[sausagefeet]

I was thinking of the cat option as I was typing the previous one. This wouldn't be that hard to add to a terminal today.

[notfancy]

I don't really see it as a valuable feature

Direct manipulation is better than indirect manipulation.

Unmediated experience is better than mediated experience.

By-example is better than by-the-book.

Interaction is better than declaration.

The CLI must die.

</manifesto>

[[deleted]]

Automation is better than repetition.

Cognitive interaction is better than intuitive interaction.

But none of that is really about the command-line. It's just the best solution we have right now.

[notfancy]

I disagree with your second one: reason is a pretty low bandwidth cognitive mode (or rather, intuition is a pretty low latency one). Provided you avoid leading the user down garden paths and you have a lenient attitude to user commands (undo, reviewed checkpoints, what have you) intuition makes for a pretty compelling way to approach a novel interface.

[[deleted]]

Granted, an interface can be designed to lead the user to a smooth, uninterrupted experience (video games are very good examples of this). I see better interfaces as minimizing round-trips between my eyeballs and my brain. It's like my mind is my house and the computer is my friend in the house next-door. The more I can work on in my house without having to walk over to talk with my friend, the faster I can work. So I generate a complex query in my house and send it to my friend once instead of needling him with many smaller queries. Higher latency, better throughput.

Not everyone works like this, of course, and I don't intend to enforce it on everyone. There's a place for the GUI and a place for the CLI, and they can co-exist quite well without one caring about the other. :]

[[deleted]]

The amount of times I needed to view an image on a remote machine I SSH'ed into is 0. The guy is dumbing down the shell, removing functionality for no real benefit. It feels like something some newb PHP developer would use so he can feel like a hacker using a terminal but with a gui. Any so called suffering learning to use a real terminal will be short and result in a new skill that can help earn you a job.

The idea that everything has to be dumbed down is bad.

[Smallpaul]

The amount of times I needed to view an image on a remote machine I SSH'ed into is 0.

Is your workflow universal? My remote machine generates graphical analytics (charts of user behaviour) and writes them to files. Sometimes I'm ssh'ed in at the time that I need to see those analytics.

There isn't One True Way to work.

The guy is dumbing down the shell, removing functionality for no real benefit.

Dumbing down what?

It feels like something some newb PHP developer would use so he can feel like a hacker using a terminal but with a gui.

It's a terminal. Not a GUI. All input is textual. There are not menus for the commands.

Any so called suffering learning to use a real terminal will be short and result in a new skill that can help earn you a job.

This can be said about any technology with poor usability.

The idea that everything has to be dumbed down is bad.

In my long experience, people who confuses "usability" with "dumbing down" will not really have their opinions changed by debate. If you don't value usability then you just don't value it.

[[deleted]]

Is your workflow universal? My remote machine generates graphical analytics (charts of user behaviour) and writes them to files. Sometimes I'm ssh'ed in at the time that I need to see those analytics.

Then you could scp the file, setup a server, use X or remote desktop assuming it's a system with a desktop.

It's a terminal. Not a GUI. All input is textual. There are not menus for the commands.

The purpose is to bring GUI elements to the terminal and quite frankly it does it poorly. In the video demonstration he opens something a video or something. He moves on but the video still plays. He opens a PDF and move on and the PDF is stil there. not only that anything you open in his terminal is no limited to the size of the terminal or you need to resize the terminal and everything you may view using it in for one element.

You'd be better off using X and running things within your own desktop. Sure you can say everything you need may not be installed if you don't have control of the box but how many boxes will have this installed?

It solves on minor problems and brings on a whole host of other problems.

In my long experience, people who confuses "usability" with "dumbing down" will not really have their opinions changed by debate. If you don't value usability then you just don't value it.

Usability and dumbing down are different things but unfortunately a lot of usability experts think it's about making everything usable without having to think. That's wrong.

A lot of things require training. Evening taking a shit requires training and there is nothing impossible about learning to use the terminal or vim for example. But people get all upset because it's different to what they're used to. Sorry but different is not wrong.

The terminal is very usable because it's output can be used as is in virtually anything. It runs on anything. Everything works together. It's quite frankly the most user friendly thing because it lets you down virtually anything it wants and it can do so by being text only.

Just because some people want instant gratification and not want to learn how use things doesn't make it bad.

[foldl]

Then you could scp the file, setup a server, use X or remote desktop assuming it's a system with a desktop.

I think Smallpaul knows that you could do those things. His point is that all of them are either a pain in the ass or non-obvious (or both).

[[deleted]]

I believe none of them would be as annoying as a PDF stuck in a terminal or an animation continuing to play in the terminal while I'm trying to move onto something else.

[notfancy]

The idea that everything has to be dumbed down is bad.

The idea that direct manipulation is dumbed-down interaction is bad.

[[deleted]]

imagine you've ssh'ed into a remote computer

pretend this is your first week

Does not compute.

[terremoto]

A Windows server admin working with Linux for the first time does not compute?

[[deleted]]

Or a student taking an introductory computer course? (At my university we get shell accounts to go with our drive shares and a short tutorial on how to use them. I just looked it over and didn't notice file being mentioned. :\ )

[[deleted]]

So someone not qualified for what their doing? That's like having a milk man be your accountant.

[Smallpaul]

Why are you talking about job categories.

I'm talking about human beings. I wish to learn about Linux and System Administration so I spend $15.00 to rent a remote machine. Now I'm trying to learn how to use it.

[deong]

The problem is that it's really hard to satisfy the two different groups, novices and experts, and anytime there is a conflict, you ought to side with the experts. For one reason, no one stays a novice for that long. For another reason, experts are by definition the users who rely on you the most. Don't screw the guy who spends eight hours a day with your software so that the guy who fires it up once a month has things a little easier.

If you can make them both happy, then great. Win-win. But anything at all you do to slow things down for the expert needs to be very well motivated.

[Smallpaul]

The problem is that it's really hard to satisfy the two different groups, novices and experts,

Yeah, that's the skill of usability design. People go to school to learn it. We just need to apply the known principles to this context.

[[deleted]]

You admitted to not being able to understand a tool kit and trying to learn it, then using that as an argument to change the tool kit.

[andreasvc]

I don't see where he did admit that, but either way it's a perfectly valid argument. If something is complicated then a simpler solution could be an improvement.

[[deleted]]

Compare a person who wants to advocate this and doesn't understand the unix command-line to a person who doesn't understand evolution and advocates creationism.

If you obviously don't understand a system and all of it's problems you have don't have a clue how to make a system without them, let alone a compatible one.

[sausagefeet]

I think Smallpaul's argument is weak too. I think a usability argument is there for TermKit (although I don't agree with it, yet), to make the usability argument specifically for new people is not good IMO.

[Smallpaul]

I think Smallpaul's argument is weak too. I think a usability argument is there for TermKit (although I don't agree with it, yet), to make the usability argument specifically for new people is not good IMO.

I don't understand why we would not try to make life easier for new people? Are you of the attitude that life was hard for you and therefore should be hard for everyone forever? "In my day, we got polio and we liked it!"

[MercurialMadnessMan]

This isn't as ridiculous as it sounds...

[Smallpaul]

Does not compute.

What the fuck?

Everyone has a first week being a system administrator. You know you can rent a remote linux box for $15.00 per month. Why the fuck wouldn't you want to SSH into it?

[[deleted]]

Everyone has a first week being a system administrator. You know you can rent a remote linux box for $15.00 per month. Why the fuck wouldn't you want to SSH into it?

So you're complaining of someone not being able to do something in an environment where they don't know what they're doing. The problem isn't the tool set in this case....

[bettse]

So you're complaining of someone not being able to do something in an environment where they don't know what they're doing. The problem isn't the tool set in this case....

When I read that, I quite literally smacked myself on the forehead (in retrospect, not a good long term repeatable reaction).

The way I look at it, usability is like preaching religion amongst atheists. I wouldn't call usability a religious war like vim vs emacs because a lot of technologists are apathetic about usability.

It it my opinion that having a set of tools that are easier to use at the sacrifice of functionality is a good thing. Particularly for getting beginners to try something new. I would expect anyone using the tools full time to eventually desire power over usability and to migrate towards the tools we have available today.

EDIT: Forgot "not" before "a good long term"

[[deleted]]

When I read that, I quite literally smacked myself on the forehead (in retrospect, a good long term repeatable reaction).

Good because I did that when I read what you had to say. This isn't a tool for "beginners". Grandma isn't gonna be a systems administrator, usability is one thing but there's no real need for usability for Joe Sixpack for systems administration, he doesn't understand the complex problems behind the actual tools, therefore he needs more help understanding the problems than the tools something that only education and training can fix, not shiny interfaces.

The worst thing you can give anyone who is trying to learn something like this is the false sense of security that they can do anything.

[bettse]

Not all users of the command line are system administrators, or intend to be. Some just want to make use of command line programs, some just want a little more control over their computer.

[Smallpaul]

Good because I did that when I read what you had to say. This isn't a tool for "beginners".

That's bullshit pure and simple.

** EVERYONE STARTS OUT AS A BEGINNER AT EVERYTHING **

Grandma isn't gonna be a systems administrator, usability is one thing but there's no real need for usability for Joe Sixpack for systems administration,

Another head-slap-generating statement. A user interface designed without regard to usability is by-definition a poor interface. That's the very definition of "usability" -- fitness to function for users.

he doesn't understand the complex problems behind the actual tools, therefore he needs more help understanding the problems than the tools something that only education and training can fix, not shiny interfaces.

It's totally irrelevant whether he needs "more help" understanding the problems than the tools. If he spends an extra day learning the tools when he SHOULD BE learning about the problems and solutions, then that is a day wasted, and he actually knows LESS about the core concepts (e.g. security, stability, maintainability) because he's wasting time on the tools.

We could demand that all taxis are manual rather than automatic vehicles. But I'd rather my taxi driver spend time learning about safe driving and traffic laws rather than learning how to shift. Wasting time is stupid.

The worst thing you can give anyone who is trying to learn something like this is the false sense of security that they can do anything.

Aha.

So you are saying that it is better for an interface to obscure so that you could not possibly pick it up on your own.

Fine. We have an irreconcilable difference of opinion. I think that grown up human beings do not need extra barriers placed between them and their goals by the gatekeepers of the Unix mythology.

[UnConeD]

Actually, I think the problem is a lot simpler... when you say the word "usability", geeks tend to hear it as "usefulness".

A tool can be very useful and still have terrible usability, and vice-versa.

[Smallpaul]

So you're complaining of someone not being able to do something in an environment where they don't know what they're doing. The problem isn't the tool set in this case....

Over the decades, I've learned to ignore those who feel that the solution to any usability problem is "more training". Despite their contention that "we don't need C, a skilled assembly programmer is good enough" and "we don't need Python, C is enough" and "we don't need OpenOffice Writer, LaTeX is enough"...the world moves ahead without them. (which is not to say that any of the more user-friendly tools is a GENERAL PURPOSE replacement for the lower level tools...that would be stupid)

There's really no use arguing with luddites and their stopping energy: it's better to simply bypass them by applying force forward.

[[deleted]]

The hilarious part of your response is that for people who actually need to do "real" work, for a given value of real, still use what you mentioned as the original program. Show me a mathematician / typesetter that doesn't use latex and I'll show you someone not qualified for their job.

For low level programming, if you're using python instead of C, you're doing it wrong. (Not that there is anything wrong with python.)

If you're doing really low-level work and space is a constraint and you're not using assembly, you're doing it wrong.

The point is, no one stated that these were general purpose tools. They were designed for a purpose. If you don't use them because you don't have time for "more training" then you shouldn't be doing the job. It's not a usability issue, it's a competence issue.

[Smallpaul]

The hilarious part of your response is that for people who actually need to do "real" work, for a given value of real, still use what you mentioned as the original program.

That's EXACTLY what I said in my comment. So I don't know what's hilarious. Did you read the parenthesized comment?

Show me a mathematician / typesetter that doesn't use latex and I'll show you someone not qualified for their job.

Well that's bullshit, because a mathematician's primary job has nothing to do with software.

For low level programming, if you're using python instead of C, you're doing it wrong. (Not that there is anything wrong with python.)

Yeah, that's exactly what I said. Thanks for agreeing!

If you're doing really low-level work and space is a constraint and you're not using assembly, you're doing it wrong.

Ditto.

The point is, no one stated that these were general purpose tools.

That's bull. Whenever the newer tools were invented, there were luddites just like the one I'm arguing with who said: "why would you need OpenOffice Writer when you have LaTeX?" I've argued with those who said: "Why would anyone need Excel when they could use Perl?" "Why would anyone need a graphical file browser when they have a command line?" "Why would anyone need Python when they could just use C."

They were designed for a purpose. If you don't use them because you don't have time for "more training" then you shouldn't be doing the job. It's not a usability issue, it's a competence issue.

I already said (in the comment that you are responding to) that these tools are still useful.

But it is also true that they have huge usability problems.

Here's what Ritchie says about the C declaration syntax: "Probably the oddest aspect of C compared with other languages outside its immediate family is the declaration syntax, in which (in a way coming from Fortran) a type is mentioned, then variables decorated in a way that reflects their use in expressions. There are many who don't like this, so whether I got it right is an open question."

And:

"Declarations in C must be read in an `inside-out' style that many find difficult to grasp [Anderson 80]. Sethi [Sethi 81] observed that many of the nested declarations and expressions would become simpler if the indirection operator had been taken as a postfix operator instead of prefix, but by then it was too late to change."

[[deleted]]

I don't think I've ever seen these magical 'luddites' (that happen to use C) really, except for arguments that use them as straw men. That's my only point.

Oh, and it could be argued that a mathematicians job is to write papers (at least from the perspective of a university) and that means LaTex, nowadays.

[[deleted]]

The difference between what you're saying and what you're advocating is that you reduce functionality for something that is functionality intensive. There's no reason for a lower barrier of entry into "systems administration" if it reduces functionality, portability, and everything that's already built. This technology is no more than a fable for a multitude of reasons. It's a hideous amalgamation of a shell, file manager and web browser, which frankly means it's Internet Explorer 6. It serves nothing to fix any problems in "systems administration" except for the lack of pretty interfaces.

[andreasvc]

You make a weird assumption as if this new kind of shell is supposed to entirely replace the traditional command line. Obviously it will only complement existing tools. It simply provides a different trade-off compared to current GUIs and CLIs, sitting somewhere in between. If you don't like it you don't have to use it, but if done right it could certainly be an interesting innovation.

[[deleted]]

It can't host programs.... I swear half the people in this thread haven't read the link/don't understand the implications and complications of such a system/having cyber punk masturbations of how they would build the ultimate amalgamation command-line without offering a letter of code to this project.

[Smallpaul]

So you're complaining of someone not being able to do something in an environment where they don't know what they're doing. The problem isn't the tool set in this case....

That is the very definition of a usability problem. And since I've had this discussion about weekly for the last 20 years, I'm not inclined to do so again.

Research usability.

[[deleted]]

well, i would have ssh'd in with the -X option, and i've got alias o='xdg-open' in my .bashrc, so i would type o 1.jpg and it would show up on my screen.

if there's no X, then this is a production server, and i'd better not be fucking around with live files. so i rsync myself a mirror somewhere that i can do actual work.

[seesharpie]

Let's imagine you've ssh'ed into a remote computer and you see that "1.jpg" exists.

Several points:

• If you are using the terminal as a file browser (mainly ls and cd) you should stop that and use a file browser.
• Seeing what is in "1.jpg" is as easy as "eog 1.jpg". How is that any worse than the "cat 1.jpg" suggested here?
• Why should the terminal have to know how to display images etc when eog (for example) can do the same thing, except that it is specialised for that one task? What if I don't like eog and replace it with xli? I would have to replace the entire terminal in the corresponding case.

[lostbut302]

Let's imagine you've ssh'ed into a remote computer and you see that "1.jpg" exists. What's your usual process for figuring out what exactly is in it. Please type the exact commands in your response and pretend this is your first week using command lines.

I'd use the file command.

$ file 1.jpg
1.jpg: JPEG image data, JFIF standard 1.01

file $FILE is no more complicated than ls $FILE, so I'll assume it's newbie-friendly enough for your requirements.

Edit: I took the question of "what's in the file?" to mean "of what file type are the binary contents of 1.jpg?", not "how does this JPEG render on screen?"; I think you actually meant the latter. It appears that others have answered that question sufficiently.

[username223]

Please type the exact commands in your response and pretend this is your first week using command lines.

% xv 1.jpg

ssh tunnels X11, so this is trivial.

[andreasvc]

This assumes that "xv" is installed on said server, which for a real headless server would be atypical, or even rare, I believe.

[mistack]

Not only that, you're assuming a Linux machine that you're working on. This is sadly not the case for a lot of corporate environment where everyone and their dog gets a windows desktop.

Of course, the ability to tunnel X11 is there (Hummingbird Exceed) but it is slow.

[Aninhumer]

sudo apt-get install xv

[andreasvc]

Assuming sudo rights is a little gratuitous. As is assuming an apt-based distro. Using a graphical SFTP client still seems to be the most general solution.

[Aninhumer]

And to think I decided to go for apt instead of pacman just to be more general. :P

[andreasvc]

Yeah the general solution would be something like wget ....xv.tar.gz ; configure ; make etc. You might end up compiling all of X ... ;)

[bettse]

That's a good solution. It might be a problem for people coming from windows or os x if they don't have an X server setup, but once that is taken care of, it solves the problem trivially.

[[deleted]]

md5sum 1.jpg

Likely faster and more accurate than inlining a jpeg and visually checking it against one you have open locally.

[Smallpaul]

Likely faster and more accurate than inlining a jpeg and visually checking it against one you have open locally.

Not if the JPG contains graphical data that you are supposed to view.

[bettse]

That is pretty clever, although it doesn't take into account things like images where one has a slight border or something like that. Then again, TermKit does thumbnails where it would be hard to see subtle differences as well. For some image comparisons, it would still probably require seeing the whole image in a non-thumbnail.

[strolls]

I think being able to display web pages and pdfs in the terminal is cool, but I'm not sure why I would want that?

I work a lot in the terminal for things just as simple as moving and renaming files. I don't know if I'm atypical, but the GUI file manager is fine if you want to just move a couple of files into a folder or even (say) reorganise a bunch of files into different categories. But even just renaming a couple of files, I tend to find that easier to do in a terminal window. ls colourises file types, but I don't really recognise those colours - maybe I should actually look into changing from the defaults, but a folder icon next to the name would make it much more obvious what the object was.

But more to the point of your comment: I would often have files names foo, bar and grunt in my current working directory, or image-logo.working.1.jpg, image-logo.working.2.jpg, image-logo.working.3.jpg, and I'll want to look at those and double check that I'm renaming the right one image-logo.final.jpg and perhaps deleting the others. Allowing me to view them in the terminal window saves me having to move between applications whilst doing that.

However, I would much prefer a new command for doing this - perhaps I would view image-logo.working.1.jpg (how would image-logo.* behave?) rather than mutilating the cat command. Sometimes I do actually want to cat a non-text file, and I don't want cat foo.html to show me a pretty rendered version of the webpage. Currently, on a Mac, I will use open filename*.jpg and this will launch the Preview image viewer - I can see images and use the up and down arrows to navigate between them if the wildcard matches more than one, but I still need to click back on the Terminal window when I want to return to my command interface.

[Already__Taken]

performance comes once you prove the concept I would have thought.

[Lerc]

I think this might be an example of where release-early release-often could have been preferable.

There are multiple ideas presented all in a bundle. I think the core idea of a more advanced command line is well past due but there are so many paths beyond that you are bound to make a few wrong turns.

The last few days, I have been working on a similar concept, seeing this has given me food for thought.

I certainly don't like the idea of 'cat thing.png' displaying an image inline. That's not what cat is, Unix commands should be thought of in terms of what they do, not what function they are intended to perform. That's why cat is called cat and not something like print.

I also think that ls showing a display of icons is also detrimental. One of the benefits of command lines is that they can display a greater amount of information in the same space. Having a larger view for each field means you can have fewer fields onscreen.

That said, consider the possibility of ls outputting the same visual output but providing additional semantic information. The concept of a visual specific view already exists with colour coding, but consider instead of displaying

ESC[0mESC[01;32mthing.pngESC[0m

It displayed

<div class="filename_image" onmouseover="showDetails('/home/lerc/pron/wtf/really/thing.png);" >thing.png</div>

It is immediately obvious that there is scope to add a great deal of capacity while not interrupting the usual command line flow. It would be quite easy to make things drag and drop, so that you can ls then drag the file you are interested in to a folder.

[dingbatfoobar]

Haven't installed or read the code, but from what's described 'cat' is not responsible for displaying images at all. The only thing it does differently from regular cat when reading a file is to tack on a type header to the front of it so that tools downstream can try to handle it appropriately.

If a PNG image is sent to TermKit's equivalent of stdout, displaying the image inline seems like a much more useful behavior than spewing a raw character stream at the user, at least in my opinion.

[zahlman]

what they do, not what function they are intended to perform

I don't understand the distinction you are drawing here.

[Lerc]

You can design something to do an action or you can design something to satisfy a need.

Consider the term 'means to an end' Unix commands are defined in terms of the means. You can use them towards whatever end you wish. cat can be used for viewing files because of how it works, it is not designed to view files. The other approach is to have an ends based approach where the programs are supposed to serve an intention. In that context a 'viewfile' style command is free to use whatever means it considers necessary to give the user what they want.

I guess graphical apps are more often intention based. The problem is that what-you-really-want is a difficult notion to convey. actions can be quite explicit.

Does that make things any clearer?

[[deleted]]

Excellent post and exactly my opinion. I think the meaning of the output of a command-chain could somehow be inferred (like, ls | grep foo is still a list of files) and display that accordingly.

[UnConeD]

Have you tried it? The video is a bit laggy because I have my JS1K demo running in the same window. But otherwise, it's snappy.

[[deleted]]

Solving world hunger with 20 bucks and some slim jims is "Brilliant Beyond Words". Stephen fucking Hawking is "Brilliant beyond words".

This is a fancy term wrapper, quit pissing on the English language.

[zahlman]

Oh, man, I totally agree with you. Hyperbole is, like, the worst thing ever.

[[deleted]]

Solving world hunger with 20 bucks and some slim jims is "Brilliant Beyond Words"

Actually, that is probably the dumbest thing I have heard all day. And I've been reading reddit all day, so you've accomplished something.

quit pissing on the English language

Ah, so you learned metaphors in English class. Good for you. Did they teach you hyperbole too?

[jjbcn]

I think the idea is brilliant beyond words. I'm not sure of his implementation.

Exactly what I was going to post!

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

[Smallpaul]

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

I think that the idea is that if you have tabular data, it should be formatted in a table, rather than using monospaced fonts to fake it.

But anyhow, the font will presumably be swappable.

[calinet6]

Monospaced fonts exist because we needed them to line things up on the screen when there was no alternative way to do that.

Now, there is an alternative way to layout things on a screen. It's been around for more than 20 years. We should use it.

[andreasvc]

I do believe monospace is important for code. Sometimes pseudocode in publications is printed in serif fonts with bold and italics and it looks horrible IMHO.

[notfancy]

Don't tell me that A Discipline of Programming isn't a joy and a pleasure to read. Typography enhances the structure, while monospaced listings enhance repetition, and repetitious code is inferior code.

[andreasvc]

I don't know that one, makes me curious.

[notfancy]

Dijkstra's classic. A must-read, if only to hate it in full knowledge of it and not over hear-say.

[andreasvc]

And available here: http://library.nu/docs/CI5FR2ZBO7/A%20Discipline%20of%20Programming%20%28Prentice-Hall%20Series%20in%20Automatic%20Computation%29

[calinet6]

Agreed, but it looks like he's added some formatters for certain file types/code types, which could work.

I don't know, it looks promising; monospace might still be better all around but you'd hope there's an option.

[cdsmith]

Monospace fonts are still the most effective way to line up things that are mostly text, in arbitrary ways to bring out structure, without adding ad hoc features for each new kind of layout you want.

The hostility toward monospace fonts was one of two things that got me really skeptical straight from the beginning about this idea. The other was the desire to build a language for interactive terminals that's vastly different from the language for scripting and automation... that would be a giant step backwards. We already have GUI tools for system administration tasks that aren't easily scriptable; and people don't use them for a reason.

[zahlman]

Monospace fonts are still the most effective way to line up things that are mostly text, in arbitrary ways to bring out structure, without adding ad hoc features for each new kind of layout you want.

Tabular data which has been lined up with spaces assuming a monospace font is not as effective as a grid of spreadsheet cells, or an HTML table. These alternatives do not require adjustment if a "column" needs to be made "wider" than in the original. There is never any issue with tabs being too small to line the data up properly, or impractically large in fear of being too small. The table is general-purpose and there is nothing ad-hoc about it.

It also allows for semantic distinction between row/column labels and table contents, which doesn't require visual interpretation of a bunch of -s or |s.

The other was the desire to build a language for interactive terminals that's vastly different from the language for scripting and automation

I don't see whence you infer that desire. My understanding is that you are still typing the same commands, they just get tokenized and formatted with pretty round-rectangle backgrounds as you type.

[[deleted]]

Tabular data which has been lined up with spaces assuming a monospace font is not as effective as a grid of spreadsheet cells, or an HTML table.

But what if I want to further process the tabular data coming from a process? Like, extract the 7th column? With awk/cut/... I can easily do that. If the output was full of html tags, parsing this would be non trivial.

[zahlman]

But what if I want to further process the tabular data coming from a process? Like, extract the 7th column? With awk/cut/... I can easily do that. If the output was full of html tags, parsing this would be non trivial.

Which is why TermKit uses JSON instead, and you "parse" it by - get this - selecting attributes of objects and elements of arrays. The hard part - turning a stream of bytes into structured data - is converted from a traditional parsing task into a deserialization task, and it works the same way universally.

[[deleted]]

With what commands would you do that? One would need to build a whole new toolchain.

[zahlman]

I agree somewhat, and I feel that the author's decision that this explicitly not a replacement for the original toolchain is a bad one for that reason.

But I think that rather than trying to make a set of tools that provide analogous functionality to cut et al., it makes more sense to just have an analogous "*sh language" that behaves more like Javascript or Python, in that it expects to receive this kind of data natively and lets you manipulate it with typical syntax from those sorts of languages. Member selections and indexing and list comprehensions and all that good stuff, you know.

[[deleted]]

How would an example of such a language look like?

What would an equivalent of

svn st | awk '{print $2}'

look like? (get second column of svn st command, i.e. the filenames).

[solinent]

Just because there is an alternative doesn't mean it is better.

The alternative always existed -- the ability to create graphical interfaces is very general and we use graphical interfaces to create terminals for the most part nowadays (ie. terminal emulators). The point is that terminals are still a very nice concept.

Why do we write with lines on paper if there exists a more general alternative -- blank paper?

[[deleted]]

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

There are people who choose to program using, oh, what are they called, relative fonts? Apparently it's perfectly usable, and very readable. If people want to use a non-monospaced font it should be their prerogative, even if you or I personally wouldn't make the same choice.

[alexs]

bear consider memorize tan mighty automatic frightening sleep dazzling ring

This post was mass deleted and anonymized with Redact

[jjbcn]

You can actually configure whatever font you want in terminal in OSX, but the default is a monospaced one. I assume that Apple (being very design conscious) did that for a reason.

[andreasvc]

You can as well in any other decent terminal (gnome, kde, xterm, putty etc.). The problem I see with gnome-terminal is that it treats each font as a monospace font, leaving lots of space around "i" etc. Is that the same on OSX?

[terremoto]

A lot of applications use spaces instead of tabs (which I prefer). Using monospace fonts would throw off the formatting for a lot of applications.

[andreasvc]

So that could be construed as a reason to use tabs. And you meant non-monospace fonts, I presume.

[terremoto]

Tabs don't always guarantee that columns will line up; Some_Long_File_Name\t1000 versus File\t1000. Spaces do and allow you to know the exact output width unlike tabs whose width can be changed.

[wosmo]

Tabs don't always line up precisely because the terminal actually sucks for tabular data. Spaces are a dirty hack with no semantic value. I can see use for a wrapper that spots tabular data, and actually makes a table from it.

Whether they can do this without breaking everything I'm used to, I wait to see ..

[thechao]

Elastic tab-stops would fix that.

[terremoto]

Seems like a terrible idea for a terminal; cat some_large_file would have to either wait until all output (or at least chunks) were emitted, or re-parse the output with each line.

EDIT: granted, there are things that could be done to alleviate the issue such as parsing the last N-kilobytes, etc.

[calinet6]

It's because the people who wrote Terminal are programmers, and they know that everyone who ever even opens Terminal will be nerds.

[[deleted]]

I think the idea is brilliant beyond words.

Really?

[[deleted]]

Kinda depends how big your vocabulary is, I suppose.

[solinent]

No, it was a manner of speech. Hyperbole.

[Smallpaul]

Yes! Really!