31–40 of 45 posts
I think the author forgets to mention that the primary reason bash is used is because of its cross distribution support. I known if i write my script in bash it will work on any small linux distro. I think python is a close second, but it still use bash to bootstrap my environment for my real work.
"Rewrite all your shell scripts in Python! Now you can ignore shell!"
No.
(I also have a hard time seeing the upside of e.g. Fabric. It's a Python wrapper around the shell, so now you have two things to learn: the actual commands that you need to execute, and how to express those commands in this bespoke Python-to-shell mapping.)
Just learn shell. It's not going anywhere. You'll always have occasion to use it. People will respect you.
(Edit: One trick I like: If I'm writing a shell script an there's some fiddly bit of processing that is PITA to express in sh I'll write a tiny Python script that does it and call that from the shell script. Not great for performance, but usually it's a one-off or small batch so you don't care. Sometimes it's a small enough Python snippet that you can just use `python -c "..."`)
I think the author forgets to mention that the primary reason bash is used is because of its cross distribution support. I known if i write my script in bash it will work on any small linux distro. I think python is a close second, but it still use bash to bootstrap my environment for my real work.
I've been using POSIX shell exclusively, and spent a week or so converting all of my existing scripts to POSIX a few years ago (when Ubuntu switched its initscripts to run under dash instead of bash). Bash isn't available on tiny Linux distros by default, because it's quite large. Many use dash, including most busybox based distributions. With checkbashisms and shellcheck, it's pretty easy to spot compatibility issue…
(busybox sh is apparently a close cousin to dash, since they both derive from the Almquist shell.)
Earlier quoted context omitted.
I've been using POSIX shell exclusively, and spent a week or so converting all of my existing scripts to POSIX a few years ago (when Ubuntu switched its initscripts to run under dash instead of bash). Bash isn't available on tiny Linux distros by default, because it's quite large. Many use dash, including most busybox based distributions. With checkbashisms and shellcheck, it's pretty easy to spot compatibility issue…
Shouldn't busybox-based distros use busybox sh? (busybox sh is apparently a close cousin to dash, since they both derive from the Almquist shell.)
"This shell is actually a derivative of the Debian "dash" shell by Herbert Xu, which was created by porting the "ash" shell, written by Kenneth Almquist, from NetBSD."
https://git.busybox.net/busybox/tree/shell/Config.in?id=9d70...
So, yes, it is the "busybox shell", but the busybox shell is a version of dash. So, if you target dash, you're good for busybox distros.
> I’ve idealized the four steps as separate functions. Does the author know he can write functions in bash? I mean, if he wants to compare programming languages, he should at least compare similar programming styles. Bash is great for OS scripts because it has built-in commands and syntax for dealing with processus and their inter-communication (pipes and stuff). Python has NOTHING about that. If you want to do this,…
The problem with Bash functions is that they aren't really functions -- more like subroutines. You can't even return a value from a Bash function (just a numeric status code). Most of the functions the author wrote wouldn't even be possible in Bash, if only because they utilize return values. So your suggestion that he "compare similar programming styles" is practically impossible without using implicit state-passing…
{print_this_garbage_out=`do_a_little_dance` #maybe even with awk|sed|perl|python|sql|mom
retval_for_something_hopefully_cool=$? # or some other requisite test/set, limit sky
echo "${print_this_garbage_out}"
return ${retval_for_something_hopefully_cool}} # don't exit, because that might be silly
The bash is sort of like your machine code, it, like your machine, can use anything it has access to, if told properly. So I don't understand "can't even return a value". I don't know much about bash for bash's sake so I'm wondering if I may have missed something along the way.
I think the author forgets to mention that the primary reason bash is used is because of its cross distribution support. I known if i write my script in bash it will work on any small linux distro. I think python is a close second, but it still use bash to bootstrap my environment for my real work.
I've been using POSIX shell exclusively, and spent a week or so converting all of my existing scripts to POSIX a few years ago (when Ubuntu switched its initscripts to run under dash instead of bash). Bash isn't available on tiny Linux distros by default, because it's quite large. Many use dash, including most busybox based distributions. With checkbashisms and shellcheck, it's pretty easy to spot compatibility issue…
Earlier quoted context omitted.
I've been using POSIX shell exclusively, and spent a week or so converting all of my existing scripts to POSIX a few years ago (when Ubuntu switched its initscripts to run under dash instead of bash). Bash isn't available on tiny Linux distros by default, because it's quite large. Many use dash, including most busybox based distributions. With checkbashisms and shellcheck, it's pretty easy to spot compatibility issue…
And if you're POSIX compliant, you get to target every POSIX platform (GNU/Linux, BSDs, MacOS, GNU/NT) for free:)
The price you still have to pay for cross-platform is the different paths, different output formats for system commands, etc. This is particularly pronounced for the stuff most of my lines of shell scripts are used for, where it's interacting almost entirely with system utilities to figure out where it's running and to do things to make sure the system is able to run the software my scripts are installing (which also interacts with the system in intimate and intrusive ways). But, you'd pay this with just about any programming language.
Then again, I also use shell scripts for building/deploying things where a makefile would be overkill (and of course makefiles interact with the shell, too, so building your makefiles for POSIX shell rather than bash is also a good practice), and I make those with POSIX, as well. And, in those cases, it would definitely be OK on damned near any platform. I even worked on Windows for a few months when I got my current laptop because HiDPI support and the graphics drives on Linux just weren't working well enough, and most of my stuff worked fine there...both in the WSL and from a git bash prompt.
Earlier quoted context omitted.
This is usually referred to as functional or acceptance testing. The goal of these types of tests is to confirm that the overall application works as expected from a users perspective. This is easy with bash. Testing individual units of code inside of a bash script is more difficult. This can be useful for pin pointing which function introduced a bug. Edit: want to add that difficult does not mean impossible. Bats ex…
Yeah, I just don't understand what actually makes it difficult.
The thing other languages lack for me is a clean way to execute other programs. With bash it's just "grep whatever", in other languages it's "exec('grep whatever');". Then piping that output to another program is a lot of work. Bash makes for really good program glue. I've considered creating a library that scanned your PATH for binaries then created dynamic function signatures to allow calling the function by name.…