10 ms·
The Bash Hackers Wiki
- zimbatm 7y agoAnother great reference is https://github.com/dylanaraps/pure-bash-bible https://github.com/dylanaraps/pure-bash-bible
- dijit 7y agoBash 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.
- mistrial9 7y agoside note -- jobs+join is not a bad thing in many cases !
- ofrzeta 7y agoI'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 https://docs.python.org/3.7/library/pathlib.html
- badsectoracula 7y agoThe 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).
- Doingmything123 7y agoI 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.
- Aloha 7y agoHaving migrated something recently from python2 to python3, I'll take bash. I actually ported two of the three scripts to bash, and the third one I reluctantly moved to python3 (I needed python-pil). String handling in python3 in my opinion is a tire fire compared to bash.
- lizmat 7y ago> Perl 6 that was renamed to something else Indeed, it has been renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media).
- ShorsHammer 7y agoHaving 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?
- heavyset_go 7y ago> 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.
- ShorsHammer 7y agoit's python, requests is one of it's many libraries for the purpose, would actually be quite concerned hiring someone who doesn't know the multiple stdlib solutions for this and still claims ability in python. import json import urllib.request tough hey
- heavyset_go 7y agoI'd be as concerned with someone not opting to use what the documentation recommends[1] in lieu of the stdlib, as I would someone who puts together an awkward Bash script to parse JSON instead of just installing the 50kb package for jq. > The Requests package is recommended for a higher-level HTTP client interface. [1] https://docs.python.org/3/library/urllib.request.html https://docs.python.org/3/library/urllib.request.html
- ShorsHammer 7y agoIt's a lot easier to hire people than fire them friend. The documentation recommends nothing of the sort, it's a direction for consumers. We all live in varied and different worlds, how many varied server environments have you been responsible for all at once? Is it really beyond your amazing programming skills to use the tools at hand in every circumstance? Perhaps it's a chance to demonstrate yet another 3rd party tool which fixes non-existent problems. It's a few bytes difference in your script that is using requests over the numerous and plentiful stdlib options there.
- ekianjo 7y agoPython needs to be installed, maintained, and every single library will have its list of dependencies (along with breaking API changes once in a while). There's a reason Bash exists: it's everywhere by default and you know it will still work as it works now in x years.
- epr 7y agoI'm sorry, but for the type of work he is suggesting (bash script equivalent), you don't need anything besides the standard library. I cannot think of a single system I have used in recent decades that didn't come with python installed by default. For all intents and purposes, Python is as ubiquitous as bash at this point.
- tjoff 7y agoMy phone and router have bash. Even if pyhton is installed it isn't certain if it is v.2 or 3.
- thewhitetulip 7y agoWe use AIX at work and it didn't have Python installed. We had to install it for a code review tool I built. But despite Bash's weird syntax, I love how we can do very complex tasks within a few lines.
- vaingloriole 7y agoBalderdash and hokum. z=1 ; while test ${z} -lt 4 ; do a=${RANDOM:1:3} ; dd if=/dev/urandom count=12 bs=4 of=${a} && b=$(cat ${a}) && echo ${b:$(expr 1 + ${RANDOM} % 4):12} ; ((z++)); done You have one tool that you know well. I have thousands of tools that I've learned daily and I wrap with a bash script..except when I need python/tcl or C. Most of what I do in python/tcl/C is truly complicated, needs to be fast or use a data structure other than an array: as it should be. Most of what I do in the shell is as simple as the userspace tools and bash will let it be. Write the one liner above in python without importing a library.
- hannob 7y agoActually I have recently analyzed some python code that does some shell calls and if I can eliminate them with pure python. It was quite frustrating. A lot of stuff that the shell has simple functionality for can't be done easily in python. Examples: * Call to chown -R. Sure, python can change file owners (os.chown()). But it has no parameter to do this recursively. You need to build a loop around it over some file iteration function. * Call to setfacl. Can't be done with the python standard library, needs pylibacl and you can't rely on it being installed. * Call to killall -HUP [processname]. You can send kill signals with python, but only to pids, not to process names. You'd have to parse the system process list or something like that in order to simulate. In all cases I decided to keep the shell call, it just wasn't worth it converting that to less readable python code.
- ofrzeta 7y agoFair enough, choosing the right tool for the job. On my own servers I can take care that the requires modules are installed and even use virtual envs for stable library versioning. This is how we do Let's Encrypt renewal because I can use a Python library for Route53 authentication that works. Your first example could be solved with something like [os.chown(p, uid, gid) for p in pathlib.Path('.').rglob('*')] Obviously this is more verbose than chown but I think it's ok in a script.
- yeowMeng 7y agoBash 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”.
- _jal 7y agoI 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.
- igetspam 7y agoGoogle'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...
- Aloha 7y agoI think in bash still. I know python and php, but I still think in bash.
- thewhitetulip 7y agoI love Python, I am a Python trainer and wrote an into book on it. But few years ago, I finally learnt how to use shell and it blew my mind. With a single command, I can split a really large files in 100 based on a particular column or I can aggregate and do whatever I want with a few piped commands, preview any file with sed '3p' file Sure. I do not write 100lines of awk code, but I believe I have started utilizing some potential of bash and I don't anymore fire up Python shell and write ten lines which then someone has to maintain! In my org, our Program manager discovered Python and he looks to replace entire unix scripts whoch do exactly what they are required to do, never fail and will work without any changes to Python. I don't understand that. I don't want Python to "win" because there are things you can do in bash, if you learn it correctly
- heavyset_go 7y ago> Bash was the first scripting language I ever got "good" with. Same here. However, it wasn't until I used other languages to manage systems, or glue utilities together, that I really started appreciating Bash. Bash can be ugly and pretty gross at times, but there are some problems that can be solved quite elegantly with it. > It also left me a bit weird when thinking about concurrency Funny, one of the things that I like the most about Bash is how simple it makes concurrency, especially when you pair it with GNU parallel.
- Galanwe 7y ago> Funny, one of the things that I like the most about Bash is how simple it makes concurrency, especially when you pair it with GNU parallel. Or xargs :-)
- CJefferson 7y agoSub shells are something I don't think get used enough. I would love it if it was easier to spawn extra processes, particularly if those processes could be strongly sandboxed. Who cares about overflows in your video encoder, if all it can do is make you output broken / different video?
- ravoori 7y agoIt would be remiss to talk of bash and not bring up Greg's Bash Wiki (https://mywiki.wooledge.org/BashFAQ https://mywiki.wooledge.org/BashFAQ)
- rascul 7y agoThis and the bash man page are all I need in general.
- oh_sigh 7y agohttps://xkcd.com/927 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.
- 0xdeadb00f 7y agoI use POSIX /bin/sh exclusively. It's reasonably lightweight but because of this you loose a lot of the "bash-ism"s. There's ways to work around it though, and the pure-sh-bible[1] is great. 1: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible
- chubot 7y agoThat's what Oil is, except it also runs bash scripts and lets you upgrade seamlessly. That is, bin/oil is the same as bin/osh with a bunch of shell options on, including 'shopt -s simple_word_eval' which eliminates a lot of the quoting hassles. You can try it now, but some things will be cut out after optimizing the prototype interpreter (in the name of time): You Can Now Try the Oil Language http://www.oilshell.org/blog/2019/10/04.html http://www.oilshell.org/blog/2019/10/04.html I'm looking for help too: http://www.oilshell.org/blog/2019/12/09.html#help-wanted http://www.oilshell.org/blog/2019/12/09.html#help-wanted ---- Also, I think there is more room than ever, because both Python 3 and Perl 6/Raku are worse for shell-like tasks than their predecessors! Mainly because of startup time and the string abstaction. We discussed that a couple weeks ago here, and I think it's on the blog somewhere too: https://news.ycombinator.com/item?id=22156151 https://news.ycombinator.com/item?id=22156151
- rane 7y agoOnce Oil has better documentation I'll probably give it a try. The documents outlined in "Docs I Want to Write" seem promising and are still only visible as drafts in Zulip which requires logging in.
- chubot 7y agoThat's fair, in the meantime this post gives some more examples: http://www.oilshell.org/blog/2020/01/simplest-explanation.html http://www.oilshell.org/blog/2020/01/simplest-explanation.ht... as well as other posts tagged #oil-language: http://www.oilshell.org/blog/tags.html?tag=oil-language#oil-language http://www.oilshell.org/blog/tags.html?tag=oil-language#oil-...
- anonsivalley652 7y agoIt 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.
- dfox 7y agoI think that there is really good reason why you don't want to do any of that: bash shell and not general purpose language/VM. And I say that as the author of what essentially is point of sale system implemented in bash with ui based on dialog/whiptail...
- saagarjha 7y agoIf you really care about speed, you probably shouldn't be using Bash.
- yesenadam 7y agoAlso true of Python, but I almost never hear people say that. Strange.
- saagarjha 7y agoPython's a bit faster than Bash.
- vaingloriole 7y agoFor what? Is it faster than (g)awk? How about sed? How about dd? How about any of the thousands of tools in userspace that you wrap in bash and are faster than python at the same task? Use the right tool is being lost in the 'you are too stupid to make a good decision, do it this way' generation.
- AceJohnny2 7y agoThis website has been my go-to reference when hacking together Bash scripts. I can never remember the exact syntax of parameter substitution, and how do I do arithmetic substitution again? What's all the 'set -o' options? I've since switched to Zsh, and while its documentation is extensive, it's basically one fat book and is far from being as accessible or navigable at this excellent wiki.
- m463 7y agoI 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.
- _jal 7y agoPython'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.
- chubot 7y agoI agree, I basically wrote the same thing in the FAQ for Oil: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-scripts-over-100-lines-be-rewritten-in-python-or-ruby http://www.oilshell.org/blog/2018/01/28.html#shouldnt-script...
- m463 7y agoI 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])
- Too 7y ago99.9% of all process management can be done with oneliner subprocess.check_output. Not verbose at all and much safer. Biggest mistake people do is bringing bash idioms into python, like trying to pipe the output through head/cut/tail/grep/sed instead of just using string operators like endswith/in/startswith/re. If you do that then process managment will be more verbose, but it is in bash also unless you ignore decent error handling like $PIPEFAIL[0] which many many scripts actually do unknowingly. For those other 0.1% of the places where you actually need a pipe then just accept that you have to write 4 lines instead of 2, you will save thousands of lines in other places. For parallel running processes &, jobs, nohup and wait in bash isn't exactly convenient either if you are interested in the results, so there it's a tie vs POpen if i'm being generous.
- bachmeier 7y agoI recently came across this static site generator written in Bash: https://github.com/hmngwy/jenny 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.)
- asveikau 7y agoClicking around, I am glad to see portability to non-bash shells covered in some topics, despite the name of the site. It seems to me like sometime in the last 10-15 years, what we used to call "shell scripting" became "bash" in popular discourse. I myself learned to write shell scripts in times and places where bash was the most popular default, but I never thought of it as writing intentional bashisms, but a set of skills applicable to multiple possible implementations, so I find that shift in jargon a little disappointing or incorrect.
- tannhaeuser 7y agoAn even more important point since the two mainstream desktop Unixen (Mac OS and Ubuntu) ship with zsh and dash, resp., by default.
- laumars 7y agodash is shipped as a replacement for the Bourne shell, not bash. Thus Ubuntu does also ship bash too. Alpine doesn't have bash installed. It alsonpretty common not to have bash as part of the base image on non-Linux systems too. You've already mentioned macOS but the same is true for many of the BSDs.
- wodenokoto 7y agoI think bash has become the new name for "shell", in the same way kleenex and hoover became names for product categories, rather than brands.
- kyuudou 7y agoI think the biggest distinction between shells is whether they are C-shell derivative (csh/tcsh) or Bourne shell derivative (sh/ksh/bash).
- wodenokoto 7y agoI clicked the config article and it reminded me of 2 major pet peeves: 1) No good way to store config values, nor ones that can be shared with other languages. I might have a set of python applications running in the cloud and a shell script to deploy them, and guess what, I'd like them to share the same config, so I don't have to keep to update resource names in 2 places. 2) No simple way of templating files. A script that would replace {var} with value of $var in a file seems like an obvious thing for shell to do for you, but I haven't found a good way of doing it.
- dijit 7y agoMaybe I’m misunderstand the points here but shouldn’t point 1 be covered by environment variables mostly? And for point 2, basically the same thing, you can set variables to have a default value and then try to read the environment. export variable=${variable:-“some_default”}
- laumars 7y ago1) There's a few ways you could skin this proverbial cat: option 1: A bit python specific but you can use python-dotenv[1] for Python; and `source` that file in bash for shell support. option 2: Alternatively you could just pass environmental variables between applications (that's kind of the point of them). option 3: You could still use a dot env file and import that in other languages as TOML. This is a really nasty hacky way of doing things though because you'd need to read that file in, then prefix a key at the start of the file (eg "[vars]") to adhere to the TOML standard before you could run it through a TOML parser. I wouldn't personally recommend this approach but it would work as a lazy solution. 2) Sure there is, `envsubst`[2] hello.tmpl: This is an exmaple Hello, ${HELLO_NAME}! hello.env: HELLO_NAME="wodenokoto" hello.sh: #!/bin/sh source hello.env envsubst < hello.tmpl > hello.txt Run hello.sh and it will create a file called hello.txt: This is an exmaple Hello, wodenokoto! One caveat is that this is part of the gettext package which doesn't always ship with every distro. But it's a pretty small package (small enough that I don't have any issue installing it into a docker container for one CI pipeline). [1] https://pypi.org/project/python-dotenv/ https://pypi.org/project/python-dotenv/ [2] https://linux.die.net/man/1/envsubst https://linux.die.net/man/1/envsubst
- INTPenis 7y agoThis, Greg's wiki and #bash@freenode is how I became a bash nazi to my peers. Just hanging out in #bash@freenode you learn so much best practice. Like sub-shell quotation, variable capitalization, parameter expansion, read usage and much more.