5 ms·
A better approach is to avoid writing bash scripts. They're just too dangerous, even with "strict mode" (http://redsymbol.net/articles/unofficial-bash-strict-mo
by itamarst 5y ago
A better approach is to avoid writing bash scripts. They're just too dangerous, even with "strict mode" (http://redsymbol.net/articles/unofficial-bash-strict-mode/ http://redsymbol.net/articles/unofficial-bash-strict-mode/).
Better to use Python, or Ruby, or a Rust or Go executable.
- seiferteric 5y agoHow does that help with idempotency? Your better off with Ansible if idempotency is the goal.
- znpy 5y ago> How does that help with idempotency? It just doesn't. Edit: oh and you can write non-idempotent ansible playbooks too... it's not about the tool, it's about the craft, and experience.
- qbasic_forever 5y agoThat still doesn't solve the issue that idempotentcy is getting at though. You can very easily and happily write bad python/go/ruby/etc. code that does things like fail to handle a directory that already exists, a file that was previously created, etc. I'd even argue it's more difficult in those language since it's likely more error checking code to write vs. passing a flag to a command in a shell script.
- _0w8t 5y agoI have a PHP script that does idempotentcy. It was strictly easier to write than a similar code in bash the moment one needs non-trivial and robust patching of config files. And passing force flags can lead to subtle issues as -f and friends may have wrong behavior in corner cases. So for this reason I do not use it in shell scripts and rather do explicit tests before the command, like test -f file && rm file
- Spivak 5y agoDoing so will solve none of the problems outlined in the article. You will still have to write all these patterns in Python to make them idempotent. Also for systems stuff you’re not gaining much lot when your interface is calling binaries. A script of subprocess.run calls is way more cumbersome and the moment you want to pip install something it’s no longer portable and a huge PITA to distribute. Bash has lots of footguns because it’s been around a while; run your code through shellcheck if you’re not confident. It’s the lingua franca of Linux userspace.
- geekbird 5y agoPlus Bash is one basic scripting language that every sysadmin worth their salt knows, even more than sh. There will be religious wars until the end of time about Python vs Go vs Ruby vs Rust vs "The New Hotness". Popular languages change; bash, as a shell language, outlives them. In 1995 Perl was the hot language. Bash was there too. Now people can't maintain Perl code, but Bash still runs. Bash doesn't require add-on libraries or modules, it uses system built-ins. It's the lowest common denominator for system scripting. Also, while Mac tries to force people to switch to zsh, and most lemmings just obey, you can still make Macs obey you, and use bash as your login shell.
- giobox 5y agoBash has the distinction of effectively being one of the only "zero-dependency" cross-platform scripting languages for most software engineers: "just works" on Linux/Macs. On Windows, Git for Windows includes gitbash.exe (for cross platform hook-scripts etc), allowing bash scripts to work on Windows boxes as well. Given the prevalence of git in the software development world, this has meant in my experience bash has very often been the most effective "zero dependency" cross-platform scripting language around. Python/JS/<other runtimes> will rarely work out of the box 100% of the time especially for Windows developers. This makes bash pretty valuable for things like build scripts if you have developers using different OSes. If your source lives in git, you know there is a good chance user must have gitbash.exe too if they managed to clone a git repo on Windows, thus granting as near as one gets to "zero-dependency" cross-platform scripting in my experience.
- EuAndreh 5y agoThe sh shell, or POSIX sh, is closer to a zero dependency language. There are many systems that have shells which are not bash.
- giobox 5y agoExcellent point, and will still work on recent MacOS versions with zsh/gitbash.exe too.
- _0w8t 5y agoBash on Mac is deprecated and zsh is sufficiently different. Plus on minimal installs of containers or in VM one may not even have it with /bin/sh provided by dash or similar minimal shell. So my rule of thumb if one cannot use plain /bin/sh and must depend on bash-specific things, one better use a proper scripting language.
- jolmg 5y ago> and zsh is sufficiently different But generally not with stuff that one typically uses for scripting. In most ways, it's a superset of bash. Besides word-splitting on unquoted variables being turned off with default settings (which is turned on when zsh is called as bash/sh with a symlink or similar), what other differences do you think would be common to find when running random bash scripts with zsh?
- 40four 5y agoThis is a really unproductive comment. The bash script versus ‘real scripting language’ is an argument that we will all be fighting over until the end of time, so no need to bring it up here. The subject is bash scripts, so it’s safe to assume anyone reading the article has decided they have a good reason for implementing the work in bash. As someone who is trying the level up their bash skills, I found the information in this article very useful.
- deleted 5y ago[deleted]
- xdennis 5y agoBash is the glue that's present everywhere. If you need a script to bootstrap something you're better off writing it in Bash than Python. If you think Python is the answer then you have to deal with the whole nonsense around pipenv/poetry/pyenv/asdf/virtualenv/setup.py/requirements.txt/pyproject.toml/wheels/... 5 hours later .../system packages/anaconda.