6 ms·

Most of the responses here so far that do not include some sort of a guide are not the responses you're looking for (imho). Mind your pipes and quotes. Guard y

Most of the responses here so far that do not include some sort of a guide are not the responses you're looking for (imho). Mind your pipes and quotes. Guard your variables with braces. Do not export everything, test for and (try to) handle return codes and conditions and keep it simple (emphasis simple) but most of all just write it. BASH (or Bourne) is ubiquitous when dealing with systems (vs programs). You don't need to be on the fashionable lang of the day by any measure. BASH, for most cases, will always be there, always ready and, in most cases, is the default human interface for deployed systems. As scripting languages go you don't need "better", you need dependability, zero dependencies with no requirement for modules or any other whizbangwoohoo plug-in. Language Fashionistas and personal preferences aside at least some level of fluency with BASH should be mandatory for anyone interfacing with a system.

joshstaiger 9y ago
1000 times this. You're going to get a lot of snark from people saying things like "don't", or "learn python instead". This epitomizes "a little knowledge is a dangerous thing". Bash has many cringeworthy aspects, but we have to deal with the world as it is, not the world as we would like it to be, and the reality is that bash is the default shell on 99.9% of unix boxes you encounter — even if you use an alt shell on your machine. Coworkers machine? Bash. Default AWS AMI? Bash. init script to bootstrap $DAEMON? Bash. ssh to a server at your workplace? Bash. Random O'Reilly Linux tutorial? Assumes bash. My advice? Take some time. Sit down. and read "man bash" cover-to-cover. at least once. A lot of the illogical things in bash make a lot more sense once you understand its parsing/expansion rules. And once you understand what is in the language vs an external terminal program in your PATH. Since that sounds unappealing (and I scoffed at that very advice for many years), I've also found the wooledge bash guide to be very helpful.
- ktRolster 9y ago
  Bash is unbeatable as a functional concept for chaining command-line tools together. Once you start getting functions or even a lot of if/while constructs, it's usually time to switch to Python/Perl.
  - deleted 9y ago
    [deleted]
  - sethrin 9y ago
    I wrote a guide to the shell (posted elsewhere here). I concur with this statement wholeheartedly. Bash as a command language is exceptional, as a scripting language it is sub-par at best. I've been using Ruby a lot lately in command line scripting, little things like $ ls /*.orig | ruby -e 'while f = gets do ... end' It's not quite as easy as the shell tools for little things, but I feel like the crossover point where the lack of programming constructs begins to outweigh the initial ease of Bash scripting is about ten lines of Bash. Which is not to say that it's not useful -- I do think that Bash is something that every developer should know -- but that you really need to have Bash and another command line scripting language in your toolbox, and know when to use each.
    - ktRolster 9y ago
      I used to think of it in terms of "number of lines" but then I found a task that worked quite well in a longer bash script (creating a .deb file). In fact, it worked better than if it were a python script, because all the commands were right there. Now my metric is, "if it needs a function, or even a complex while loop，switch to perl/ruby"
      - sethrin 9y ago
        I think that what I would tell new people would be "more than ten lines, OR using more than two variables, OR any flow control constructs". Bash can make even simple conditional statements difficult, and while my rule is absurdly restrictive, Bash can still be amazingly useful within those bounds. Probably mine is the lower bound for "anything less complex than this is fine to write in Bash" and yours is "anything more complex than this should definitely not be written in Bash", with the middle ground being "have a good reason why Bash is the best tool for the job".
      - sethrin 9y ago
        I think that what I would tell new people would be "more than ten lines, OR using more than two variables, OR any flow control constructs". Bash can make even simple conditional statements difficult, and while my rule is absurdly restrictive, Bash can still be amazingly useful within those bounds. Probably mine is the lower bound for "anything less complex than this is fine to write in Bash" and yours is "anything more complex than this should definitely not be written in Bash", with the middle ground being "have a good reason why Bash is the best tool for the job".
curiousgal 9y ago
https://www.google.com/search?q=whizbangwoohoo https://www.google.com/search?q=whizbangwoohoo
- fredley 9y ago
  Google Whack!
  - quickthrower 9y ago
    Technically no. A Googlewhack requires 2 dictionary words. Dave Gorman won't be visiting us.
- n4s33r 9y ago
  nice, you made a Googlewhack
  - wybiral 9y ago
    If there's a term of photobombing a Googlewhack, I think I just did that.
    - curiousgal 9y ago
      I am surprised by how quickly that took! Google's crawlers are hard working.
qrbLPHiKpiux 9y ago
I've been using linux since 1992 and if there's one thing I can't stress enough is to use full directories and not anything abbreviated. After 25 years, I still find myself slipping up, overlooking some minute detail, causing data loss.
- mmphosis 9y ago
  I've heard this suggestion to use full paths for a long time. Why use full paths?
  - tyingq 9y ago
    I'm sure there are other reasons, but the big one is that your scripts may get called in an environment other than your normal logged in shell. Cron, for example, doesn't have the same $PATH as your login shell. So no full paths means you can fail to run some commands, or run the wrong copy of one. There's also the security aspect. If your script has "." in it's $PATH, or something else writeable, I may be able to coerce it to run an imposter command.
    - uhhfcuvv 9y ago
      This is terrible advice, if you expect your PATH to be something, just set it at the top of the script and be done with it. No need to make it 100 times harder to read.
      - yebyen 9y ago
        Why even expect binaries to be in the same place on different systems with different default PATHs? Know how many times I've seen problems caused by (#!/usr/bin/bash|#!/bin/bash) pointing to the wrong place? After reading this thread though, I'm not sure I want to suggest people write `#!/usr/bin/env bash` either... since that depends on the path being correctly set, and bash being in the path!
        mobilethrow 9y ago

