Modernize your Bash Scripts by adding GUI | Hacker News Reader

Modernize your Bash Scripts by adding GUI

medium.com

68 pointsdelvin066 comments

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 have never seen one of those.

I use firefox with NoScript and Privacy Badger, and I disallow cookies. Hopefully this helps.

Disabling JS does help against Medium nagging. It also disables any active content, which can be not only e.g. animations, but also images loaded from a CDN using a script. So disabling JS cuts both ways.

Frankly, I would really prefer to just pay for articles I liked (as opposed to a subscription), but this option is not available :(

> It also disables any active content, which can be not only e.g. animations, but also images loaded from a CDN using a script. So disabling JS cuts both ways.

I usually selectively enable JS. If I care enough about the content that's disabled then I'll enable it from some sources for some sites.

> Frankly, I would really prefer to just pay for articles I liked (as opposed to a subscription), but this option is not available :(

This would also be preferable.

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

I don't understand this recent trend of modernizing things just for the sake of modernity.

Old ideas are often the best ones, why shove everything down the drain every five years?

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.

I think the title is misleading.

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.

`tksh` (ksh93 plus Tk widgets) 25 years ago.

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.

[1] https://github.com/dudik/herbe

Try `notify-send TEXT` instead. E.g.

  alias n="notify-send Completed."

Thank you, but I don't use a notification server.

notify-send is for desktop(possibly gnome only?) notifications.

notify-send works by sending notifications to a notification daemon (a.k.a., a "notification server", as defined in the "Desktop Notifications Specification").

notify-send won't work for dudik since, as he said, he doesn't use a notification server.

Nothing is stopping you, even if you don't run any kind of GUI session: https://github.com/Sweets/tiramisu

I use something like:

    echo -e "command\n with a long output,\n and it's last line" |tee /dev/tty| tail -n 1| { read -d '\n' _output ; notify-send "$_output"; telegram-send "$_output"; }

This will send the last n lines of stdout to:

- gnome-notifications

- telegram on my phone from a bot account that uses a unique notification sound

Too heavy? The executable I just built is 19K. I like it for localhost.

Did you wind up picking something else?

Sorry for my poor choice of words. What I wanted to say was that I prefer using software that does exactly what I need and nothing else. For some people it might sound silly, but I enjoy the suckless philosophy.

I use notifications only for things that take a long time so I can disengage work on something else for a while.

"long build has completed"

is pretty much my primary notification.

The "dialog" command is a nice middle ground that will put a graphical dialog within the terminal, instead of having a dependency on X11.

Like:

  dialog --title "Message" --yesno "Continue?" 6 25
  echo $? # will be 0 for yes, 1 for no

I always thought shell scripts are intended to avoid using GUI altogether?

I write shell scripts all the time. I have probably written hundreds of shell scripts this year.

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

If you want similar interactivity as TUI, try dialog (https://invisible-island.net/dialog/)

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

That allows you to combine the disadvantages of CLI and UI.

Isn't a big benefit of bash that the dependencies are already satisfied? How will you package this binary?

Scripts are useful, even to the non-technical. Easily adding some GUI to a user-facing script is a good thing.

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.

That runs the risk of family techies being condemned to debugging bash scripts when they're inevitably less portable and we'll tested than one would hope.

Please, show some humanity: think of the techies.

"Tired of displaying raw text on Console?"

Nope.

I am a scripter. I will never get tired of raw text, but I sure get tired of GUIs, fast. If the author had pitched this as a way to make the scripter's scripts accessible to others who do not understand scripts, I would have a different response.

Last sentence of the first paragraph "But if it is used by a general audience it is obviously good to have some user friendly interactions."

Yeah but was is this then a shell script which randomly pops up some windows you need to click away?

When your script was a bash script chances are you targeted proficient users with it. These might get annoyed by popping up stuff. This means ultimately you are probably better off adding a GUI and a --headless flag so both user categories are happy.

As I see it the only thing that is a little useful are the notifications (e.g. if you have some sort of daemon running in background that needs to bring sth to the users attention)

I feel like notifications would be the only thing on that list I could see myself using. I know you can make the terminal make a noise, but I sometimes prefer visual alerts.

./dosomething && mail user -s job done

Edit: I read the article, this is covered a bit.

On Linux you can use `notify-send "title" "content"`. The only limitation it has is that you can't query the notification id to update or selectively dismiss it later.

Also, many terminals will have a visual alert instead/together with a sound: konsole does this, for instance.

Many Linux terminals can monitor for activity/silence/bell/process exit. Using these facilities, notifications can be done without modifying the script.

I use a shell script to flash the terminal background using OSC 11 — green or red depending on the last exit status.

I'm also a scripter and love the CLI but notify-send is really nice to be alerted when locally-executed long-running scripts end (for example, a terraform plan)

gnome-terminal already seems to do this for me...

How? I cannot find any "notify on activity" in my gnome-terminal version (I used to use it with Terminator). But anyway it's not the same, or at least it wasn't in Terminator, since you can just notify for activity in a terminal regardless of the program generating activity in it. And I don't want to turn it off and on every time I stop/start using terraform in that session

Can’t read the article, guess I’m out of free reads this month/week. I wish there was some kind of rule against posting medium.com links on HN. That would incentivise people to use some other tools, for example dev.to or personal blogs.

Just go incognito in the meantime..

Incognito is also blocking me.

Just block cookies on medium.com and enjoy the paywall-free experience. On Chrome, click the lock icon in the address bar, hit "Cookies", select "medium.com" and block. Then refresh.

Are you sure that would work for every Chrome user? Chrome tests many different variations on different users and they are constantly messing with Chrome and ChromeOS via automatic updates. On a Chromebook I have in developer mode, using the Crouton chroot script, for many months, through several "updates", cookies could no longer be blocked from the address bar, only through Settings and only on a per site basis; it became impossible to globally disable cookies, the setting would automatically revert back to enabled! After the latest update, I can now finally gloablly disable cookies again and disable from the address bar (though this requires more clicks than it once did). Sometimes they release "updates" and the stuff is still broken. By the next update they have fixed it. In the interim we have to settle for unfinished software. In my opinion, Chrome is not one program, it is constantly changing unfinished work and not every user gets the same "features".

I block cookies using a local proxy. I cannot rely on Chrome "features" for anything privacy-related. They just keep changing.

HN's only paywall-related rule is against hard paywalls. As long as the paywall is porous, it's OK here, as you can always use archive sites to bypass the paywall.

In this case: https://archive.md/Fvxy4

I doubt HN wants to get into the business of running official campaigns against publishing platforms.

Try this link: https://outline.com/AFBUbY

This is such a backwards way of thinking. Like modernizing math by using little colored blocks with symbols written on them, because your tired of using boring old white and black pencil and paper... It's what you do to entertain children into being interested in something, not how adults get stuff done.

There is a value in making things enjoyable/a bit fun to use. I would prefer my real analysis textbook to have color block. I don't understand the concept that adults need to use product that is boring.

Agreed. Colourful math symbols sounds like a great idea.

The vast majority of adults, like, all of them for pretty much any practical purpose, gets stuff done on computers outside of a shell using GUI programs exclusively. Outside of dev, ops, research etc. bubbles, bash might as well not exist at all. GUI apps are also a much more recent and, yes, modern evolution of human-computer interfaces, so modernizing doesn't sound wrong to me – we keep the terminal as a UI paradigm because it works very well for a certain class of interfacing needs, but it is low-tech and ancient and very limited when dealing with anything that isn't exclusively unicode text. Targeted UI modernization of select terminal programs by lifting them to the UI paradigm the industry has moved to decades ago doesn't feel backwards to me at all if it makes bits of shell technology available to everyone else without the steep and brutal learning curve of getting used to working in a shell.

Besides, isn't programming with syntax highlighting pretty much ubiquitous? Since, at this point in history, all programming I'm aware of boils down to a relatively practical application of maths, I'd argue colored blocks have already pretty much supplanted pencil and paper as the interface adults use to get stuff done.

> This is such a backwards way of thinking. Like modernizing math by using little colored blocks with symbols written on them, because your tired of using boring old white and black pencil and paper...

I remember having to use TI-83 for school. Back then, some people taught the same about the calculator.

Also, sounds like you'd oppose syntax highlighting. I like making e.g. my PS1 colorful. The problem is when other's force their color scheme upon you, like mIRC colors, or website themes (!!).

> "Like modernizing math by using little colored blocks with symbols written on them, because your tired of using boring old white and black pencil and paper..."

Most developers like color-coded syntax highlighting in their IDEs and editors though?

Reply on news.ycombinator.com