views:

2042

answers:

6

I run across many shell scripts with variables in all caps, and I've always thought that there is a severe misunderstanding with that. My understanding is that, by convention (and perhaps by necessity long ago), environment variables are in all-caps.

But in modern scripting environments like Bash, I have always prefered the convention of lower-case variables for temporary variables, and upper-case variables only for exported (i.e. environment) variables. For example:

#!/bin/bash
year=`date +%Y`
echo "It is $year."
export JAVA_HOME="$HOME/java"

That has always been my take on things. Are there any authoritative sources which either agree or disagree with this approach, or is it purely a matter of style?

+1  A: 

It's just a very widely held convention, I doubt there's any "authoritative" source for it.

Alnitak
+3  A: 

I do what you do. I doubt there's an authoritative source, but it seems a fairly widespread de-facto standard.

Draemon
I agree. It's because ALL_CAPS is ugly, but it's good to make ENVIRONMENT VARIABLES stand out by being ugly.
slim
I agree with you on coding style, but I definitely disagree that it's widespread! Shell scripts are one of those side languages that people just learn informally, and so I feel like everybody is always saying LOCATION=`cat /tmp/location.txt`
jhs
@jhs - I've obviously been lucky in the shell scripts I've had to work with!
Draemon
A: 

i tend use ALL_CAPS both for environment and global variables. of course, in Bash there's no real variable scope, so there's a good portion of variables used as globals (mostly settings and state tracking), and relatively few 'locals' (counters, iterators, partly-constructed strings, and temporaries)

Javier
Yes, I kind of conceptually think of non-exported variables as locals, since Bash is so often forking child processes to do whatever it's tasked with doing.
jhs
+1  A: 

The way I've always looked at it is, if the Bash environment variables are all in caps, I should export mine the say way to keep it uniform. The Bash Manual does not say that all environment variables should be in caps but the vast majority of environment variables built into bash are all in caps (the only exception I know of is $histchars).

Pierre-Luc Simard
+2  A: 

Actually, the term "environment variables" seems to be of fairly recent coinage. Kernighan and Pike in their classic book "The UNIX Programming Environment", published in 1984, speak only of "shell variables" - there is not even an entry for "environment" in the index!

anon
I think that is a omission of the book. getenv(), setenv() and environ were introduced in UNIX version 7 (1979). http://en.wikipedia.org/wiki/Version_7_Unix
Juliano
That book looks to note that upper case variables do have special meaning.
ashawley
+9  A: 

By convention, environment variables (PAGER, EDITOR, ..) and internal shell variables (SHELL, BASH_VERSION, ..) are capitalized. All other variable names should be lower case.

Remember that variable names are case-sensitive; this convention avoids accidentally overriding environmental and internal variables.

Keeping to this convention, you can rest assured that you don't need to know every environment variable used by UNIX tools or shells in order to avoid overwriting them. If it's your variable, lowercase it. If you export it, uppercase it.

lhunath
+1. Good point about accidental overwriting. I forgot to mention, but now that you mention it, I think I decided on using lowercase because I read or heard about just that problem.
jhs