joshstaiger 9y ago

1000 times this. You're going to get a lot of snark from people saying things like "don't", or "learn python instead". This epitomizes "a little knowledge is a dangerous thing". Bash has many cringeworthy aspects, but we have to deal with the world as it is, not the world as we would like it to be, and the reality is that bash is the default shell on 99.9% of unix boxes you encounter — even if you use an alt shell on your machine. Coworkers machine? Bash. Default AWS AMI? Bash. init script to bootstrap $DAEMON? Bash. ssh to a server at your workplace? Bash. Random O'Reilly Linux tutorial? Assumes bash. My advice? Take some time. Sit down. and read "man bash" cover-to-cover. at least once. A lot of the illogical things in bash make a lot more sense once you understand its parsing/expansion rules. And once you understand what is in the language vs an external terminal program in your PATH. Since that sounds unappealing (and I scoffed at that very advice for many years), I've also found the wooledge bash guide to be very helpful.

ktRolster 9y ago
Bash is unbeatable as a functional concept for chaining command-line tools together. Once you start getting functions or even a lot of if/while constructs, it's usually time to switch to Python/Perl.
- deleted 9y ago
  [deleted]
- sethrin 9y ago
  I wrote a guide to the shell (posted elsewhere here). I concur with this statement wholeheartedly. Bash as a command language is exceptional, as a scripting language it is sub-par at best. I've been using Ruby a lot lately in command line scripting, little things like $ ls /*.orig | ruby -e 'while f = gets do ... end' It's not quite as easy as the shell tools for little things, but I feel like the crossover point where the lack of programming constructs begins to outweigh the initial ease of Bash scripting is about ten lines of Bash. Which is not to say that it's not useful -- I do think that Bash is something that every developer should know -- but that you really need to have Bash and another command line scripting language in your toolbox, and know when to use each.
  - ktRolster 9y ago
    I used to think of it in terms of "number of lines" but then I found a task that worked quite well in a longer bash script (creating a .deb file). In fact, it worked better than if it were a python script, because all the commands were right there. Now my metric is, "if it needs a function, or even a complex while loop，switch to perl/ruby"
    - sethrin 9y ago
      I think that what I would tell new people would be "more than ten lines, OR using more than two variables, OR any flow control constructs". Bash can make even simple conditional statements difficult, and while my rule is absurdly restrictive, Bash can still be amazingly useful within those bounds. Probably mine is the lower bound for "anything less complex than this is fine to write in Bash" and yours is "anything more complex than this should definitely not be written in Bash", with the middle ground being "have a good reason why Bash is the best tool for the job".
    - sethrin 9y ago
      I think that what I would tell new people would be "more than ten lines, OR using more than two variables, OR any flow control constructs". Bash can make even simple conditional statements difficult, and while my rule is absurdly restrictive, Bash can still be amazingly useful within those bounds. Probably mine is the lower bound for "anything less complex than this is fine to write in Bash" and yours is "anything more complex than this should definitely not be written in Bash", with the middle ground being "have a good reason why Bash is the best tool for the job".

curiousgal 9y ago

https://www.google.com/search?q=whizbangwoohoo https://www.google.com/search?q=whizbangwoohoo

fredley 9y ago
Google Whack!
- quickthrower 9y ago
  Technically no. A Googlewhack requires 2 dictionary words. Dave Gorman won't be visiting us.
n4s33r 9y ago
nice, you made a Googlewhack
- wybiral 9y ago
  If there's a term of photobombing a Googlewhack, I think I just did that.
  - curiousgal 9y ago
    I am surprised by how quickly that took! Google's crawlers are hard working.

qrbLPHiKpiux 9y ago

I've been using linux since 1992 and if there's one thing I can't stress enough is to use full directories and not anything abbreviated. After 25 years, I still find myself slipping up, overlooking some minute detail, causing data loss.

mmphosis 9y ago
I've heard this suggestion to use full paths for a long time. Why use full paths?
- tyingq 9y ago
  I'm sure there are other reasons, but the big one is that your scripts may get called in an environment other than your normal logged in shell. Cron, for example, doesn't have the same $PATH as your login shell. So no full paths means you can fail to run some commands, or run the wrong copy of one. There's also the security aspect. If your script has "." in it's $PATH, or something else writeable, I may be able to coerce it to run an imposter command.
  - uhhfcuvv 9y ago
    This is terrible advice, if you expect your PATH to be something, just set it at the top of the script and be done with it. No need to make it 100 times harder to read.
    - yebyen 9y ago
      Why even expect binaries to be in the same place on different systems with different default PATHs? Know how many times I've seen problems caused by (#!/usr/bin/bash|#!/bin/bash) pointing to the wrong place? After reading this thread though, I'm not sure I want to suggest people write `#!/usr/bin/env bash` either... since that depends on the path being correctly set, and bash being in the path!
      - mobilethrow 9y ago