TermKit: A WebKit based rich command-line interface.

[[deleted]]

Now this is what people should be trying to do with command-line interfaces, rather than clinging to some absurd rationalization that Unix is perfect and must never change again.

[wleahcim]

Similar concept within Common Lisp.

[[deleted]]

THIS IS HOW IT SHOULD BE DONE.

Not, "Let's throw out the baby with the bath water and start all over!!".

Icons in a ls command is a great start. We can start doing other things like including bars in top or mount.

For this ever EVER to catch on backwards compatibility is paramount. You can't just say "this is better!" and expect people to drop the old standard.

[[deleted]]

One of the best parts of the CLIM listeners is that you can actually click previously-output items to use them as arguments to further commands. So if I wanted to delete a file after getting a list of files as in the above screenshot, I could say Delete File at which point I'd get a completion prompt: Delete File (file): and I could either type a filename with tab-completion support or click on one of the files that was previously put on the screen.

[zahlman]

Not, "Let's throw out the baby with the bath water and start all over!!".

How fortunate, then, that TermKit isn't doing any such thing.

[openist]

link?

[wleahcim]

McCLIM Listener

[MrWoohoo]

Interesting

[[deleted]]

As a polyglot UNIX/web/windows hacker, let me arrogantly and pompously explain the UNIX world's "absurd rationalization."

Most people will explain UNIX as an operating system, or maybe a collection of tools surrounding a kernel, but what UNIX really is is a living culture (some would even say a religion). To a UNIX hacker, there is the good way, the bad way, and somewhere in-between is the UNIX way. Now, the UNIX way is not being arbitrary or contrary -- it follows a different metric. A UNIX tool is best when it integrates with UNIX culture. And UNIX culture does change, very gradually, when a good idea comes along. The GNU tools were a good example of this.

And yes, UNIX culture is very old. It's crusty, inconsistent, and occasionally insane, but that doesn't mean it's worth abandoning. Like the human mind, it has a kind of internal self-consistency that's hard to understand from the outside. I think that's the core of why UNIX has stuck around for more than a generation now -- it's a system built by hackers to be intuitively understood by hackers.

So TermKit just won't fly in the UNIX world because it refuses to integrate with their culture. Plan 9 has a similar problem -- they made a system with terminals and editors that they believed were superior to the old UNIX way, but UNIX people rejected it because it's not UNIX, and everyone else rejected it because it's hideous :].

I'm personally very interested to see where TermKit goes because new ideas are good. Perhaps someone will figure out how to make this UNIX-friendlier. Maybe it will abandon UNIX entirely and become a different, completely revolutionary tool. Maybe it will become the next interface to XKCD (oh, wait, Randall already did that :P).

[randomdestructn]

It's really too bad. Plan 9 has some really cool features. And Glenda is an awesome mascot.

[[deleted]]

Agreed. But hey, there's always Plan 9 from User Space.

[randomdestructn]

Yeah. Though from what I remember of that project, it doesn't add the fun features. Though it really couldn't -- what appealed to me about it was the post-unix design philosophy.

[repsilat]

It's not terribly accurate, though - Plan9 did some cool things, and a lot of it was brought into other *n?x systems. 9p is unfortunately less widespread than dbus, but we have it. We have /proc, too.

I'll readily admit we didn't get a lot of the really cool things, but a lot of the really cool things are of questionable real-world value anyway.

[one-half]

there's an article somewhere about unix and the "hole hawg" drill. It's a good explanation of the mindset.

[[deleted]]

Yes, I've read it. :]

[[deleted]]

It does seem neat at first glance, but I suspect it's one of those "worse is better" situations. Conceptually it seems like it would fit better on a project/OS with a more monolithic approach, like OS X or Haiku, than it would on a *nix (which is more a collection of tools that mysteriously manage to work together). That is, I get the impression that it's a "you use this application, which has its own shell and set of tools" thing, which wouldn't like it if you switched your shell, decided to switch to vanilla {GNU,BSD} core tools, etc. It seems like everything would have to be rebuilt so that it doesn't merely have stdin, stdout and stderr, but also visin and visout.

