Better bash in 15 minutes

http://robertmuth.blogspot.com/2012/08/better-bash-scripting-in-15-minutes.html

by wsxiaoys • 12 years ago

475 151 12 years ago

robertmuth.blogspot.com

earless1• 12 years ago

I'm glad this included the "Signs you should not be using a bash script" section. Bash is a very good solution for many cases, but it becomes downright unruly when dealing with a lot of string manipulation and more complex objects.

chubot4• 12 years ago

    your script is longer than a few hundred lines of code
    you need data structures beyond simple arrays
    you have a hard time working around quoting issues
    you do a lot of string manipulation
    you do not have much need for invoking other programs or pipe-lining them
    you worry about performance

It's not a sign you shouldn't be using bash. It's a sign you shouldn't be using ONLY bash.

People who insist on rewriting an ENTIRE program in Python, Perl, or Ruby fail to understand the Unix philosophy (this is a real misunderstanding I've encountered in my work, not a straw man).

You can just write the complex part in another language, but keep the rest in bash. In other words, main() stays in bash. Python et. al. is used as just another process. bash is a language for coordinating processes.

You don't want a 2000 line bash script. But it can be worse to have a 5,000 line Python script that shells out to tons of other utilities, or awkwardly and verbosely reimplements 'xargs -P' or 'sed -i'. Often you can do the same job with 500 lines of bash and 500 lines of Python (or C), and that is the ideal solution.

Python and bash are pretty radically different languages, and they are not interchangeable (the advices "just rewrite in Python" seems to imply they are). You can use each one for the things they are good at.

japhyr• 12 years ago

I think I might have accidentally down voted you. That was helpful feedback for me.

nikatwork• 12 years ago

Modularity is nice, but it's generally easier to debug a program in a single context.

I work with some deployment systems that chain together small scripts in a bunch of different languages. They are a nightmare to troubleshoot.

I'd much rather the spaghetti was all on one plate than follow it from table to table...

barrkel2• 12 years ago

This is how I work. Whenever possible, when I have to write a utility in whatever language, I write it such that it can easily be integrated into shell pipelines. That makes it far easier to glue multiple tools written in different languages together.

__david__3• 12 years ago

…awkwardly and verbosely reimplements 'xargs -P'…

Verbose, and almost guaranteed to be more accurate. The thing about python/ruby/perl is that when you do things the programmatic way you get safety by default. You don't have to remember to 'find -0 | xargs -0' and thing aren't going to bite you in the butt when filenames have spaces in them.

Yes, you can make all that work with shell (heaven knows I've done it), but it's more work and sadly isn't shell's default state.

anon42• 12 years ago

To add, if you need/want to you can write python and perl inline in bash like so:

  python3 - <<'END'
  print('hello world')
  END

The advantage is that you still have only one shell script to ship, which makes sense when the python code inside it is specific to that one script.

Remember to use the <<'END' variant so variable expansion isn't done inside the heredoc. On the other hand, $ doesn't do anything in python and if you're feeling like it (please make sure everybody else is also feeling like it) you can use variable substitution there, in effect generating a python script and executing it.

yason• 12 years ago

I generally, whatever I'm writing, start with bash or considering bash. Usually that means I start with bash, excluding the obvious cases such as graphics or doing heavy data processing where I know from start that line-based approach isn't enough.

Then, when bash isn't enough, I write the difficult parts in Python as standalone utilities and use those from bash. Consequently, I already have a library of little tools in my ~/bin that are generic enough so that I can just use them from bash right away. But every now and then I need to write a special tool that my bash program can use.

Most of my programs "finish" after this stage and they can live for years as a completed bash script calling helper programs. They do their job and there's nothing to add. As long as the program continues to "live on" I just make changes to the bash script or the helper programs.

If at some point I need features that bash can't offer, such as more speed or more complex data processing, I begin to consider rewriting my program in one language. But this is only after the first revision of the program is already complete and I know exactly what to do when porting.

Thus, porting the program is initially only about rewriting in another language, not developing it further at the same time. The first months or years of using the bash script turn into a prototyping stage, and this allows my rewrite be concise, well-thought and clear-partitioned.

In other words, the rewrite becomes a new stable baseline that contains only the best of my bash prototyping, and only solves a perfectly scoped problem. As soon as the port becomes a drop-in replacement for my original bash program I switch to using it and start a development branch to support the new features, if any. Usually the newly gained speed is enough already.

And usually the rewrite happens using C or Scheme. There's rarely enough point in rewriting the script in Python which may already be used to some extent in utility programs that the script calls. At that point I don't want to extend the program but lift it onto a new platform to cut some old baggage that's not needed anymore. There's a certain kind of joy rewriting in a new language something that you know completely before hand. This allows you to only work with the language since the underlying problem is already solved.

Coincidentally, this new C or Scheme program might then, one day in the future, be called from a new bash script...

ejstronge• 12 years ago

Do you have any examples of a tool/workflow that's made its way from bash to bash+python to C?

dllthomas7• 12 years ago

God yes. I spent a year maintaining ~90k lines of bash. Interesting experience...

migrantgeek• 12 years ago

up-voted just to ease the pain

dvirsky• 12 years ago

I'd go as far as saying "having more than a dozen lines". Bash syntax for anything other than basic execution and piping a few commands, is a disaster IMHO. Anything that requires logic should be written in a "real" scripting language.

Python is my choice when I need a bit of logic in my scripts, but it's just a personal choice of course. A good addition for simplifying execution is the "sh" library that lets you call system commands easily as if they were python functions: http://amoffat.github.io/sh/

massysett2• 12 years ago

Agreed; I would also say that you should run from Bash not when you need anything more than a simple array, but when you need any kind of array, period.

The advice on functions also gives me pause because that helps you write longer Bash scripts...not a good idea. Functions are of limited use because they can't really return values (just an exit status.) If a function has to return something, it generally prints it to stdout...which requires use of command substitution to get the result...nasty.

Shells are good for interactive use and for starting other programs, but it's a lot easier to take a full-featured language and make it work like a shell than it is to take a shell and make it behave like a full-featured language.

I'd take this blog post, add considerably to the "when you shouldn't use Bash" list, and put that at the top of the blog post, and then say "but if you absolutely must use Bash for something that is not trivial, here are some things that can make the process manageably nasty instead of truly horrid."

dsfadadsffd2• 12 years ago

There is no need for long set flags, e.g. use

  set -e

and not:

  set -o err

etc.

nfm• 12 years ago

They are functionally equivalent, but the longhand versions are clearly more readable/greppable/google-able. The longhand versions have the exact same benefits as calling a variable eg. `target_file` instead of `a`.

stormbrew6• 12 years ago

Usually true but not always. Calling a for loop iterator "index" instead of "i" just adds unnecessary noise, for example.

I think "set -e" in bash should become common on the same level, it's pretty rare that you really want a script to continue after an unguarded error return.

pmh• 12 years ago

I think "set -e" may be more idiomatic. While not scientific, there are more instances (by about an order of magnitude) of "set -e" than "set -o errexit" found via a code search on GitHub.

Anecdotally, I've nearly always seen "set -e" in bash scripts I've worked with over the years (if the option is there at all).

oblio• 12 years ago

Agreed. It's like

. ./file

versus

source ./file

Try googling for that if your Google foo is weak. "shell script dot"? "bash dot"? (edit: it seems Google search has gotten smarter or probably has an improved profile for me since this time it actually points to somewhat useful stuff; last time I searched for this was 8 or so years ago)

__david__3• 12 years ago

I would argue they make the code less readable, merely because they are not the original names. I certainly had no idea what "set -o errexit" did—I've never ever seen it in the wild and it doesn't sound familiar to me at all (and I've done a lot of shell scripting).

But "set -e"? Oh yeah, I use that all the time. It also has the benefit of being the same name as the command line option. That's especially useful for "set -x" which I use all the time when debugging bash, especially in the form "bash -x myscript".

I would never say "tar --extract --file" either–it's just not done.

bryanlarsen• 12 years ago

My shell scripts almost always contain "set -e -x", and I always forget which is exit on error, and which is echo commands. The long form would help me avoid that problem.

massysett2• 12 years ago

"The two settings also have shorthands (“-u” and “-e”) but the longer versions are more readable."

sleepydog• 12 years ago

I found this web page, from the author of musl libc, very insightful:

http://www.etalabs.net/sh_tricks.html

Shell scripts are great, I use and write them every day (and quite advanced ones, too). But it's very hard to make a shell script robust.

Unfortunately it's hard to find a replacement that is stable and installed everywhere. Perl is pretty close. And python too, if you are careful about making your script compatible with all the different versions.

narsil• 12 years ago

Another useful capability I use to do cleanup is `trap`.

    function cleanup {
        ...
    }
    trap cleanup EXIT

See more here: http://linux.die.net/Bash-Beginners-Guide/sect_12_02.html

eik3_de2• 12 years ago

to clean the command prompt line after CTRL-C:

    trap "{ echo; exit 1; }" INT

e12e• 12 years ago

I don't know, if you're fearing a ctrl-c in the middle of one of those newfangled moving, colourized progress bars (hello, npm), "reset" might be more appropriate?

pavel_lishin• 12 years ago

Is there a way to determine whether the exit occurred due to the bash script finishing successfully, or due to an error (via set -o errexit)?

jacquesm2• 12 years ago

You could trap the error.

rshm• 12 years ago

'set -o nounset' is a must have. I Just suffered this script from Samsung Printer setting Utility. sudo ./uninstall wiped the /opt

  DEST_PATH=/opt/$VENDOR/$DEST_DIRNAME
  #remove destination
  VERSION=`cat "$DEST_PATH/bin/.version"`
  if rm -fr "$DEST_PATH"; then
  	echo "INFO: $APP_NAME (ver.$VERSION) has been uninstalled successfully."
  ...

laurent123456• 12 years ago

Wow, nounset or not, doing a `rm -rf` on a variable without any check is quite irresponsible. Especially if they expect the script to be run as sudo.

jacquesm2• 12 years ago

Just checking if .version exists and if it doesn't exiting with an error code would be a huge improvement, checking if $DEST_PATH is set is a must as well.

Scary to see a big company like Samsung release code this bad.

kirubakaran2• 12 years ago

Use:

  #!/usr/bin/env bash

Instead of:

  #!/bin/bash

This makes the script more portable as you don't rely on bash (or any executable) to be in /bin.

http://en.wikipedia.org/wiki/Shebang_(Unix)#Portability

sgentle• 12 years ago

Are there any situations where you wouldn't be able to find bash in /bin/bash? I haven't ever seen such a system, but I'd like to know if it's something I might run into...

The other thing is, if you're targeting obscure systems, wouldn't it be just as likely that there wouldn't be a /usr/bin/env, /usr/ might not be mounted, or that bash might not be installed at all?

I suppose what I'm asking is: for practical purposes, is the lowest common denominator /usr/bin/env or is it /bin/sh?

clarry• 12 years ago

Are there any situations where you wouldn't be able to find bash in /bin/bash?

Yes there are.

OpenBSD for instance installs third party software under /usr/local. Bash is not a part of the base system.

env(1) on the other hand is a POSIX standard utility and comes with the OS.

kirubakaran2• 12 years ago

[in addition to what clarry said] Habit of using /usr/bin/env becomes more important in other use-cases, such as invoking Python interpreter.

thwarted• 12 years ago

The lowest common denominator is /bin/sh. But bash has a lot of niceties, and the POSIX shell can get the job done, but that lowest common denominator is pretty low. You're still going to be dealing with annoying differences on the platforms anyway.

I don't use env on my shebang lines specifically because it's then PATH ordering dependent (there used to be a thing where /usr/local/bin and GNU tools were last in root's path, but first in non-root users' path). I'm more confident (perhaps incorrectly) that /bin/bash or /usr/local/bin/bash is what I expect it is vs the first thing found in PATH that is named bash is what I think it is (however, this applies moreso to coreutils-like things, that have different SysV vs BSD semantics/options, vs a shell such as bash, which is known everywhere to be GNU bash). Some tools, like ssh, can propagate environment settings based on local, remote or config file settings, and I'd rather not be surprised.

This used to be a bigger deal on systems that put reasonable (where "reasonable" == "what you're used to") tools in /usr/ucb or /opt/gnu, rather than system paths. If you're going to create something that's intended to be "portable", you've got bigger fish to fry than if and where bash is available, and it's wise to abstract system differences to different scripts (run.linux.sh, run.freebsd.sh, run.osx.sh, run.aix.sh, etc) than try to keep everything in one massive script anyway.

dfc5• 12 years ago

  FreeBSD = /usr/local/bin/bash
  OpenBSD = /usr/local/bin/bash

barrkel2• 12 years ago

OS X ships with an increasingly ancient version of bash owing to GPLv3. You probably want to use a later version installed with brew / port etc.

stevekemp• 12 years ago

If you look after random mixtures of Linux and similar you'll be OK, but I've juggled OpenBSD , FreeBSD, Solaris, and Linux all at once.

Usually Solaris would get GNU tools installed beneath /opt, or similar, rather than in /bin.

collyw2• 12 years ago

I always thought the purpose of the /bin directory was for the basic unix commands.

https://en.wikipedia.org/wiki/Unix_directory_structure#Conve...

Crito• 12 years ago

I have seen it in corporate environments where specific versions of things like bash (but more commonly, python, ruby, etc) are pushed to machines to places like /opt/ so that the deployed application could use them without fucking around with the package management of the underlying host. The deployed applications would then be kicked off in an environment with a modified PATH to reflect their dependencies being in those locations.

Those sort of deployments got a lot of milage out of /usr/bin/env

skywhopper2• 12 years ago

Something along these lines would allow using bash without making your script completely broken:

    #!/bin/sh
    if [ -z "$BASH_VERSION" ]; then
        if which bash >/dev/null 2>/dev/null; then
            exec bash "$0"
        else
            echo "ERROR: bash was not in your PATH" >&2
            exit 1
        fi
    fi

    # now start using bash-only shortcuts safely
    if [[ "hello" == "hello" ]]; then
        echo Bash has been achieved.
    fi

I'm not promising that's completely foolproof (it clearly isn't), but it works with the default Ubuntu 13.10 config of having /bin/sh linked to /bin/dash. And you could easily expand on the idea to look in specific locations for the bash binary even if it's not in the path, check those binary's versions, etc.

_paulc• 12 years ago

Any {Free,Open,Net}BSD system.

copergi• 12 years ago

Are there any situations where you wouldn't be able to find bash in /bin/bash?

Basically everything that isn't a typical gnu/linux distro or osx. Bash is not a standard tool, it is a gnu specific shell. Posix requires env to exist, and requires it to exist in /usr/bin/. If you are using bashisms, then using /usr/bin/env bash will let people without bash see that your script is a bash script, and install bash to solve the problem. If you hardcode /bin/bash they have to fix your script.

is the lowest common denominator /usr/bin/env or is it /bin/sh

Ideally you should use /bin/sh of course. But it is missing functionality some people want to use, so in that case using bash the portable way is preferred over using bash the unportable way.

dmytrish2• 12 years ago

The only real situation I'd like to use that is on Android, but it does not have /usr/bin/env either.

teddyh• 12 years ago

If I want to be that portable, I just use #!/bin/sh and write a straight POSIX shell-compatible script instead.

voltagex_• 12 years ago

I also like http://google-styleguide.googlecode.com/svn/trunk/shell.xml but of course some things that work well for Google might not work for you.

dingaling• 12 years ago

  complete -r

disables Bash 'smart tab completion', which in theory is a great idea ( use tab to complete arguments or only list files applicable to the program ) but which never seems to work properly for me.

Disabling it saves a lot of frustrated tab-banging.

dfc5• 12 years ago

Something is terribly wrong with your setup if command line completion is not working.

aidenn02• 12 years ago

A lot of installs come with over-complete smart completion configurations that make <tab> take several seconds (or even 10s of seconds) to complete in fairly common situations.

mateuszf2• 12 years ago

Nice here document feature I have found recently is heredoc with pipe, e.g.

  cat <<REQUEST_BODY |      
  {
    "from" : 0,
    "size" : 40
  }
  REQUEST_BODY
  curl http://localhost -d @-

It allows to pass heredoc text to standard input of next command.

lotheac• 12 years ago

This is a prime example of useless use of cat. Heredoc already means "pass this as stdin", there's no need to pipe it. Your example without cat:

    curl http://localhost -d @- <<REQUEST_BODY
    {
      "from" : 0,
      "size" : 40
    }
    REQUEST_BODY

mateuszf2• 12 years ago

Well, maybe in that case it is. But I like to separate the commands so that the data flow looks sequential. That way it makes more sense to me.

zimpenfish2• 12 years ago

Much as I hate the cargocult invocation of "UUOC", this is actually nicer because it reads more sanely - the HEREDOC is properly linked to the curl whereas the previous has the curl seemingly adrift on its own line unattached to the HEREDOC.

pdkl95• 12 years ago

I like modularity:

    request_body() {
        cat <<REQUEST_BODY |      
        {
            "from" : 0,
            "size" : 40
        }
        REQUEST_BODY
    }

    get_url() {
        curl http://localhost -d @-
    }

    request_body | get_url

I find it helps readability when you come back to it a year later. Of course, it's also easy to parameterize the body, if needed.

/readability sometimes trumps YAGNI

zimpenfish2• 12 years ago

My issue with this is that unless you're maintaining a lot of context and understanding the precise weirdness of HEREDOC piping, that looks at first glance like you're catting the HEREDOC to STDOUT and then running a random curl command. It's clever, sure, but it's harder to read and maintain.

mhitza• 12 years ago

You can also write curl after the pipe

    cat <<REQUEST_BODY | curl http://localhost -d @-
      {
        "from" : 0,
        "size" : 40
      }
    REQUEST_BODY

cynik_• 12 years ago

I'd really recommend using `set -x` or `bash -x script` to sanity check all the commands and expected output.

See http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03...

scott_karana• 12 years ago

The article mentioned both -x and -v, didn't it? ;)

rtpg• 12 years ago

are we going to get a better bash at one point? I've always felt like the only thing bash scripts are good at describing is I/O redirection. But conditionals, dealing with variables, pretty much everything else is frustrating and error-prone

I use fish as my main shell and its slightly better, but just testing things on variables can be a huge mess.

nfoz2• 12 years ago

I'm making shok (http://shok.io) as an alternative, but it's in its infancy (read: currently useless). The basics should be usable in a few months.

shok proposes that the solution to awkward-shell-syntax is to syntactically separate the programming language from program-invocation.

dllthomas7• 12 years ago

Well, we've consistently gotten a better bash as bash development has proceeded. As for something that removes the warts and doesn't cut out anything too important and winds up with adoption - it'll be interesting to see...

Goosey• 12 years ago

I enjoy using fish as my main shell, but as soon as I ran into a "curl oneliner install" that failed in fish (in my case Homebrew's at the bottom of http://brew.sh/) and required me to jump into bash. I enjoy fish so much I continue to use it, but I am in a state of fear that I will at some point encounter some failing shell script that leaves my system in a broken state.

Do you have any recommendations to make fish play better with shell scripts intended for bash?

hollerith• 12 years ago

In fish, type "bash" then return. Now paste in the curl oneliner and hit return. Finally, type "exit" to exit bash and go back to fish.

cpenner461• 12 years ago

I used fish for about 6 months or so and loved it - with this exception. Initially I'd just hop into bash to do whatever I needed (as another comment suggests), but what was the "last straw" for me was not being to have some of the convenience functions that virtualenvwrapper exposes for working with python virtualenvs. My solution was to switch to zsh/oh-my-zsh - I'm pretty happy with it so far, although I do miss a few things from fish (namely the auto suggest/complete when typing previous commands).

Symmetry• 12 years ago

First, don't make fish your system shell. Instead have whatever terminal emulator you use launch it by default. Second feel free to jump back to bash for running things that are bash dependent.

I was jumping into bash a lot working with ROS until I made my own ROS fish bindings and still go back when I'm copying and pasting, e.g., code for grabbing some commit from Gerrit.

ygra• 12 years ago

I love the very last list »Signs that you should not be using a bash script«. That should be a required part of every language/tool introduction/tutorial.

So very often people lose track of when to use what tools. (Although admittedly, so very often people are forced into some tools by external constraints.)

oneandoneis22• 12 years ago

A link on HN about improving bash and it wasn't instructions on how to install zsh. I'm pleasantly surprised :)

weaksauce2• 12 years ago

I like bash and all, but a well tuned zsh is amazing. I was hesitant for a while but it really improved my workflow in the shell.

oneandoneis22• 12 years ago

I switched from bash to zsh some times ago, and miss it when it's not there.. but TBH, the only real difference for me is zsh can turn 'cd s/l/f/p[tab]' into 'cd some/long/file/path' - all other features I'm aware of either exist in Bash too, or aren't useful for me.

What are some of the differences that made such a difference for you?

TylerE2• 12 years ago

Yep!

And thanks to oh-my-zsh (https://github.com/robbyrussell/oh-my-zsh) it really requires very little fiddling, maybe 10 minutes worth.

sliverstorm• 12 years ago

I keep switching back and forth between the two. The latest versions of bash have recovered a lot of ground, and zsh (in my experience) has a tendency to get really slow. Maybe it's the command completion here, or the history search there, but it just tries to be too sophisticated for my purposes (huge cluster environment with countless executables in my PATH, which by the way is constantly changing)

stormbrew6• 12 years ago

The thing about a shell (much like an editor, really) is that if you invest in it too far it becomes much more frustrating than reasonable to go without it. If you tend to shell in to a lot of servers that you lack control over, getting used to zsh niceties just makes the rest of your life that much harder. At least in my experience.

phaemon• 12 years ago

If you're using:

    set -o errexit # or set -e if you prefer

Then you probably also want:

    set -o pipefail

Otherwise, it only checks that the last command succeeds, so something like:

    ls *.ssjkfle | wc -l

will actually continue as success despite the "ls" failing.

zx2c4• 12 years ago

If you'd like to see a decently written piece of bash that incorporates many of these suggestions, check out pass, the standard unix password manager.

Project page: http://www.zx2c4.com/projects/password-store/ Source: http://git.zx2c4.com/password-store/tree/src/password-store....

dllthomas7• 12 years ago

One thing I've liked is throwing ${PIPESTATUS[*]} at the front of my PS1.

hyp03• 12 years ago

Excellent, bash the good parts. More than 15 minutes though.

Googling bashlint, shlint turns up some discussion (bash -n, ksh -n, zsh -n, some github projects), but I doubt they cover this article's specifics - though most (all?) of it could be automatically checked. I think some could be automatically added (e.g. set -o nounset) - perhaps a bash-subset (or coffeescript-style language) possible...

notfoss• 12 years ago

I have had good results with Syntastic for Vim. Running

    :SyntasticInfo

lists 'sh' as the linting program for bash scripts.

curiousbiped2• 12 years ago

Try out shellcheck - there's an online checker at http://www.shellcheck.net/, and if you like it, the source for it is on github at https://github.com/koalaman/shellcheck.

njharman• 12 years ago

> This will take care of two very common errors: > Referencing undefined variables (which default to "") > Ignoring failing commands

Better is subjective... About half my scripts depend on those features. For default arguments, and fail early.

skywhopper2• 12 years ago

He's advocating fail early with "set -e". And as for the other, you can allow overrides with syntax like:

    COULD_BE_SET=${COULD_BE_SET:altvalue}

Karunamon• 12 years ago

Try moving all bash code into functions leaving only global variable/constant definitions and a call to “main” at the top-level.

One of my main complaints with bash.. the file is evaluated in order - you can't call a function on the line before it's declared.

This fails:

    #!/usr/bin/env bash
    bar='bar'
    foofunction

    foofunction(){
      echo 'foo'
      echo $bar
    }

Basically you have to write your entire script in reverse, and i'm unaware of a good way to get around it.

14113• 12 years ago

C is the same, but at least with C it's possible to declare functions before providing definitions. Is it possible that it's the same in bash?

xrt• 12 years ago

I really hate writing things in reverse, but a decent style in Bash is to put everything in functions, w/ a main() at the top:

    #! /usr/bin/env bash
    set -e -u
    bar='bar'
    
    main() {
      foofunction
    }
    
    foofunction() {
      echo 'foo'
      echo $bar
    }

    main "$@"

nfoz2• 12 years ago

Well, what would you do instead? It's an interpreted language. When you type "foofunction" at a prompt, you don't want it to wait around in case you define that to have meaning later.

You probably want the interpreter to be smart: "Am I loading a script from a file, or am I receiving instructions interactively on the command-line?" But now there's two modes of execution, and code in a bash script won't work if you type it into the prompt yourself. That's a bit uncomfortable.

knyt• 12 years ago

The author uses ${} a lot more than I see in most code. Is it helpful to always use the ${var} syntax instead of simply writing $var?

I can see universal application of ${} being advantageous in avoiding accidental "$foo_bar where you meant ${foo}_bar" situations, and ${} makes it clearer that you're referencing a variable. The only cost would seem to be more typing.

celebril• 12 years ago

Or you can just use Zsh, which is superior in any way to Bash. ;)

vacri3• 12 years ago

Except existing deployment spread :)

Better bash in 15 minutes

Related Stories