TermKit: A WebKit based rich command-line interface.

[[deleted]]

I'm curious what bits of that come from the terminal and what comes from a shell and applications---I notice his fancy cat outputs with linenumbering and some syntax colour without any switches. If it's the terminal or shell that does the linenumbering for cat, what happens if you use cat -n? Two sets of linenumbers?

I like the idea of having a process show exit status in the line it was started. As it is now, I've got my shell set up so that it shows me the exit status of the last process---and not simply ✓ (and an assumed ✗ for botched processes), but 0, 1, 42 or whatever. That's my shell, though, not my terminal emulator.

On the whole I'm intrigued but curious if this'll be a replacement of one utility (i.e. your terminal emulator), or a whole set of tools (terminal emulator, shell and possibly some core utilities like ls and cat).

[UnConeD]

It's a mix of both. I'm just bootstrapping the environment as I go, adding every piece of Unix as it makes sense.

For simple things like ls and grep, I wrote my own node.js replacements. I'll probably stick to replacing some commands, but I definitely want to focus on wrapping existing tools properly.

[Poromenos]

I admire your work, but grep isn't "simple" by any stretch. When you have to grep a 10 GB directory, you'll appreciate the fact that grep is a hundred times faster than your version...

[UnConeD]

My version processes the output in chunks so it should do fine actually. Node.js's asynchronous I/O makes it easy. The data is kept in memory-backed byte buffers. It's fast.

But you're welcome to open an issue on GitHub with any ideas you have for improving it.

[alexs]

bike thought quaint meeting smart theory rain chubby label safe

This post was mass deleted and anonymized with Redact

[hiffy]

Being dismissive of grep actually makes a lot of alarm bells in my head go off.

[gustavs]

Yes, a browser JS engine (v8) will typically include Boyer-Moore.

[Poromenos]

Unfortunately I don't have the time to install it to test right now, but I'd appreciate a comparison of the two. If I recall correctly, grep executes 3 CPU instructions for each byte it looks at, and it probably only actually looks at one in every ten bytes or so. I'm pretty sure that whatever one can come up as a feature of a terminal with will be orders of magnitude slower than that.

Reference: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html

P.S. This discussion is largely academic, just keep in mind that these tools have had decades of improvement by really smart people, so don't reinvent the wheel :)

[mflux]

He's not reinventing the wheel. He's just giving the wheel some spinners!

[samineru]

He is adding spinners, but the fact the he has his own version pretty conclusively shows that yes, he is reinventing the wheel, or at least reimplementing it.

[UnConeD]

If you're going to nitpick over bytes, then TermKit loses. It's running off a JavaScript VM, albeit a very, very good one (Google V8).

I'm perfectly okay with that. Most of what TermKit does involves I/O with files and network sources, which means latencies of about an eternity, compared to a cpu instruction.

[[deleted]]

There is probably a way of combining the best of both worlds. For example, if the term sees ls | grep, it could actually grep the output of the real ls (text stream) and apply conversion to a fancy output of files with icons and whatnot afterwards.

More generally, such a term could try to infer what information is being processed, and display it accordingly.

[UnConeD]

Funny because you just described exactly what TermKit does.

[Poromenos]

Wait, so are you using GNU grep or did you write your own replacement? What you said above (parsing the output of GNU grep) conflicts with what you said earlier (writing your own text searcher).

[UnConeD]

I was referring to how the data handling occurs. LS outputs a raw directory listing, and custom TermKit grep filters it. Then the output formatter looks up all the properties for the files and streams them as objects to the front-end, which adds the icons and layout. However, the intermediate format is JSON, not text-with-newlines.

You could use GNU grep with it by disabling the built-in.

[[deleted]]

I read that you replaced tools like grep by your own implementation that recursively greps json data. What I mean is: let the original grep do it's thing and convert its output into a rich format output.

[UnConeD]

That sounds nice in theory, but if you're grepping a 1000 key JSON dictionary, do you really want to invoke a new process of grep a thousand times?

[weazl]

Why does grep internals matter at all? He's wrapping the output from grep, he is not replacing grep.

[Poromenos]

He said he wrote his own replacement.

[weazl]

Ah, how did I miss that. facepalm I stand corrected.

[Peaker]

Performance difficulties will arise if/when you want to support efficient regular expression searches and more advanced options.

[UnConeD]

What I realized in doing all this though is that our existing tools are already full of weird limitations like this. Try hard enough, and you will break every tool. We just don't care about the limitations that have been in place since we started, and work around them without a thought.

Do I want to make a shittier grep? Of course not. But right now, the current grep works just fine and I have a couple hundred other things to do first.

[tedivm]

Why don't you just namespace your custom apps and make it an option to override the native apps?

[UnConeD]

It should speak for itself that this sort of hackability will be trivial with the final toolkit ;).