The Bash Hackers Wiki
wiki.bash-hackers.org
wiki.bash-hackers.org
(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.
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.
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).
Indeed, it has been renamed to Raku (https://raku.org using the #rakulang tag on social media).
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.
import json
import urllib.request
tough hey
> The Requests package is recommended for a higher-level HTTP client interface.
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.
Each to their own. Simply saying what I would look for.
Have any examples of your apt install jq script? How would you install jq on a few hundred machines also?
I'd be happy to share an example of an out of the box python script that does the same job and works virtually everywhere.
Even if pyhton is installed it isn't certain if it is v.2 or 3.
Neither bash nor python seem to be preinstalled on BSDs.
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.
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.
I think most people are spoiled by being able to install anything; I work in a locked down environment and getting anything non-sanctioned in is very difficult, and the sanctioning process is tedious if nothing else.
That, and the fact that libraries are evolving- which is why we end up with horrible things like package/library version pinning.
For instance the "os" module has an "urandom" function that does essentially the same as the "dd" in the bash script. Of course you could also read from the device so you wouldn't need to import "os". You would need to import "random" to get access to the random number generator, though, but it's still part of the standard library.
> python -c "for i in range(4): print(__import__('os').urandom(12)[__import__('random').randint(1,4):12])"
Or something like it, that bash one liner is pretty unreadable and full of side effects that may or may not be needed. A small 3 line python file would be cleaner and more readable.
This can break quite fast if you rely on something from Bash 4 (released 11 years ago, still not on OS X by default), or some command-line tools that's either not installed or uses switches/functions only available in their GNU incarnations.
For anything that involves more than one file or with a line count going into triple digits, I wouldn't recommend bash. And heck, for those kind of scripts, I'd go one step further and stick with plain 'sh', just to be really sure. Bash adds little. GNU missed the train of transitioning to something like ksh93, probably because RMS thought that everyone would be using Guile once Hurd is out. (I once worked with a pretty large piece of software for packaking/administration mostly written in ksh93, as this was more palatable for commercial Unix users -- not as important these days where you won't run into AIX, HP-UX and Irix anymore)
For anything more involved than a few straightfoward lines, I'd probably still pick Perl 5. Very common, especially as some operating systems/distros have it in their core tooling (e.g. CentOS) and because it's included in git, so even available on Windows. Standard functionality is good enough and it's no big jump from sh/awk/sed. Rather do that before I depend on some obscure gawk function or gsed switch, especially as it's really hard to tell whether that's proprietary or in what version it was first introduced. Cross-browser checking is easier these days than cross-distro/unix.
Python does have a better/bigger standard library, but isn't as common and you might even run into Python 2/3 shenanigans these days.
Still, the situations where you have something moderately complex and can't install stuff should be pretty rare. Might not be able to do it for the whole system, but things like perlbrew/rbenv/nvm/pyenv-du-jour solve that mostly. At that level, Go might be an option, too.
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.
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.
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”.
I think the experience did things to him, but he was the guy to go to for awk questions.
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
I have a workflow I maintain, it takes an image from a file path or a url, converts the image to 2-bit color, adds control codes, and sends the job to the printer - and there were two other utilities did various calibration options for the printer.
So, originally it was written in python2, and used an IPP library that didnt make the leap to python3, so I ported the 'core' (downloading the image, and processing it, and adding the needed control codes) part of the job to python3, and then wrote a bash wrapper to run this script, and pipe the output to lp, it also uses $PIPESTATUS to provide intelligent error codes back to the calling application.
When I approached this, I realized that I could have ported the whole thing to bash, but the more I thought about it I realized it'd probably have greater overhead. First I'd have to run the script, then curl, then next imagemagick (which has its own issues), then insert the formatting around the image, and then run lp. I looked at it and figured python has lower overhead to do all of these things, as everything but the image handling is part of the python standard library.
There were two other scripts however, that all they do is output a bunch of strings, and send them to be printed, these were also python2 and used IPP, these however I just reimplemented in bash, and send the jobs directly to cups.
My attitude is use whatever language you feel comfortable with to accomplish the task, you can do serious programming in bash - people are incredulous at this, but the basic unix toolset is so powerful, you can do almost anything with it.
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.
Or xargs :-)
Who cares about overflows in your video encoder, if all it can do is make you output broken / different video?
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.)
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.
echo $(echo $(echo echo))
Due to those command substitutions, on zsh/bash/mksh/dash/yash/busybox/osh you'll see 2 forks/clones, but on ksh93 there will be none, and this allows ksh93 to be insanely fast on "pure" shell scripts that have little use of external binaries and pipes, even faster than dash which is usually known to outperform most shells.
Like one program I had. Basically calling bunch programs in a pipeline but need to poll output of some shell async. C or python makes the pipe code complicated while emulating async Io with tmp is also complicated. In a few cases, is to have second program in python or c or perl and send messages over a pipe.
3. and 4. are helpful. JIT not so much since bottleneck seems to to be parsing rather than executing.
1. I do this in murex but actually the performance improvement barely registers in benchmarks because that's not where the real bottleneck is. It's forking and it's passing data via standard streams (stdout et al) rather than sharing memory. There's lots of expensive syscalls to do stuff that you wouldn't need to do in a monolithic service. It's also worth noting that shell scripting is designed to be a highly dynamic language - even command names can be variables(!) - so there is a limit to just how much up-front compilation and caching you do (at least if you want to retain POSIX compatibility).
2. No 2?
3. I also do this to some extent in murex too, except it's not coreutils but rather a set of additional utils specific for more complex data wrangling (JSON, YAML, TOML, CSV, etc). Unfortunately it comes with a set of additional complexities, any of which are deal breakers:
i) If you don't fork then processes don't register PIDs so you can't easily kill a long running process or command run in error. To get around this in murex I had to create a new, separate, function list. This list only includes processes launched from murex but it has both external files (awk et al) as well as builtins. This works for murex because murex isn't going for POSIX compatibility but this would never fly with Bash because you then need to train users to use different `kill`, `ps`, etc commands.
ii) Many users take advantage of job control, which is where you can stop, resume and background already running processes. This works via signals (like SIGINT which you'd be familiar with) and is controlled by UNIX/Linux and not the shell. To get this working with non-forked builtins takes a hell of a lot of hacking and, once again, breaks POSIX compatibility. In fact I ended up removing support for SIGSTSP from murex builtins because it wasn't reliable (though I do plan on adding it again at some point). I also have a bug where external commands don't get sent a SIGTTIN (signal to tell background processes to pause if they're reading from stdin) and that's largely due to some of the hacks I've made regarding your first point.
iii) re-implementing coreutils is non-trivial. In fact calling it "non-trivial" is a massively understatement. And that's without touching the other utils you've highlighted. This effort alone is enough to be a deal breaker without taking into account i and ii.
The reason busybox works is because it's a subset of coreutils. In fact busybox can be a little jarring at times because it is missing so many common flags. However it does just enough to be a useful emergency / embedded shell.
4. This is how murex approaches sub-shells but you're still limited by the caching problems (raised to point 1) plus the forking requirements (addressed in point 3) in terms of just how much additional performance it will squeeze. However out of all the points you have discussed, this is the easiest to implement.
It's also worth noting that fork-bombs (or equivalent exploits) will always be possible as long as your code has functions. Removing sub-shells wouldn't prevent someone from writing a self-referencing function.
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.
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.
http://www.oilshell.org/blog/2018/01/28.html#shouldnt-script...
However I like this lots:
subprocess.call(['cmd','with','precise','args',file1])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.
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.
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.
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.
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.
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”}
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_NAME="wodenokoto"
#!/bin/sh
source hello.env
envsubst < hello.tmpl > hello.txt
This is an exmaple
Hello, wodenokoto!
That would require me to 1) somehow ensure that shell is sourcing the the environment variables from a file, and 2) we are back to all the hackery mentioned in the article [1]
Also that was just one of three options I listed; and there will be a plethora of other alternatives I've not mentioned too.
You’ve given me a lot of food for thought and some good ideas on how to attack some of my problems.
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.
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.
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
I'm looking for help too: 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:
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-...
Startup time can always be better, agree. But full support for Unicode is needed in this day and age, and that brings overhead, whichever way you do that, and especially so if you want to do it 100% correctly. If you're still living in an ASCII world, then by all means, go for it.
Additionally, in this world of source version control, and virtually unlimited diskspace for source-code, I think using scripts, rather than one-liners, will help better in maintainability rather than using one-liners.
Explained here:
http://www.oilshell.org/blog/2018/03/04.html#faq
which links:
http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ (by Armin Ronacher)
The summary is that there are two kinds of Unicode support:
- UTF-8 based: Go, Rust, and Oil (and Perl 5 it seems, not sure about Raku)
- array-of-codepoint based: bash/zsh/libc, Python, Java, JavaScript, Windows (JavaScript notably requires surrogate pairs, Python used to have build time configuration, now has complex storage heuristics, etc.)
This isn't a theoretical problem -- the Unicode problems in the other comment thread I linked are real and show up in practice.
Many don't really understand the string model (because many don't really understand character encoding) but it comes down to: all input and output is going to be bytes, which by default is stored as the codepoints sharing the ordinals of those bytes, and there are several mechanisms by which you can manually or automatically decode/encode those byte ordinals to the represented characters; for most text processing, you do this on STDIN and STDOUT.
Most of what people hope for Unicode support to achieve beyond that (case-folding, homoglyph elimination, &c.) is not only not achieved, but not even possible.