https://xkcd.com/927 Is there room for a lightweight scriptable language that takes the place of, say, bash/zsh/korn/fish shell scripts? Please don't say perl/python or sed/awk.
Your use case is unclear, but you may want to look at Tcl?
The Bash Hackers Wiki
21–30 of 89 posts
Re: The Bash Hackers Wiki
#22Earlier quoted context omitted.
Bash was the first scripting language I became “good” in too! The skill seems to be regularly devalued in this community, and there is no surprise why (what is collaboration and maintenance for $500). However, it’s hard to ignore why bash masters are born in the first place if better tools exist - shouldn’t the best tool win in the long run? My take is lone wolf hackers working in corporate /_/nix constrained environ…
I used to know someone who worked for a hugeco with really ancient proprietary unix systems. He wrote huge, complicated things in awk. I think the experience did things to him, but he was the guy to go to for awk questions.
Google's perforce client wrapper was thousands of lines of bash for a long time. It was both amazing and terrible. It stood up to thousands of engineers and was easy to customize, if youbwerw good in bash. Fun times...
Re: The Bash Hackers Wiki
#23I recently came across this static site generator written in Bash:
https://github.com/hmngwy/jenny
It's kind of cool, but what makes it really nice is that it's going to work on any computer I use, there are no concerns about dependencies, and no concerns about future compatibility. (Obviously not 100%, but I'm not worried in the least.)
Re: The Bash Hackers Wiki
#24I like bash, but I sort of have a rule... If I am thinking of using advanced features of bash, or I'm over-using grep/sed/awk within the script.... switch to python (formerly perl) Mostly it's a win with respect to quoting, path manipulation and proper data structures.
My bar for switching to my scripting language of choice is much lower; as soon as I need any sort of control flow, I switch to Ruby.
Re: The Bash Hackers Wiki
#25I like bash, but I sort of have a rule... If I am thinking of using advanced features of bash, or I'm over-using grep/sed/awk within the script.... switch to python (formerly perl) Mostly it's a win with respect to quoting, path manipulation and proper data structures.
Python's major glaring problem as a systems language is dealing with processes. It is just verbose, ticky and annoying. I have my other issues with it as a systems language that are more idiosyncratic, but for replacing bash, process management is just way too much hassle.
I agree. I basically fall back to a subroutine with try and subprocess.check_output() as shorthand.
However I like this lots:
subprocess.call(['cmd','with','precise','args',file1])Re: The Bash Hackers Wiki
#26Bash was the first scripting language I ever got "good" with. (I put "good" in quotes because while I could get basically anything done, I promise that it was not good looking). However, I feel like it left me a bit brain damaged, I still think in terms of quotation quirks and "sub-shells" even in proper languages such as python or rust. It also left me a bit weird when thinking about concurrency, because I never con…
I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html
The nice thing about Bash which can obviously not be said about Python is that Bash scripts will keep working (assuming whatever they call is also there of course) since Bash goes out of its way to preserve backwards compatibility. Considering its legacy, Bash can run scripts more than a decade before Python even existed.
The only other scripting language i know of that has similar backwards compatibility is Tcl. Perhaps Perl too (ignoring Perl 6 that was renamed to something else again due to it being practically a different language).
Re: The Bash Hackers Wiki
#27Earlier quoted context omitted.
I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html
The nice thing about Bash which can obviously not be said about Python is that Bash scripts will keep working (assuming whatever they call is also there of course) since Bash goes out of its way to preserve backwards compatibility. Considering its legacy, Bash can run scripts more than a decade before Python even existed. The only other scripting language i know of that has similar backwards compatibility is Tcl. Per…
I guess it's the trade off between backwards compatibility and readability/correctness/maintainability. Both languages will have technical debt overtime. In my opinion, I would much rather have to rarely update python scripts in exchange to for peace of mind that I can fix/update the script as need be. In my experience, *sh scripts can be fragile and hard to ensure correctness.
Re: The Bash Hackers Wiki
#28Bash was the first scripting language I ever got "good" with. (I put "good" in quotes because while I could get basically anything done, I promise that it was not good looking). However, I feel like it left me a bit brain damaged, I still think in terms of quotation quirks and "sub-shells" even in proper languages such as python or rust. It also left me a bit weird when thinking about concurrency, because I never con…
I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html
Having watched people hack together utterly bizarre bash scripts with awk and grep to handle json responses I'd very much agree here.
And before someone raises jq, what % of servers already have python installed vs jq?
Re: The Bash Hackers Wiki
#29Earlier quoted context omitted.
I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html
Having watched people hack together utterly bizarre bash scripts with awk and grep to handle json responses I'd very much agree here. And before someone raises jq, what % of servers already have python installed vs jq?
> And before someone raises jq, what % of servers already have python installed vs jq?
How many of those servers have something like requests installed out of the box vs needing to fetch it via a package manager or PyPI?
jq is available in Ubuntu's universe repository along with requests.
Re: The Bash Hackers Wiki
#30It seems like there is potential for making bash faster. 1. JIT compilation, caching and invalidating on updated source files 3. Rearchitecting similar a-la busybox all of coreutils, sharutils, grep, awk and sed as internal components to avoid forking as much as possible. Tool symlinks back to itself for compatibility. 4. Rearchitecting to simulate sub-shells with threads and local contexts, rather than globals/singu…
If you really care about speed, you probably shouldn't be using Bash.
Also true of Python, but I almost never hear people say that. Strange.