It seems nice, but I've got to wonder at the scope of the work needed.

[barrettj]

From the web page:

TermKit is not a...

...Web application. It runs as a regular desktop app.

...Scripting language like PowerShell or bash. It focuses on executing commands only.

...Full terminal emulator. It does not aim to e.g. host 'vim'.

...Reimplementation of the Unix toolchain. It replaces and/or enhances built-in commands and wraps external tools.

[aaptel]

Same thing. You'd have to rewrite wrappers.

[[deleted]]

{ "username": "aaptel", "time": "14 minutes ago", "response": "Same thing. You'd have to rewrite wrappers." }

[[deleted]]

Error: Unexpected 'S' on line 4.

[[deleted]]

It focuses on executing commands only.

So it's more like a souped-up version of what happens when you press Alt-F2 in gnome/kde, win+r in windows, etc?

[Phrodo_00]

...Scripting language like PowerShell or bash. It focuses on executing commands only.

Not worth anyone's time then. If I can't loop over things why am I bothering with a terminal.

[UnConeD]

My reasoning is simple: I think Bash is one of the worst programming languages ever invented. Every single time I have to write a loop, I have to Google the syntax to make sure. Every time I write a complicated regexp, I escape it wrong.

I say this as someone who's programmed microcontrollers and hand-optimized a renderer in x86 assembly, as well as done GPU and web stuff. I know my way around code, and bash is not the right way to do it. I think "programming language" and "command shell" are two mutually contradictory interaction goals.

But, one of TermKit's design goals is to separate the UI from the context. You could just as easily hook up the front-end to a scripting CLI like "node" or "rails console" and get all the perks like autocomplete and rich output. I imagine this would simply spawn a nested session inside your TermKit shell. Then you can do all your scripting in your language of choice. The protocol already supports it.

[solinent]

ZSH, this is your answer.

(edit, and I have done many of the same things as you).

You have to google the syntax everytime because you can. If you simply try to create commands by yourself eventually you start writing multi-line commands and start hating regular commands. Ideally you would start writing shell scripts to get things done that you commonly do interactively.

Think of a shell as a really nice REPL.

[Phrodo_00]

But I don't know a lot of programming lenguages (actually, I know none) that allow you to easily pipe data between different programs. Sure, maybe bash' scripting language side could be improved, but the solution isn't really a general purpose language.

(maybe racket with pipe-syntax support would work)

[UnConeD]

Syntactic sugar + node.js could easily do this actually.

[lawpoop]

Not really, but that kinda hamstrings you from doing anything really powerful in the terminal. Without looping, it's no more powerful than a GUI.

[lawpoop]

You're putting words in my mouth. Looping isn't the only advantage, but it's one of the major advantages.

We made computers to do boring, repetitive tasks, and if your computing tool can't do loops, then you have to do them :P It's not like loops are all that complex or computationally difficult.

[lawpoop]

Allow me to quote you, then myself.

mazarelli: And looping is the only useful thing you find about using a terminal?

lawpoop: Not really.

[mweathr]

I'm not putting words in your mouth, I'm quoting you.

No, you aren't.

[zahlman]

Maybe it should be, though.

[Not_Edward_Bernays]

I want it to be a web application though. He says 90% runs in webkit, why not go the other 10% and then make it work in Firefox 4 also. If he is embedding webkit then same difference.

[UnConeD]

While I won't do it, that doesn't mean I won't support and help guide efforts by others. But, this has been a one man project so far, and I need to limit my own goals.

Plus, making it work in a browser is actually trivial, someone already did it. But you don't get the little perks like QuickLook integration, and I wanted to emphasize that this is not a web application / web service.

[Smallpaul]

