One of the most universal experiences of any Linux or Unix user is working through a guide or handbook and coming across an almost unbelievably complex line of code meant to be executed with a shell. At the time of encountering a snippet like this it’s difficult to imagine any human ever having written it in the first place, but with some dedication it is possible to tease out what these small bits of code do when they’re typed into the terminal and run (unless it’s something like :(){ :|:& };: but that’s another story entirely). [noperator] recently built a tool which helps users in this predicament understand these shell scripts by expanding them into a more human-intelligible form.
The tool is named sol and does much more than expanding shell one-liners into a readable format. It also provides an interactive shell environment where the user can explore the exploded code in detail, modify it in any way they see fit, and collapse it back down to a single line so it can easily be sent to other users. It can be used with most of the major text editors as well as piped directly to standard input, and has a number of other options as well such as custom configurations and the ability to see non-standard bits of code that might not be compatible from one shell environment to another, as well as helping to translate those bits of code.
[noperator] has made the code available in the linked GitHub page for anyone curious about its use, and has a to-do list for future versions of the tool as well including adding support beyond bash. We’d definitely recommend a tool like this especially if you’re still relatively new to bash scripting (or shell scripting in general) and, as always, we’d just to remind everyone not to blindly copy and paste commands into their terminal windows. If you’re the type of person to go out on a limb and run crazy commands to see what they actually do, though, make sure you’re at least logged into the right computer first.
None of those terms define it as well. And where were you about terminology when hundreds of drones were being sent south of the border hitting everything randomly?
I think the author even calls it de-minifying as does hackernews … and I agree. The only difference with minified js etc, is that we minify it in our brain by writing it as a compact oneliner.
To me, this is really the same thing as shfmt, so not sure why we need a nother tool that does the same. I do know that in the past (for the right reasons) the maintainer of shfmt was very reluctant to adding flexibility. ‘Oh, you write using this style, hmm no’.
One thing worth mentioning, is that one feature mossing here (super conplex) is to use lobg-opts for non busybox commands! Reading args in 6 months from now will be painful.
I had no idea that a shell script could do parallel processing. I’m astonished.
The script is probably using GNU parallel.
The ampersand also tells the system yo run the previous code in the background, allowing a following command to run in foreground
I’d suggest using the somewhat established term “pretty-print”.
“given what happened on Monday and Tuesday, perhaps “blowing up” is not the right verb to use.”
How about we all put on our big boy/girl pants and not assign unintended meaning to everything under the sun… it’s called being an adult. Try it, it’s kinda fun. I can stay up past my bedtime, eat dessert before the meal, etc. Winter isn’t here yet, so I’d just as soon not have to deal with snowflakes early.
No. Just no. It is the same as what happened to master/slave (and master branch in git), and other stuff. Stop trying to cut away pieces of the language
Wait, y’all are leaving dirty oneliners in your scripts?
lynx -dump table.html \ | grep -Ev "(yadda|dabba|doo)" \ | sed -f lynx_table_to_csv.sed \ | sed '/^Symbol/! s/^/'${symbol}',/;s/ -$//' \ | awk -F, '{ if ($9 ~ "") { print "\"" $1 "\",\"" $2 "\",\"" $3 "\",\"" $4 "\",\"" $5 "\",\"" $7 "\",\"0\"" } else { print "\"" $1 "\",\"" $2 "\",\"" $3 "\",\"" $4 "\",\"" $5 "\",\"" $7 "\",\"" $8 "\"" } }' \ > ${datafile}Bash is so weird!
I’m surprised that something like C-Shell or similar hasn’t caught on. But then.. if I ever were to get serious about developing something as a shell script I would probably go with Bash just because I would know that my target audience all have Bash and are familiar with it already.
I suppose that is exactly why Bash has lived this long isn’t it?
Depending on which flavor *nix we are talking about, Bourne and Bash are usually part of the base system and is updated as part of the other system updates. Csh, Ksh, and the rest one has to go out of their way to obtain, install, and maintain. If you learn Bash, then you can pretty much sit down at the console of any *nix system and start working without having to do any pre-install.
It’s one thing to install a preferred shell on a personal system, but in a corporate production environment it is advantageous to keep a system as vanilla as possible. Sure, if an application requires a different shell install it, but otherwise keep the system as clean as possible and learn to work within it.
Oh, I don’t disagree with that in theory. But languages have done a lot of converging or at least settling on a similar set of syntax that most of us intuitively recognize vs what started with Bash so long ago.
Think of an if statement or a for loop in C, C++, Javascript, PHP, C# and more… not exactly the same but it’s not like a person who is fluent in one wouldn’t immediately recognize all the others either.
Now picture that same thing in Bash. (You can do that without me… I’d have to Google it)
Even BASIC with it’s ‘End If’ and ‘Next’ would be less weird than Bash to most who aren’t already eligible for retirement.
A lot of things I think to change for the negative just for the sake of change. But maybe considering changing the default shell once every 50 years or so wouldn’t be too much? It’s just so damn alien now.
Meanwhile I bet a lot of people are probably relying on something that isn’t part of the base system (probably Python) for their scripting because frankly, it just isn’t worth the effort to figure it out in Bash when doing it that way the learning curve at least gets you closer to all other forms of coding too as opposed to being a one-off.
Ksh, zsh and busybox are all easily installable either through the os package manager. I haven’t checked but there may even be flatpacks, snaps, and nix bundles for those who use any of them. If all else fails, there’s docker images to give your exact environment directly to whoever wants it to easily run.
Why csh hasn’t caught on? There’s a FAQ for that. Several in fact, going back 30 years. Search for the following:
“Csh Programming Considered Harmful” by Tom Christiansen
“Top Ten Reasons not to use the C shell and C shell problems” by Bruce Barnett
They are idiots.
I prefer C-shell and tcsh, as it’s wired into my brain, and I’m too old to change. (Same with vi).
What gets my goat is someone on stack exchange asking a perfectly simple question about how to do this or that in C-shell, and the first 3 answers are “Don’t use C-shell”, “C-shell is bad, here’s how to do it in bash”, and “C-shell caused WWIII.”
POSIX.
Bash is POSIX compliant, while csh is not.
Bash follows POSIX shell standards and integrates seamlessly with POSIX utilities, csh does not.
Neither sh, bash, or csh are something that you would generally “develop something” particularly significant in. They are more utility scripting languages although you can get quite complex if you choose to.
Note, of course, that bash does extend beyond POSIX … A sh script should always run under bash or any other POSIX compliant shell, but, no guarantee of an sh script running under bash (which is why it’s okay to link /bin/sh to /bin/bash, but not vice versa). Use POSIX sh standards if you don’t need bash… Use csh if you want everyone to hate you. ;)
POSIX starts with POS. just saying….
Does this exist for regular expressions, about which there is really nothing most humans would call ‘regular’ rather more ‘diabolical’.
e.g., this regex to find incorrectly closed quotation marks near em-dashes: —[’”][^<\s]
I mean it’s ridiculous in this day and age.
I think I’ve used this site in the past for building and understanding/translating regular expressions: https://regex101.com/
There’s other similar sites as well.
There are things like https://regexper.com/ (often inside other tools), which can help you to read compact regexes.
Perl (and possibly other things using “Perl-compatible regular expressions”) had a syntax to allow for whitespace, indentation and comments inside regexps, so that you could write them in a more readable format. Possibly there is some command-line tool that can expand regexps within shell scripts using that syntax.
I think, though, if you don’t like regexps it’s probably the essential idea you don’t like, and you probably wouldn’t like it any better if it took up more space.
(I enjoy regexps, but I will readily concede they’re a net negative for civilisation as a whole)
Whenever I’ve written a regex, short or long, I’ve made a point of manually breaking it down in roughly the style of the tool described in this article, and commented each line, so that I and the people after me could gain a clue on what was going on during subsequent maintenance. To do otherwise is just being passive aggressive, given that next to nobody is facile with regex. Speaking of passive aggressive, the same goes for using IPA as a pronunciation guide.
You could say the same thing about Prolog, but it serves a purpose.
I use shellgpt to help me explain or pretty print stuff or create a script; it’s just a onestop shop instead of using all kinds of different tools of which i forget what their name was. But i do appreciate the effort of writing these
I love the colorscheme used in the cover image! What is it?