Looks a lot like the good ol' zenity: https://help.gnome.org/users/zenity/3.24/

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

My favorite of these is Commando for the Macintosh Programmer's Workshop.

http://web.uvic.ca/~ncs/406/HTML/Targeting_MacOS/images/IDE1...

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

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

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

See also:

CDE's DtKsh, which has had support for this for decades. http://www.brendangregg.com/dtkshdemos.html

http://www.osnews.com/story/18969/pt_VII_CDE/page1/

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.

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.

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.

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 ...

> 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

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

[3]: http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-on-u...

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 ...

Pretending that terminal or command line applications are immune to a very common mode of attack, even to them, is itself dangerous thinking.

This could potentially add a new attack surface, sure, but don't think that without it, exploits aren't possible.

There is two problems with that argument:

- Terminals are the worth offenders when it comes to special characters and encoding issues.

- GUIs are not inherently injectable.

That said, I still things it's a weird idea. There are much better ways to gain efficiencies (e.g. shells)

I'm not sure what you mean. Termipal is just an external program, it's not going to be automatically launched by the Terminal. It's like any other interpreter you might run from your scripts -- it's your responsibility to ensure the input is safe.

I’m not sure I follow you. Unless I’ve read it totally wrong, this thing is basically just xdialog for macOS with some fancy dress-up. I don’t see how it exposes a novel attack vector.

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

I have a handful of escape codes that beg to differ...

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

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.

I just use Scalafx with a Scala REPL. Unfortunately I don't know offhand of anything else outside of the JVM ecosystem that's as simple and portable.

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

What does Termipal do if you have terminal full screen?

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

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

It actually didn't occur to me to try that until now. Looks like it doesn't work because it's a different process and its window can't be composited on top of the fullscreen app. I don't know if there's a workaround -- maybe there's a way to move it into the desktop space occupied by the fullscreen Terminal?

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

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

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.

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!

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.

Cool links regarding JS in OSX

* [JXA Cookbook](https://github.com/JXA-Cookbook/JXA-Cookbook)

* [JavaScript OS X App Examples](https://github.com/tylergaw/js-osx-app-examples)

It's also available for system automation [1], which is a highly underrated (IMHO) part of the Mac system.

For my application (URL in bio), I wrote a shell script that (mostly) automatically generates the screenshots for the Mac App Store. It uses osascript(1) with some JS to set the system colors/wallpaper/language to a particular style, position the app window where I want it, take a screenshot, block out my menubar extras, crop it to the requested size, etc.

OSA scripting is actually pretty powerful, but sadly the documentation is awful. Try:

  osascript -l JavaScript -e 'Application("System Events").appearancePreferences.appearance = "graphite"'

(or "blue")

[1]: https://en.wikipedia.org/wiki/AppleScript#JavaScript_for_Aut...

It's called JavaScriptCore and it's part of iOS as well.

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

Heads up: the text cuts off on ultrawide

https://i.imgur.com/p64kvl0.png

Needs more examples certainly. Still, nice work!

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

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.

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.

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

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.

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?

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.

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 :)

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

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

AFAIK it works with iTerm.

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

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

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

Here's the Github repo: https://github.com/pojala/termipal

Its down for my in San Francisco.

Nice!!

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

It's not meant to.

Then it should say that in the title