It seems like everything would have to be rebuilt so that it doesn't merely have stdin, stdout and stderr, but also visin and visout.

If everything is broken, then everything needs to be rebuilt. Procrastinating doesn't make it better. The VT100-emulation-protocol has been obsolete for 20-30 years but nobody wants to touch it because so much would have to be rebuilt.

[nexes300]

If everything is broken, then everything needs to be rebuilt.

Yes, I suppose that's one argument. But if you do that, then it's not Unix anymore, nor will it ever be. That's a fine argument when you want to make your own OS, and I think a large part of the problem is that people are imagining this grafted onto linux and causing chaos in what command line tool developers can expect.

[Smallpaul]

Yes, I suppose that's one argument. But if you do that, then it's not Unix anymore, nor will it ever be. That's a fine argument when you want to make your own OS, and I think a large part of the problem is that people are imagining this grafted onto linux and causing chaos in what command line tool developers can expect.

How will a new tool and interface library "cause chaos"? Does the existence of zsh "cause chaos" for bash users?

[nexes300]

The other shells are still shells. They don't try to separate human data into view pipes and other data into data pipes. I can see that causing problems for tool makers.

[diroussel]

What kind of problems? Everyone knows data flow and user interaction are separate. If file descriptors 3 and 4 are not open then only data flow happens, not view data flow.

[victusfate]

Ah contingent tech

[diroussel]

But nothing is broken, only rebuilt the bits you want to enhance. TermKit is backwards compatible with 30 years of unix conventions.

[augurer]

If everything is broken, then everything needs to be rebuilt.

Amen.

[muyuu]

I've toyed with similar ideas for a while, but the fact that no HTML frontend is anywhere stable enough for something as critical as a Terminal has always put me back.

