31–40 of 71 posts
Earlier quoted context omitted.
The niche is installer scripts. Because there is one certainty: Bash is available everywhere.
> Bash is available everywhere POSIX mistake number 1: Bash isn't available everywhere, even when restricted to Linux . Even Debian avoids bash for a good reason (Bash is slower than most POSIX shell implementations), although it's installed by default for convenience.
:-/
Earlier quoted context omitted.
No it can't. You have the argument array which is a horrible workaround. If you need to write scripts that interact with other tools a lot, bash is the language of choice. Starting and handling other processes is a messy thing in any other language.
It's not a terrible workaround; it's a beautiful demonstration of how flexible the standard shell is.
2 things I'd love to see in a checker would be: Warn me when I'm using -h instead of --help. When writing persisted scripts it's often more descriptive and self documenting to use long form flags[0] when a tool gives you both options. Warn me when I mix using "-p 8000:8000" and "-p=8000:8000". I know it's technically not possible to give a definitive answer here because supporting spaces vs equals comes down to the C…
[[ -1 -eq 0-1 ]] && echo true || echo false
[[ -1 == 0-1 ]] && echo true || echo false
Earlier quoted context omitted.
Which POSIX sh do you have in mind and how does one pass arrays around in it?
POSIX sh. Pass it as a string, use standard programs to turn it into what you want. Voila. Not that hard. Just like you do everything else in UNIX.
Even if it were an implementation, how would you write a "POSIX sh" equivalent of these lines taken from a bash script? (My point isn't that it's impossible.)
mkdir -p /tmp/nodes/{a,b,c,d,e} ; NODES=( /tmp/nodes/{a,b,c,d,e} ) ; echo ${NODES[$((`date +%-j` % ${#NODES[@]}))]}
I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan. What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a bet…
Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?
Many simple file and data munging tasks can be done on cli 100x faster with 10x less code than Python, using rudimentary bash-fu.
I already see a wave of Python undoing in the data world. Python becoming the cobol of this field.
I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan. What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a bet…
Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?
So what you need is a good language that lets you concisely express ways of calling out to other programs. Not necessarily a language that's backward-compatible with whatever seemed like a good idea for a CLI in 1979.
Google's styleguide has incorrect bash being used, they are using string comparison operators for numeric comparisons (see the various `$? != 0` and $PIPESTATUS). [[ -1 -eq 0-1 ]] && echo true || echo false [[ -1 == 0-1 ]] && echo true || echo false https://www.gnu.org/software/bash/manual/html_node/Bash-Cond...
See also where it says: > For preference, don’t use [[ … ]] at all for numeric comparisons, use (( … )) instead.
Earlier quoted context omitted.
Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?
So your 10 lines of bash use a bunch of other programs to do almost all the work, right? So what you need is a good language that lets you concisely express ways of calling out to other programs. Not necessarily a language that's backward-compatible with whatever seemed like a good idea for a CLI in 1979.
All that in... (goes off to wc -l the script) ...twenty lines of bash, a third of which are comments.
> language that lets you concisely express ways of calling out to other programs
Seems like bash meets those requirements to me, dawg. /shrug