The Bash Hackers Wiki
wiki.bash-hackers.org
The Bash Hackers Wiki
1–10 of 89 posts
Re: The Bash Hackers Wiki
#2Another great reference is https://github.com/dylanaraps/pure-bash-bible
Re: The Bash Hackers Wiki
#3Bash 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 consider IPC, I just think in terms of jobs+join so my code ends up performing as a series of bottlenecks as everything rejoins the main thread.
That said; getting good with bash has helped my career a lot as a sysadmin; but maybe this is part of why sysadmins struggle with real programming.
Re: The Bash Hackers Wiki
#4Bash 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…
side note -- jobs+join is not a bad thing in many cases !
Re: The Bash Hackers Wiki
#5It would be remiss to talk of bash and not bring up Greg's Bash Wiki (https://mywiki.wooledge.org/BashFAQ)
Re: The Bash Hackers Wiki
#6Bash 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.
Re: The Bash Hackers Wiki
#7https://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.
Re: The Bash Hackers Wiki
#8It would be remiss to talk of bash and not bring up Greg's Bash Wiki ( https://mywiki.wooledge.org/BashFAQ )
This and the bash man page are all I need in general.
Re: The Bash Hackers Wiki
#9Bash 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…
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 environment who become proficient, prolific and efficient win the corporate version of “survival of the fittest”.
Re: The Bash Hackers Wiki
#10It 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/singular locals. With formally-proven safety methodologies, there only needs to be one "shell" process running, a server. All other invocations become thread children if called directly or interact as a client if exec()ed. Subshells become just lightweight threads with Copy-On-Write contexts. No more shell fork-bombs, scripts get crazy fast and reduce first PID.