As an aside, I noticed this at the top of of the article:
You have 1 free story left this month. Sign up and get an extra one for free.
I really dislike Medium. I don't want to have a relationship with the blog platform that people use in order to read the article; I want to read the article.
I once developed an entire CMS in Bash and Zenity. We could not use dynamic languages on the web server and only had an SSH access to a very restricted machine. The users where not technical and resented command line interface. So I learned Zenity and played with it up to te point where the website (it was essentially a calendar + attached documents interface) was entirely editable using the Zenity GUI. A few years later I heard that my script was still in use at the place where I made it. It was good fun. I just like doing stuff with Bash :).
What if $DISPLAY is unset? Or if zenity isn't found in $PATH?
If you want to see "user unfriendliness", just present your user with the cryptic error message they'll receive in either of those instances (ask 'em how "modern" they think your script is then)!
I'm obviously not the "target market" for this article anyways but a better example might have included, at the minimum, some basic error checking or perhaps even a graceful fallback to dialog or whiptail or similar.
As a terminal user, nearly all the time, I'm mostly inside the terminal so they don't make as much sense to me.
However I'm not _always_ a terminal user. Sometimes I'm a browser user and sometimes I have to use spreadsheets too.
In these contexts I use other programs which have GUI's, sometimes quite minimal, like a screenshot app for example.
I can certainly imagine getting a spreadsheet into a defined set of columns and then executing another app which asks a set of questions and then does something with that data, maybe even only draws a graph (as I despize drawing graphs in spreadsheets).
In this context, I feel that I may well write BASH, but opening a terminal would be as jarring as leaving it under normal circumstances...
So I feel these kind of tools are useful.
Shameless plug: Funnily I'm working on the opposite. Integrating STDIN/STDOUT into the GUI via a WebView, because I want that command line control but I there are occasions where there are benefits in using a GUI (graphs etc) - https://github.com/forbesmyester/wv-linewise
I find that Zenity really shines if the script is intended to be launched outside of a terminal window.
For example, I have a script bound to Super+Y that opens a youtube video inside a local video player. Before it starts the video it shows a zenity popup with the URL so I can confirm that it is correct.
While the tool suggested here isn't the best interest of the HN community, I think it has some good use cases. Just think of making an otherwise terminal-only tool more usable for non tech-savvy folks. There are many terminal only tools out there that we have no problem using, but appear scary and unusable to people who haven't used a shell before. This might work as a "gateway drug" to GUI people into making text based interfaces more familiar.
This reminds me, a company I worked at used a bash script + zenity to automate the programming of devices using open-jtag. It worked pretty well and let the workers (skilled mostly in soldering and electronics assembly) do the programming and flashing of a fairly involved embedded device.
We eventually ended up replacing it with a local web-app but the zenity version was fast to write and good enough that the quick and dirty prototype survived for several years.
My pitch for zenity would be - "Need a prototype gui for users that struggle in the console? Consider zenity."
Accessibility. You and I would probably use the CLI versions of these bash scripts. But my parents or friends would probably not use one unless it came with a GUI. Getting them interested in running shell scripts rather than purchasing expensive apps can only be a good thing.
There was xdialog 20 years ago. And libnotify has like 15 years too.
I understand "modern bash" as in any other scripting or programming language: It's about what caveats of the language quirks, the optimizations and the failure scenarios, that you solve with your code conventions, which people didn't use to use, some years ago.
Change things for the sake of having something "newer" available for me, is something I try to avoid at all levels of my life.
If someone is already using the terminal to start the script, they've already overcome the major usability hurdle: Finding the terminal and typing a command. For me, as a user, it would be annoying to have to move back and forth between using the mouse and then using the keyboard. Modernize in this case would mean 'make less user friendly'. Sigh.
If you just need to display some text or at most you need a "yes/no" answer that integrates well with your bash script, you could try herbe[1]. I was somewhat inspired by zenity, but it felt too heavy for my minimal use case.
A lot of hate from people too stubborn to recognize the value in various forms of input / output, but I think this is a great idea. Will be trying it for one of my next projects.
I use gitk pretty often and really like the fact that it acts like a modal, showing a richer UI visualization based on a shell command I run, and when I close it, I'm back to the command line where I was. I've been hoping to write my own CLI tools like that, ideally using React for the UI, but it seems like it's a big pain to set up right now. Is anyone aware of a nice way to do that? Maybe Zenity is flexible enough for arbitrary UIs, not just dialog boxes?
Ok, so I guess since here is HN, everyone is going to say... "Why would you 'modernize' your bash scripts? Isn't the point of scripts to avoid the GUI altogether? GUIs are inefficient, blah blah blah...". And there is a bit of truth in that, but that's not the whole story. (And since I guess I'll be downvoted heavily, I would suggest you to read this block of text before you do.)
This blog post is basically about using GUI inputs to get user input. Which means it's an interactive script, and the direct non-GUI equivalent is a TUI. Which means the script is not something that you will be automating for, but more just of a convenient interactive tool.
And by definition TUIs are an inferior version of a GUI, for example it usually won't handle terminal size changes, localization, etc... So it makes plenty of sense to make that a GUI for the sake of having a better input. (And I won't call that 'modernization', but it's a better option than presenting a calendar UI from your bash script or having me input a unix timestamp or something else.)
So then you might say that hey the command line equivalent of that GUI input is flags, not interactive input, but well you can make a CLI that gets it's parameters from flags and gracefully fallback to interactive input if you don't have sufficient information.
(And no, TUIs are not more efficient than GUIs. CLIs might be, because of shell piping and it's automation techniques. But TUIs are inferior, full stop.)
Agreed. While most people on this website would probably not use it, this can only expand the use of bash scripts to the general public, and encourage the next generation to get interested in them.
[+] [-] shawndellysse|5 years ago|reply
[+] [-] Shared404|5 years ago|reply
I use firefox with NoScript and Privacy Badger, and I disallow cookies. Hopefully this helps.
[+] [-] p4bl0|5 years ago|reply
[+] [-] jlgaddis|5 years ago|reply
If you want to see "user unfriendliness", just present your user with the cryptic error message they'll receive in either of those instances (ask 'em how "modern" they think your script is then)!
I'm obviously not the "target market" for this article anyways but a better example might have included, at the minimum, some basic error checking or perhaps even a graceful fallback to dialog or whiptail or similar.
[+] [-] mattatkeyboard|5 years ago|reply
However I'm not _always_ a terminal user. Sometimes I'm a browser user and sometimes I have to use spreadsheets too.
In these contexts I use other programs which have GUI's, sometimes quite minimal, like a screenshot app for example.
I can certainly imagine getting a spreadsheet into a defined set of columns and then executing another app which asks a set of questions and then does something with that data, maybe even only draws a graph (as I despize drawing graphs in spreadsheets).
In this context, I feel that I may well write BASH, but opening a terminal would be as jarring as leaving it under normal circumstances...
So I feel these kind of tools are useful.
Shameless plug: Funnily I'm working on the opposite. Integrating STDIN/STDOUT into the GUI via a WebView, because I want that command line control but I there are occasions where there are benefits in using a GUI (graphs etc) - https://github.com/forbesmyester/wv-linewise
[+] [-] ufo|5 years ago|reply
For example, I have a script bound to Super+Y that opens a youtube video inside a local video player. Before it starts the video it shows a zenity popup with the URL so I can confirm that it is correct.
[+] [-] can16358p|5 years ago|reply
[+] [-] drwoland|5 years ago|reply
My pitch for zenity would be - "Need a prototype gui for users that struggle in the console? Consider zenity."
[+] [-] blackbear_|5 years ago|reply
Old ideas are often the best ones, why shove everything down the drain every five years?
[+] [-] AA-BA-94-2A-56|5 years ago|reply
[+] [-] txutxu|5 years ago|reply
There was xdialog 20 years ago. And libnotify has like 15 years too.
I understand "modern bash" as in any other scripting or programming language: It's about what caveats of the language quirks, the optimizations and the failure scenarios, that you solve with your code conventions, which people didn't use to use, some years ago.
Change things for the sake of having something "newer" available for me, is something I try to avoid at all levels of my life.
[+] [-] lcuff|5 years ago|reply
[+] [-] dudik|5 years ago|reply
[1] https://github.com/dudik/herbe
[+] [-] mcstafford|5 years ago|reply
Did you wind up picking something else?
[+] [-] drran|5 years ago|reply
[+] [-] tyingq|5 years ago|reply
Like:
[+] [-] dschuetz|5 years ago|reply
[+] [-] m463|5 years ago|reply
If you think it was to avoid using a gui, I would have to say that's not really it.
It's more to do something (automate stuff) rather than not do something.
I learned about zenity but chose yad instead - it has the same interface + a few more bells and whistles.
What it's good for is launching something you'll do on your primary display, that has a lot of options that you might change individually.
probably also good for a phone. I learned about yad reading this article:
https://wp.puri.sm/posts/easy-librem-5-app-development-flash...
[+] [-] nxpnsv|5 years ago|reply
[+] [-] hoytschermerhrn|5 years ago|reply
[+] [-] alangpierce|5 years ago|reply
[+] [-] pcr910303|5 years ago|reply
This blog post is basically about using GUI inputs to get user input. Which means it's an interactive script, and the direct non-GUI equivalent is a TUI. Which means the script is not something that you will be automating for, but more just of a convenient interactive tool.
And by definition TUIs are an inferior version of a GUI, for example it usually won't handle terminal size changes, localization, etc... So it makes plenty of sense to make that a GUI for the sake of having a better input. (And I won't call that 'modernization', but it's a better option than presenting a calendar UI from your bash script or having me input a unix timestamp or something else.)
So then you might say that hey the command line equivalent of that GUI input is flags, not interactive input, but well you can make a CLI that gets it's parameters from flags and gracefully fallback to interactive input if you don't have sufficient information.
(And no, TUIs are not more efficient than GUIs. CLIs might be, because of shell piping and it's automation techniques. But TUIs are inferior, full stop.)
[+] [-] _pmf_|5 years ago|reply
[+] [-] beardedwizard|5 years ago|reply
[+] [-] bobsmooth|5 years ago|reply
[+] [-] AA-BA-94-2A-56|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]