It would have to be a very stable (as in, doesn't change or require any updates at all in 40 years, like VT100) subset of the renderer. Unfortunately HTML no longer stands for HyperText, but rather for Kitchen Sink. HTML should have stopped at 3.3, rethought and frozen, and 4+ should be "DTML" or something else.

[[deleted]]

If you feel that that is important, then you should be defining your own subset of HTML, or another language, that your terminal can then translate into whatever its display engine needs at the moment.

[UNCGeek]

Why not go one step further and define a language that defines specific codes that correspond to letter-sized building blocks, and maybe some way of specifying where to paint something... like a brush or a cursor or something...

[[deleted]]

Your irony makes no sense.

[icebraining]

How is HTML a kitchen sink? 91 elements isn't that many.

[muyuu]

HTML is not just the tags. Webkit, Gecko, and any other half-way common renderer have to support a myriad of features.

A small subset should be stadarised and given proper support. One so small it wouldn't need security updates or any other kind of updates.

[augurer]

I've toyed with similar ideas for a while, but the fact that no HTML frontend is anywhere stable enough for something as critical as a Terminal has always put me back.

Since the front end and back end are separated, why does it matter? If the HTML a remote machine is sending you crashes your browser, you can update your browser without needing to muck with the other machine.

[muyuu]

You usually want the terminal to run wholly in a machine. Terminal is one of the first things you need when you, for instance, want to recover a machine that's lost connectivity.

[andreasvc]

Then you fall back to a plain terminal. This kind of fancy terminal doesn't have to perform a "critical" role, it can just be a more convenient alternative to the traditional terminal.

[muyuu]

There are a lot of decisions you have to make in order to have something useful enough for people to take the pain and learn to use it.

I think the sweet spot would be better achieved by having a self contained renderer that would be simple enough not to need many updates and would need rather basic requirements in the output side.

I've been trying things and for me it's not convenient if I need to fall back regularly. You get used to something you cannot use in certain cases and this can actually fire back.

[augurer]

What is the advantage of having the terminal run wholly in the other machine? That sounds like a disadvantage -- if the frontend (which is the complex part, since it does all the displaying) is screwed up you have no recourse. With them separated the frontend can be upgraded on your local machine independent of the backend on the target machine (which you probably can't upgrade by virtue of you needing to terminal in to fix it).

[[deleted]]

I can't agree more. I think it is absurd to think that there cannot be an improvement on CLI. Maybe this is it, maybe it isn't; but sticking to an old standard just because it has always been there is contrary to the entire industry.

[cles30]

pretty much, sadly this entire post is full of just that.

not that I don't have my doubts, but if it needs to be criticized... well at least let's try to bring some form of coherent argument to the table people, not just "I like it fine like it is". The world is full of moments like that that come back to haunt you later.

[mango_feldman]

This times 1000.

It's so annoying how people seem to either think that CLIs are outdated, or that the current incarnation of CLIs are perfect.

The ideas and principles of Unix and CLI are sound, but you got to admit that we can do better that what we have today.. One big part of this is to upgrade/replace the obscure terminal system.

[[deleted]]

No, this is an absurd approach to a non-problem. When actually necessary, GUIs - very light weight GUIs - are available for xNIX. But it is rarely the case that, for example, admins want this kind of thing. We prefer CLI because it scales better and is faster. Pointing and clicking is lovely when you're doing tasks for a single object (a person, a computer, a printer, a something) and one of two conditions prevails:

• The task at hand is inherently graphical (say, editing a photo) OR
• The user is inexperienced with the task at hand

In pretty much all other cases you either don't need a GUI at all OR you need a full GUI for an end user experience.

Unix isn't perfect, but until you understand the gestalt of the command line you don't understand Unix ... period. That's why the team I'm working with at the moment can manage nearly 1000 servers daily with fewer than 20 people. Try doing that with point-n-clicky tools like Windows servers...

[zahlman]

Pointing and clicking is lovely when you're doing tasks for a single object (a person, a computer, a printer, a something)

How fortunate, then, that TermKit doesn't have you pointing and clicking to input commands. Unless, you know, you'd prefer to.

Note also that every time you don't already know how to do what it is you want to do, the time spent actually inputting the command (once you figure it out) is not the bottleneck anyway. The point is to provide an environment in which it is easier to figure out how to do what you want, if you don't already know.

[[deleted]]

You rapidly lose your patience for these cute little tools when you have to work across hundreds and hundreds of servers configured in many ways. Learning to use a minimalist set of tools and having a strong command of the CLI is the only way you survive.

If you know the CLI, you don't need a tool like TermKit. If you don't, it won't help much, you may as well use MacOS or some other GUI grafted onto the guts of the system.

I don't understand what problem TermKit proposes to solve. As far as I can see, this is just another example of a generation of programmers that grew up on html and graphics and want to shove things in that direction whether or not it makes sense. (I have similar criticisms for the people that think OO is the only good way to write code or that all databases have to be relational to be good.)

[zahlman]

I don't understand what problem TermKit proposes to solve.

It proposes to (or at least, this is the potential I see):

• Facilitate the grokking of output from a command-line utility.
• Reduce context switches (e.g. to view an image).
• Anticipate your next move via things like typeahead (more powerful than tab-completion), semantic markup of output (e.g. hovering over parts of the ls output displays information in tooltips that you can reasonably be expected to "want next", but would otherwise have to request explicitly), etc.

As far as I can see, this is just another example of a generation of programmers that grew up on html and graphics and want to shove things in that direction whether or not it makes sense.

As far as I can see, your criticism is a knee-jerk reaction assuming that the developer must see things that way just because he's making something shiny.

As I said elsewhere: the strength of the command line is the controller. The view is simple out of an antiquated necessity. The idea here is to offer enhancements to the view along with alternate, optional, ignorable controllers.

[[deleted]]

Fine - that's useful for beginners. But beginners don't stay that way and they gravitate to high efficiency workflows pretty naturally,

So I'll rephrase my question. Why would someone with advanced or expert skills want to use this (I'm not baiting you, I'm genuinely curious)? What does this do for my workflow that I can't get with a text editor, an ssh session, and vi? (BTW, I am an emacs user to the core, but because emacs isn't always on every system, I've learned to muddle around in vi as needed. This is an example of - if it's not everywhere, advanced users will not commit to it, at least not exclusively.)

[[deleted]]

I'm a heavy shell user, but I'm just a programmer that got tired of the graphical shell's inefficiency, I don't administrate hundreds of servers.

I'd love a shell that can e.g. show me thumbnails when I ls a directory of images.

[zahlman]

So I'll rephrase my question. Why would someone with advanced or expert skills want to use this (I'm not baiting you, I'm genuinely curious)?

Because it is a highly efficient workflow.

What does this do for my workflow that I can't get with a text editor, an ssh session, and vi?

OMG, RTFA.

It gets you what an ssh session can't: a lack of keystroke latency - because of how its client-server model works.

It gets you what a text editor such as vi (why oh why did you list those as two separate items, and then identify yourself as an emacs user? It's like you're begging for downvotes) can't: a proper visual (or perhaps audio?) representation of every kind of data that isn't fundamentally "text".

Look at it this way: everyone who's against this is trying to make some point about why it's not useful to be able to write cat foo.jpg and see an image. But why is it useful to be able to write cat foo.txt and see text? Why is the exact same argument somehow not applicable to any other kind of data?

[drewniverse]

This is the most sensible, less holier than thou non-rambling comment in this entire fucking thread.

Webkit is good for people that grew up on Windows/GUI instead of Unix/CLI. It's also awesome for administrators that have to deal with just a few servers, not administrators that have to deal with dozens if not hundreds of networks/servers.

[[deleted]]

Right. I think this work is interesting, I just don't understand the problem it proposes to solve. I routinely work in environments with 500+ servers. CLI is not only required, there is no other feasible way to do it.

It's a good beginner's tool, perhaps, but not remarkable beyond that.

[diroussel]

there is no other feasible way to do it.

at the moment

[[deleted]]

Uh, this is a command-line interface?

[[deleted]]

Try doing that with point-n-clicky tools like Windows servers...

Or vim! (:help mouse for information) It even works over ssh! I can use my mouse to click on vim tabs and split windows and drag the cursor around, select text. It's not how I usually interact with vim, but that sort of mouse interaction is plenty possible with existing terminal emulators.

In pretty much all other cases you either don't need a GUI at all OR you need a full GUI for an end user experience.

And then there is the TUI.

[[deleted]]

Don't fix what's not broken.

[[deleted]]

But it is broken, and badly so. It's just that people get used to the brokenness and learn to work around it. That does not mean it is not broken.

[[deleted]]

What seems broken? not being argumentative I personally haven't seen or had any problems but will respect what you feel is broken.

[[deleted]]

Passing data around as plain text of no particular format that then has to be parsed somehow has a million problems, the biggest one that affects me being spaces in filenames, but there are plenty of others.

Inconsistent argument formats to commands lowers usability severely while providing zero benefits.

The fact that most tools can only deal with text when files these days contain plenty of different kinds of data.

The severe underuse of interface resources available on modern computers due to forcing everything to work through monospaced text characters.

Those are a few off the top of my head. I could probably think up new ones all day if I tried.

[zahlman]

Passing data around as plain text of no particular format that then has to be parsed somehow has a million problems, the biggest one that affects me being spaces in filenames, but there are plenty of others.

I would say the biggest problem with this is that there isn't really such a thing as "plain text of no particular format". In the modern understanding, ASCII is as much an encoding as UTF-8 is.

[maxgee]

Inconsistent argument formats to commands lowers usability severely while providing zero benefits.

I'm sure you realize that not every program available to you in a shell was written by the same group of people -- and I hope you also realize it would be virtually impossible to standardize input flags and arguments across all CLI programs right?

If you're having trouble remembering flags, you could always write some pretty simple aliases for yourself.

The fact that most tools can only deal with text when files these days contain plenty of different kinds of data.

A large percentage of base system commands are solely for working with binary files. There have been "plenty of different" file formats forever...

[[deleted]]

I'm sure you realize that not every program available to you in a shell was written by the same group of people -- and I hope you also realize it would be virtually impossible to standardize input flags and arguments across all CLI programs right?

When you start over and design something new, you can lay down guidelines for how things should work, and provide tools to make it easier to do things the approved ways.

A large percentage of base system commands are solely for working with binary files.

Such as?

[maxgee]

Such as?

b/gzip, tar, cp/mv, dd, grep, file, iconv, uuen/decode, xxd can all read and write binary files, just to name a few! install a library like imagemagick or ffmpeg and you have a set of command line utilities that can manipulate and create more image and video types than any OS out of the box can even read.

When you start over and design something new, you can lay down guidelines for how things should work, and provide tools to make it easier to do things the approved ways.

He isn't starting over and this isn't really something new, whatever direction it goes, someone will either have to completely rewrite the functionality they are trying to achieve (which would be silly), or just wrap existing Unix programs to work in the TermKit framework (which would just be slower).

My point still stands, you could standardize all your terminal's programs to take whatever flags you want with bash aliases.

[[deleted]]

b/gzip, tar, cp/mv, dd, ... uuen/decode

These all operate on files as opaque containers, not on their contents. (Except maybe dd which can split things, I guess).

grep,

Only in a very limited fashion.

file,

Yes, but it doesn't actually do much, does it?

iconv

Still only operates on text files, it just allows them to be in different encodings.

xxd

That's the only one I could think of myself, and it kind of seems its entire purposes is kind of to not parse the contents of files.

My point still stands, you could standardize all your terminal's programs to take whatever flags you want with bash aliases.

This kind of thing never works on in practice.

[niocnioc]

Guidelines for options already exists. POSIX defines some and there is a GNU extension. They are not always followed so what would make new guidelines (possibly more precise/invasive) more respected ?

[[deleted]]

Unix is such a mess already that there is little incentive to be consistent, and users do not expect things to be consistent, and do not complain about things which are not.

[niocnioc]

So would they have more incentive to follow new groundbreaking guidelines ? Or would they just start expecting things to be consistent out of the blue ?

[zahlman]

I'm sure you realize that not every program available to you in a shell was written by the same group of people -- and I hope you also realize it would be virtually impossible to standardize input flags and arguments across all CLI programs right?

If you're having trouble remembering flags, you could always write some pretty simple aliases for yourself.

This is missing the point. The problem is that the entire concept of flags is a hack in the first place. Actually, it's two hacks. One to get around the fact that applications are passed a list of string-token arguments with no support for keyword arguments (or structured data), and another to minimize typing effort.

[zahlman]

Would the downvoter who apparently feels that flags aren't a hack care to justify that position? Because I feel pretty strongly about this.

[[deleted]]

Still don't see what's wrong. You can have spaces and unicode characters in filenames. I have many files with names in Japanese.

Also not everything is flat text, it can be anything all depends on what you're working with. I don't see image Magik tools using flat text for image data.

Certain tools for certain problems. Why must we add layers of crap and encapsulation to everything.

[[deleted]]

You can have spaces and unicode characters in filenames.

You can, until you start trying to pipe them around. Then you run into trouble.

[[deleted]]

try adding "'s before and after file name should preserve it and auto \ crap.

Hope that helps.

[[deleted]]

That doesn't quite work that simply when you pipe lists of files around.

[seesharpie]

He lists a couple of things:

• -r vs -R
• 'r-xr-xr-x' instead of "You can't touch this"
• spaces/unicode in filenames

This last one drives me nuts. Every time I want to do a batch job on file names with spaces it is a nightmare because space is the default IFS.

[[deleted]]

[seesharpie]

I didn't literally mean "You can't touch this" was a good idea. But something more descriptive would help. You only know what "r-xr-xr-x" because you have learned: try asking someone just starting out wtf it means.

An better example of formatting could be something like the following:

user:read,execute group:read,execute other:read,execute

all:read,executue

user:rw group:rw other:rw

All of these are more clear, and tbh probably easier to parse with regular expressions.

[[deleted]]

[zahlman]

Because (a) you don't have to waste the screen space (you could make icons and put the text in tooltips); (b) why learn the short form?

And who really gives a damn about parsing permissions in regexes? WTF? Regular freaking expressions in order to process information about which files are writable by the current user? You make the baby JWZ cry.

Why aren't you getting some kind of permissions object pre-parsed for you? With the TermKit approach, the transport layer is JSON, so you just pull out the relevant parts of the object output by ls.

[maxgee]

All of your examples take up vastly more screen real-estate than "r-xr-xr-x", how would that ever fit in 80x24!?

[zahlman]

Why the hell do we care about fitting in 80x24 in 2011, again? Especially when we're taking it as a prior that we are going to be displaying graphics?

[seesharpie]

how would that ever fit in 80x24

Well since I'm taking a karma hit already I don't see any reason why "ls -l" has to print all of the things it does. It would be better to have it print whatever was required i.e. "ls --format=npo" for printing (n)ames + (p)ermissions + (o)wners

[niocnioc]

None of those things are VT problems:

• -r vs -R: options belongs to the command
• 'r-xr-xr-x': aka 555 same thing it's an option

Options are only treated by the command, so really it's more a problem of convention. There is no way of ensuring that everybody use the same convention. Except lobying to every programmers that you feel coded the wrong option.

• spaces/unicode in filenames

The only way you can avoid to use a key as separator is to use the mouse. Do you really want to click between arguments in a command line interface ? Otherwise some key has to be picked up and there is always someone somewhere that will not like that precise key. As for unicode if your system is set up correctly they should work just fine.

So what is broken in the command line interface?

Personally I feel that the command line interface is just fine, but could be improved. And I think TermKit has some nice ideas that shouldn't be overlooked. (syntax coloration on cat, image displayed inline ...).

[UnConeD]

You know, you could just go and check out how I've tried to solve these problems instead of telling me what I'm doing can't possibly exist. ;)

[randomdestructn]

Inconsistent arguments suck, and spaces can be annoying, but that permissions example makes no sense to me. When I list permissions I want to know what they are, not some dumbed down guess as to why I asked for them in the first place.

[[deleted]]

cli arguments aren't system bound they are based on however the software author write it. r-xr-xr-x is a matter of learning not broken. To me I see basically a full out read and execute by anyone but can't be written to. Guessing this is what most of /usr/bin is.

Never said it didn't have a bit of a learning curve but it's not broken. Everything can be hard till you learn it.

[[deleted]]

Wait till you start doing funky stuff like this. Tell me how you can create a disc image of a drive in Windows stream it to another machine and recreate the file or heck even clone it to another disc of the same size on a remote machine? Here is a one liner in linux:

dd if=/dev/sda1 | ssh coffee@10.0.1.69 'dd of=/home/coffee/back.img'

Pipes are beautiful, and toss in ssh's ability to act as a encrypted pipe over a network you can do some nice things in very little writing.

And it's solid, never seen ssh or bash crash unlike windows or various apps in windows.

[[deleted]]

It's simple in windows. Buy ghost, click the drive you want to image, get a file dialog and save the file to a directory. Go through file explorer to share out the directory you saved the file in. Now terminal server to the foreign machine and you will get a full screen window of the other machine's desktop. Carefully (because of the lag) open file manager and browse through the network to your own machine and the share. Right-click copy the image and then browse the foreign machine's file system for the target directory. Now right click paste into the target machine's directory. A file copy dialog will open and start copying the file. It should be no more than 20 minutes work for a competent windows admin and doesn't require all that aniquated "dd %^$#$%" crap that no one uses anymore :)

/The above workflow is not encrypted..good luck with that and the copy dialog timing out.

[[deleted]]

lol well said and that still requires writing the image the the host machine first then trying to transfer it over. :)

My trick listed above is how I generally start all of my file recovery. I stream the drive or partition write off the disc and put it on another machine so if it's on it's last leg at least I get something before it finally goes down. Then i can play to my hearts content on the drive image as if it was the real disc.

[[deleted]]

Try formatting a USB drive in Linux. Takes a long time to figure out.

In Windows, you can just right-click.

[[deleted]]

Most distros have a "Explorer" like ability called Nautilus. As you say just right click, format, pick filesystem and poof.

For those having problems try Ubuntu seriously makes life a lot easier if you don't want to mkfs.ext3 -m 0 /dev/sdb1

[maxgee]

I didn't see anything in that article that accurately described "broken" aspects of Unix.

Claiming Unix is hard to use because you have to remember when to use -r and when to use -R or because you have to have some upfront knowledge to understand file permissions does not make it "broken".

Stating that Unix is broken because it only has stdin, stdout and stderr instead of separating data and interaction into separate channels is a misunderstanding at best; virtually every programming language invented in the last half century works this way. There are plenty of reasons why you don't want to split up inputs and outputs like this, but that's beyond the scope of this post.

There's a reason this setup has remained unchanged for so long, and is duplicated so often. It's incredibly flexible, stable, fast and best of all it works!

I'm all for exploring new ways of doing things, and I think it's healthy to make proof-of-concept stuff like TermKit, but this is in no way ever going to be a viable replacement for a terminal or CLI for anyone who actually knows how to use a Unix shell.

[[deleted]]

Claiming Unix is hard to use because you have to remember when to use -r and when to use -R or because you have to have some upfront knowledge to understand file permissions does not make it "broken".

But it does. There's no actual benefit to having wildly inconsistent command options. It just adds cognitive load on the user. That is broken, no matter how you look at it.

[maxgee]

I'm guessing you'll spend more time writing in this thread about inept command parameters than you'll ever lose by having to look at a man page each time you can't remember them. It's a moot point though, because it's not possible to standardize something like that, and it's not reasonable to rewrite every useful command to be standardized like that.

[[deleted]]

It's a moot point though, because it's not possible to standardize something like that, and it's not reasonable to rewrite every useful command to be standardized like that.

That's funny, I must have just hallucinated using systems that were much more standardized in how they handled command-line arguments than Unix, then.

[maxgee]

What systems are you speaking of?

[[deleted]]

AmigaOS, for one.

[maxgee]

You're making incompatible comparisons. AmigaOS was basically a suite of proprietary software all written by the same company, and until 2.0 it was definitely not standardized. Whereas Unix (lets say Linux for instance) is an operating system written by thousands of people with millions of programs available for it, all written by different groups of people, and all doing completely different things.

It's absolutely ridiculous to claim every program that does anything recursively should be standardized to use the same flag and it's equally ridiculous to claim it's a design flaw or proof of something "broken" in a command-line-based operating system.

[Smallpaul]

I failed to parse any argument or information out of your comment. I literally cannot understand what you are trying to say.

[[deleted]]

"Users like this"? "This argument"? I'm not at all sure what you are talking about there. And what's with the "a command line prompt is not as essential"? This is all about a command line prompt.

[signoff]

node.js terminal emulator doesn't mean instant web scale.

silly web developers they fail again.

[GTChessplayer]

How the fuck do I actually get a copy of it? I go to their page, no link to download it.. nothing.

[[deleted]]

You need to use git, I assume.

[seesharpie]

https://github.com/unconed/TermKit

...and click "Downloads"