241–250 of 272 posts
Earlier quoted context omitted.
They are needlessly rude and mean at #bash. A bunch of scumbags, actually.
I think it's a result of constantly dealing with people who ask for help, receive good advice, and then ignore it
#0: If you're writing scripts that are destined for other users, use POSIX sh instead.
Do you know of any learning resources that are strictly POSIX sh instead of a specific shell? I'm looking to learn and it will be very helpful.
On top of that you can use `checkbashisms` tool to lint your script against bash specific syntax.
Earlier quoted context omitted.
> As someone who has to occasionally modify 100+ line bash scripts written by Coworkers from Christmas Past which matched your spec in terms of what they had to do, please please just use Python (or similar). As someone who has inherited thousand-line shell scripts, and had to debug many 3rd party scripts, I stand by my assertion. > Yes, you will have a few extra lines but it will be vastly more readable and maintain…
subprocess.run does exactly what your wrapper does, subprocess.check_output returns stdout only and automatically throws exception on non-zero return code, this is the function you should be using 99% of the time. Those functions both accept a string as stdin-parameter.
Also, who is to say what I should be using "99% of the time?" Each problem has different constraints and different priorities.
Earlier quoted context omitted.
So it boils down to your personal taste.
For most workloads where bash is suited, so is sh. For workloads where sh is insufficient, bash probably is too and you should just use a higher level language. Chill. You don't have to hold bash so close to your heart.
#0: If you're writing scripts that are destined for other users, use POSIX sh instead.
Do you know of any learning resources that are strictly POSIX sh instead of a specific shell? I'm looking to learn and it will be very helpful.
And the accompanying reference site: http://shellhaters.org/
Earlier quoted context omitted.
Exactly: GNU bash is on most GNU/Linux systems, but: * mac OS uses an ancient version of bash * Embedded systems use busybox sh * Android uses its own version of sh * None of the BSDs come with bash, since, y'know GNU licensing EDIT: Formatting
And to make things interesting Ubuntu uses dash as sh https://wiki.ubuntu.com/DashAsBinSh
The shebang line #!/bin/sh should only be used for POSIX-compliant scripts; if it needs {bash, dash, python, etc.} it should start #!/usr/bin/env {bash, dash, python, etc.}.
Earlier quoted context omitted.
The relevant point is that all systems running bash should also be POSIX compliant. So, taking some care to avoid bash-only constructs in a shell script can reap substantial gains in portability at fairly minor cost.
Why I should care about all systems? If targeted systems have bash4.x and GNU tools, why I should write scripts in sh? If you care about all systems, ANSI C is better choice, IMHO.
But it's silly to think that there's nothing in between "complete control over target environment" and "use ANSI C so it can be compiled to any architecture and platform under the Sun." POSIX compliance will cover a lot. Try browsing /usr/bin on any Unix system you'll see plenty of use cases. I just looked at /usr/bin on my laptop and saw that mysqld_safe is a Bourne shell script, for just one example.
Using readline is a great thing to know about too. My favourite little-known readline command is operate-and-get-next: https://www.gnu.org/software/bash/manual/html_node/Miscellan... You can use it to search back in history with C-r and then execute that command with C-o and keep pressing C-o to execute the commands that followed that one in history. Very helpful for executing a whole block of history. For some reaso…
ctrl-r, find a command, press ctrl-o -> inserts ^o in the command and exits of ctrl-r.
Running bash 4.4.12(1) on Linux.
Earlier quoted context omitted.
subprocess.run does exactly what your wrapper does, subprocess.check_output returns stdout only and automatically throws exception on non-zero return code, this is the function you should be using 99% of the time. Those functions both accept a string as stdin-parameter.
Subprocess.run is Python 3+ only. If we're talking about replacing bash, Python 2.7 (possibly with 2.6 compatibility) is the more reasonable target. CentOS 7 and Debian 8 (I've not used 9 yet) still ship with Python 2.7. Also, who is to say what I should be using "99% of the time?" Each problem has different constraints and different priorities.