
Show HN: Termipal – native micro-GUIs for shell scripts and command line apps - pavlov
https://termipal.sh
======
arximboldi
Looks a lot like the good ol' zenity:
[https://help.gnome.org/users/zenity/3.24/](https://help.gnome.org/users/zenity/3.24/)

~~~
egwynn
Which (IIRC) is like xdialog for gtk, which is like dialog for X11.

~~~
vthriller
There's also alternative to the `dialog` called `whiptail`.

~~~
shakna
Which is a proof of concept around newt [0], which is a C library you can use.

[0] [https://pagure.io/newt](https://pagure.io/newt)

------
tbodt
This is written by the same guy who wrote Electrino, which was supposed to be
a lightweight Electron replacement but never really caught on. So I'm not
surprised that this has a lot of code from Electrino in the core. This is a
great way to use the idea of Electrino for something that doesn't require many
years of work to become useful.

~~~
pavlov
Yes, that's me!

I feel a bit sad that I was unable to put in the work to bring Electrino
forward. There was a lot of interest, but I just couldn't find any more extra
time between existing paying work and family. As you say, Electrino is a
multi-year commitment because of the sheer number of APIs needed to support
the apps that are already out there.

I made Termipal because I found myself writing a bunch of crappy shell scripts
for various tasks, and having real UI with dropdowns and buttons made the
scripts much more usable.

~~~
kaoD
Hey! I just discovered Electrino from this thread and no wonder it grabbed a
lot of interest! I didn't even consider the idea and now I _want_ it.

I used to be a native dev (from when native meant desktop OS :P) and switched
to web apps just for UI development convenience, then node-webkit came. I
still use both nw.js and Electron (though I admit I kinda like nw.js more, IPC
is a PITA) but, even though I _love_ the development experience, I absolutely
hate the end user experience.

Can you elaborate on why is Electrino a multi-year commitment? I guess I can
see why if you meant Electrino as a drop-in replacement of Electron. Did you
consider scaling down the features a bit? Just bundle a native webview +
Node.js, add some kind of IPC and let userland do the rest.

Would this be achievable or am I missing something that makes it way harder
than I imagine?

EDIT: After scanning my own comment I see why... the idea is to _not_ bundle
Node.js and instead use the native JS engine which does not include Node APIs
nor leverages the NPM ecosystem.

------
rsync
Things like this (terminal add-ons like graphical layers and image viewers and
so on) are only going to end badly.

What's so special about the terminal is the immunity the user has to hostile
character strings.

When I view a webpage in lynx or read an email in (al)pine, there is no string
that could be injected to harm me - I am immune to viruses and javascript and
weird CSS and so on. I can open up an infected document or view a phishing
email.

In short, the well-behaved terminal _does nothing_ but display text in your
character set. It does not interpret and it does not execute _and it certainly
doesn 't call GUI APIs to draw buttons and display videos_.

This is a door best left unopened ...

~~~
rnhmjoj
> there is no string that could be injected to harm me

Unfortunately that's not true at all. There are many instances of arbitrary
code execution gained though a terminal emulator, with escape sequences[1]
being the most common. For example exploiting common "git prompts"[2] scripts
or running `strings` on a binary[3].

[1]:
[https://unix.stackexchange.com/a/15210](https://unix.stackexchange.com/a/15210)

[2]:
[https://github.com/njhartwell/pw3nage](https://github.com/njhartwell/pw3nage)

[3]: [http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-
on-u...](http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-on-untrusted-
files.html)

~~~
rsync
Thank you for bringing up the 'strings' problem - something I had forgotten
about.

It's worth noting, however, that there is nothing inherently dangerous about a
strings-like utility. Rather, it is GNU strings which has unexpected
complexity:

"Perhaps simply by the virtue of being a part of that bundle, the strings
utility tries to leverage the common libbfd infrastructure to detect supported
executable formats and "optimize" the process by extracting text only from
specific sections of the file. Unfortunately, the underlying library can be
hardly described as safe: a quick pass with afl (and probably with any other
competent fuzzer) quickly reveals a range of troubling and likely exploitable
out-of-bounds crashes due to very limited range checking"

... which is the very issue I'm warning against, just at a different layer of
abstraction ...

------
skanga
Something like this but portable across Linux/Win/Mac would be pretty cool.

~~~
thomastjeffery
Instead of writing a terminal emulator specific gui, maybe someone could write
an ncurses based shell wrapper.

The whole problem is that shells are REPLs, and REPLs are not the best method
of interaction. This idea could probably be taken even farther.

------
duck
> For maximum convenience, Termipal automatically attaches to the bottom edge
> of your terminal window.

What does Termipal do if you have terminal full screen?

~~~
satysin
Would be kinda cool if, on a MacBook Pro, it moved the Termipal UI onto the
TouchBar :)

~~~
pavlov
I like that -- that's definitely what it should do, and maybe not even very
hard because there's so few UI elements.

------
_sdegutis
In a similar vein, I wrote choose[1] which I thought was very novel at the
time, since it is a command line utility that pops up a native GUI (for fuzzy
matching) and takes its input from stdin, lets the user choose an item by
interacting with the native GUI, and spits output onto stdout. I thought it
was the coolest idea since you can integrate it with any CLI that can launch
apps and read/write to standard input/output, including vim and emacs.

[1]: [https://github.com/sdegutis/choose](https://github.com/sdegutis/choose)

------
swsieber
Well, that's quite nifty. I never knew OS X had it's own javascript engine /
component.

~~~
robterrell
Yep, it's been there a while:

    
    
      rterrell$ /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Resources/jsc
      >>> for (var i=0; i<10; i++) { print("Hello World!", i); }
      Hello World! 0
      Hello World! 1
      Hello World! 2
      Hello World! 3
      Hello World! 4
      Hello World! 5
      Hello World! 6
      Hello World! 7
      Hello World! 8
      Hello World! 9
      undefined
      >>>
    

Edit to add: the submission reminds me of the old "Commando" for MPW. Very
cool.

~~~
lloeki
Well, while I _did_ know JSC was a standalone thing (a framework, rather) on
macOS, notably due to its presence in AppleScript Editor, I did _not_ know it
had a REPL readily available, and that the jsc interpreter works for shebangs
too!

~~~
robterrell
I found out about it when using Cappuccino -- on mac os x it would build much
faster using jsc instead of narwhal. For about a week after that I tried
writing shell scripts using the jsc shebang... but it ended up being a lot
more painful than I imagined.

------
willcodeforfoo
For the Mac there's also Pashua:
[https://www.bluem.net/en/projects/pashua/](https://www.bluem.net/en/projects/pashua/)
which lets you generate a GUI for shell scripts.

------
eat_veggies
Heads up: the text cuts off on ultrawide

[https://i.imgur.com/p64kvl0.png](https://i.imgur.com/p64kvl0.png)

------
DenisM
Needs more examples certainly. Still, nice work!

------
topher200
Looks interesting! The website could use some more screenshots showing off
what's possible.

~~~
deckar01
I didn't even notice that it was in use on the splash image. I thought the
terminal was just setting on top of another app window.

------
hultner
Looks nifty, however I’m mostly always running my terminals either in full- or
split screen. How would this work in these cases? Does it work from within a
tmux-session?

A neat feature would be a dialog (the tui cursors one) fallback, I.e. when
working over SSH.

------
gaius
What use cases does this have that Tcl/Tk doesn't?

~~~
pavlov
I feel like I don't really know Tk well enough to give a satisfactory answer.
Does it use native Cocoa widgets these days? I recall that wasn't the case
years ago, at least.

Anyway, Termipal's benefits are:

* Native Cocoa widgets

* No dependencies (uses system JavaScript framework)

* Attaches to host terminal window to minimize UI transitions.

It's designed for tiny non-intrusive GUIs invoked as part of a script. Tk
probably shines for more complex dialogs.

------
empath75
This looks super interesting, but is there api documentation some where? Is
there a way for it to output a shell command directly or can it only print?

~~~
pavlov
Sorry, I haven't written any API documentation yet. Basically there's a
handful of Node + Electron APIs implemented, and a new "microUI" module for
managing the UI. The example scripts show pretty much all there is to microUI
at this point.

For invoking shell commands, it would probably be best to just implement
Node's child_process module?

Adding more APIs is in general not difficult -- it's harder to decide what to
prioritize.

------
johnzim
I really like this idea! Maybe it's the Christmas season but I was feeling a
little wistful for the old days of fun little OS X utilities.

This is a beaut :)

------
solarkraft
The finished product is definitely not for me, but the ideas are neat.

------
twobyfour
Pretty neat. I don't suppose this works with iTerm2?

~~~
pavlov
AFAIK it works with iTerm.

It attaches to the focus window on the app that launched it, so it should be
terminal-agnostic.

------
neil1023
The site is down. Maybe due to too much traffic.

~~~
pavlov
Sorry about that. Where are you located? It works for me... Hmm :/

Here's the Github repo:
[https://github.com/pojala/termipal](https://github.com/pojala/termipal)

~~~
mmanfrin
Its down for my in San Francisco.

------
svmegatron
Nice!!

------
oxguy3
Ah, finally someone did this! I've had this same idea for forever but never
got around to implementing it.

------
sam0x17
TLDR: doesn't work on linux

~~~
magic_beans
It's not meant to.

~~~
sam0x17
Then it should say that in the title

