Explore some of the more useful but perhaps more esoteric capabilities of the Bash shell with the blog post Ten More Things I Wish I'd Known About bash. It is a followup to the highly visible post by the same author on Ten Things I Wish I'd Known About bash. Modern shells like Bash, Ksh, and Zsh have over four decades of developent and refinement, making them powerful, flexlble, and fast user interfaces for efficient work — not just excellent scripting languages for automation.
(Score: 1, Interesting) by Anonymous Coward on Tuesday January 23 2018, @01:46PM (5 children)
I have yet to see any significant software that is the product of unix processes glued together by shell code; it's only been things like configuration scripts or for interactive, "exploratory" programming.
If you wanted to use a scripting language that called out to unix processes that also did real work on its own, you'd have to step up to perl or python.
(Score: 3, Informative) by turgid on Tuesday January 23 2018, @03:24PM
Someone needs to read the Unix Koans of Master Foo.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Funny) by Nerdfest on Tuesday January 23 2018, @04:09PM
15 years ago, the internet would like a word with you. Hell even now, but to a lesser degree.
(Score: 2) by fyngyrz on Tuesday January 23 2018, @10:11PM
All I need to know about whatever command shell is running:
And bingo, now I have one set of scripting knowledge that works with Windows, OSX, and linux. And it's hella powerful.
Ideally, I just set a Python script to be executable and run it directly. Or, if a shell command is the only option because... reasons... then what it does is launch a Python script.
It makes no sense to me to use up brainspace with shell esoterica these days.
(Score: 3, Informative) by urza9814 on Tuesday January 23 2018, @10:58PM
I work for a Fortune 10 company. Our core application has a few hundred shell scripts running every night for batch processing, particularly for data coming in from external sources. Various third party companies SFTP a data file, we validate and do some processing of it with a shell script, then we trigger sql or some other process to load into the database if needed. We do the same thing for data output, and that includes output to numerous state and federal regulatory agencies, so it seems to be a pretty typical way of doing these things. In total we've got around half a million lines of bash/ksh running in production...which I'm sure is nothing compared to our application level Java code, but it's still a hell of a lot more than just "configuration scripts or exploratory programming".
(Score: 2) by http on Thursday January 25 2018, @07:23AM
I have worked at a place where customer managment was (i) written in bash, and (ii) run as CGI. Working there taught me almost as much about bash as lhunath's guide. Maybe not the fastest software, but being a small shop, we never had more than three accounts being created or modified at the same time.
Billing, however, was done in perl. Speed matters in some situations.
I browse at -1 when I have mod points. It's unsettling.