24

I am trying to learn some Bash to maybe get a job working with computers one day.

To improve my clarity and disciple writing my self-learning code, I am trying to adhere to a set of consistent "guiding principles".

As I roll my own "guidelines" I obviously ask myself: should I not be using an established standard instead?

I could not find one such "authoritative" reference for Bash, similar to what these other languages have:

Is there a link with a similar document for Bash which has good reason for being used?

Here is the type of stuff I was putting together on my own... but I think, especially as a beginner, I should be using guidelines written by experts rather than trying to come up with my own, as they would not be based on much experience, insight, practicality, knowledge of common patterns/anti-patterns, etc.

You may dispute the validity of such documents in general, but some people must like them for the web to have such prominent examples online as the ones I mention in the bullet-list above..

################################################################################    
# Coding conventions                                                                
#                                                                                   
# - Prefer lines of 80 characters of length or less                                 
#                                                                                   
# - Perform arithmetic operations and numeric comparisons within "(( ))" blocks     
#   e.g. if ((42<=24+24)), ((3**3==27))                                             
#                                                                                   
# - Reference variables by name, not expansion, within arithmetic evaluation        
#   e.g. ((i++)) rather than (($i++)), ((v+=42)) rathern than v=$(($v+42))          
#                                                                                   
# - Prefer "[[" to "[" for conditional expressions                                  
#                                                                                   
# - Prefer "[[ $s ]]" to "[[ -n $s ]]" when checking for empty strings              
#                                                                                   
# - Document each function with at least a summary sentence. This should not        
#   exceed the preferred line length, be written in third person, end with a        
#   period and concisely describe the general utility of the function   
#
# ...
# ...
# ...
#            
################################################################################
Improve this question
8
  • 1
    Of course people may prefer different styles. I believe if an argument can be made for the Google Python Style Guide to exist, a similar one may be made for a Bash equivalent. In that light, and for those people who find these standards useful, I thought that picking a reasonable on would help. Commented Mar 25, 2013 at 9:04
  • 3
    Most of those guidelines should be exactly reversed. As is, they do nothing but create unportable bash-specific scripts. Don't learn bash programming. Learn shell programming. If there's on best practice, it is sticking to POSIX as much as you can. Commented Mar 25, 2013 at 9:36
  • 2
    Given your many posts on the topic of bash programming, you seem to be placing an undue importance on the topic. I doubt you are going to find a job where shell programming is your primary duty; an in-depth knowledge of bash can make everyday tasks easier, but it's not going to be the primary reason you are hired. Style guides for Python exist to provide consistency for projects with many contributors or projects whose long lifetime suggests they will be maintained by people not involved with earlier development. Similar projects written in bash are rare. Commented Mar 25, 2013 at 12:43
  • 2
    On the other side of @chepner's coin is the fact that true experts in shell scripting are likewise rare. If you set out to learn shell scripting or even specifically BASH, keep going. Don't let us talk you out of it. Shell scripting may not serve you in your career in a direct way, but there are few enough people that know it well and far too many who only think they know it. Even in the abstract it's a useful thing to understand. Commented Mar 26, 2013 at 3:02
  • 4
    @chepner: To eventually be hired, I set myself these goals: learn bash to be fast and accurate on the command line, learn python to write my scripts, learn java to do my GUIs (SWT), learn android to do my mobile apps, learn linux to do my sysadmin, learn machine learning to do my back-end stuff (I have ideas), learn html5/css/jscript to do some, probably very little web presentation, as in "a little web site for myself", learn algorithms and compete in a few TopCoder tournaments to get some interviewing practice. Bash is just my 1st step: foundations and not looking silly @ CLI Commented Mar 26, 2013 at 10:48

2 Answers 2

Reset to default
16

The best bash style guide I have come across is from Google.

There is also some additional advice from the Chromium project.

For learning bash, the Apple Developer Shell Scripting primer is excellent.

Using a style guide for bash is rather sensible, as it is full of tricks and unexpected and difficult to diagnose quirks. Thus, if you follow the same style all the time, you should only fall for each of those tricks once.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

While the currently accepted argument has some really good rules, they don't seem to be a reference to anything widely accepted and used. This answer improves on that.
12

My shell scripting standards

  1. Prefer portability, but don't sacrifice security and whitespace awareness to it.
  2. Prefer builtins over external commands.
  3. But, use fast external commands to process very large inputs.
  4. Avoid unnecessary subshells and pipelines.
  5. Don't preoptimize.
  6. Learn the rules of quoting. Then, use quotes.
  7. Use functions to improve readability and control scope.
  8. Don't give scripts silly file extensions.
  9. Never change directory without checking that it worked.
  10. Eschew hobgoblins

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

– Ralph Waldo Emerson

When to ignore the portability rule

  1. Use -execdir when appropriate with find.
  2. Use null separators when the toolset allows to avoid accidentally wordsplitting on whitespace.
  3. Learn all the glob extensions and use them.
  4. If your target systems all have BASH, don't bend over backwards to be POSIXLY_STRICT.
  5. Use here strings.
Improve this answer

5 Comments

I am accepting this great answer, thanks! :) I am curious: what would you consider silly extensions, as in your point #8? My favourite of all: use \0!
@Robottinosino Any extension is silly for a shell script. Some editors insist everything needs an extension, so they put .sh after shell and bash scripts. Of course, having the same extension for different kinds of scripts (sh, bash, ksh, zsh, csh, tsh…) is even sillier, because it leaves you with the erroneous impression they can all be invoked the same way.
Oh, I don't feel that way, then. But your other points are good and now adopted by me as well! :)
@Robottinosino it's not a feeling. Take a look in /usr/bin. Grep for '/bin/bash'. Tell me how many of those scripts have extensions. How about the ones with /bin/sh? Extensions are a windows-ism, but you want your scripts to be like shell commands themselves. It ruins the semantics of shell commands if they end in .sh.
Basically no shell scripts bear the .sh extension, you are very right about that! I don't mind the explicitness of it though, as I only prepare "own scripts". You absolutely convinced me about system-level scripts though. Thanks.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.