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.
I had no idea that a shell script could do parallel processing. I’m astonished.
The script is probably using GNU parallel.
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?
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.