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.
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 :(
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.
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.
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.
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.
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.
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.
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.
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.
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)
And I'm sure they all didn't actually read the article before coming to the comments section, just like you. Adding their uninformed upvote to your uninformed comment.
To be clear, "If the author had pitched this..." is the uninformed part. He makes his intentions clear in the first paragraph.
What about people who can't read the article because of a paywall. They like to comment, too. Or the tangents that routinely happen having nothing to do with the article.
I believe the heading is part of the article. It is the first thing the reader will encounter and the author is trying to get us to read more. It requires that the author put some thought into it. Unless I am missing something, the statement about "raw text" reflects how the author actually believes readers might feel.
You're essentially asking me to ignore the author's statement about being "tired of displaying raw text" and try to interpret some ambiguous sentence at the end of paragraph 1. I am not tired of displaying raw text. He assumed wrong. There's no retraction or contradiction of the statement about "raw text" in the article. As far as I can tell, it was not "clickbait". The author actually believes reader are "tired of displaying raw text".
What you are not understanding is that it would have made no difference in this case. That statement about being tired of displaying raw text was intentionallly chosen by the author and it is not something I am going to ignore after I read the article. I am already familiar with the software. The article did not tell me anything I did not already know.
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)
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 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.
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.
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?
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.
