Again and again I am confronted with this wide-spread coding style
Instead of
I see
Who teaches this?
Isn't this harder to type & harder to read & harder to port to another OS?
Another observation: these variables are ALWAYS UPPERCASE. I have never seen them lowercase.
So maybe it is from an old book, from the CP/M era?
Most useless seems
Why?
Is searching the PATH for each command too resource intensive?
Doesn't the shell have a hash table?

Where is this widely spread? That looks a little ridiculous to me and unlike anything I've ever seen.

It's almost like the person writing it expects what they're doing to be more portable, by, uhh, hardcoding the paths in. Okay, maybe not. My only other guess is that they saw some distant day when they would, perhaps, have a better version of `cut` to sub in? Who knows.

Though, uppercase globals isn't too crazy. Lots of people do that in all sorts of languages. I do it, too.

Edit: Well, I guess I don't know what I know anymore. In the other thread szboardstretcher posted a link to a bunch of their shell functions and they do indeed a similar style to the OP: https://paste.ubuntu.com/23639585/ So maybe there's a good reason for it.

I don't argue with using uppercase shell variables in general.
While I still follow the UNIX convention

• environment variables = uppercase
• shell variables = lowercase

I googled this because my reaction was lolwut?

The only result I got was this one:

http://stackoverflow.com/a/795540

If that poster is to believed, then the pattern is actually supposed to be:

Where commands.sh might define $GREP as "grep -E" or "egrep" or whatever, depending on the system you're on, with the point being to get consistent behavior across different Unixes.

a little reading goes a long way.

3.2. Variables

http://linuxcommand.org/

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html

Perhaps it's following typical Makefile style?

I can probably follow the use if it were for something like cron where often the full path is required to know where a command is.

i have also played with my own package management system which did utilise the sourcing of files, as per dugan's example, to have executables with the switches needed for each command

I am also a +1 to the variable format listed by MadeInGermany

specifying the full path is ok, that has some benefits:
in a production environment (where several people do the same build) PATH may contain local, user specific settings, but the build process itself will use the hardcoded "default" path. It is safer, more secure, and probably a bit faster too (you can also specify default flags). By using these variables you will be able to switch/replace a command with a similar, other one without knowing where it is really used.

For a personal, single user environment it is not really important.

to the variable format: using sed (as real command) and $sed (as a variable) too can be confusing and hard to recognize the difference (a missing $). That's why upcase can be suggested. Constructing new functions may not lead to such confusion, therefore lowercase function names are ok.

1 members found this post helpful.

And who told you to use /path/to/cmd instead of PATH= and cmd?
Both eliminate individual user PATHs.

1 members found this post helpful.

There are cases where commands in variables make sense within the immediate scope, but as a kind of default environment setting method/style I find it much less satisfying.

...and thus potentially break many more downstream uses in the process than you will ever know, what fun!

That works in make files (build environment), but I think it is much less desirable in shell script code (executable environment), especially when you don't know where/how/by-whom it may really be used!

I agree with others that if the actual point is to enforce a default PATH, then set the PATH environment variable in the desired scope.

If the point is to set command options for use by as yet unknown or to-be-written future scripts, that leaves me with an uneasy feeling. Leave the optional behavior choices to the script writers who have full awareness of the use case at the time of writing, and who may rely on the actual default behaviors of the commands.

Agreed. In any case that you must define a command in a variable of same name, upper-case it if only for this reason! But I think I would never define a command variable of same name outside possibly a make file!

using explicit path (= using full/absolute path) sometimes faster, especially when PATH is too long. And also you can use commands "outside" of your PATH without configuration, without increasing your PATH.
Also you may have several tools with the same name (two or more different python/perl/make/whatever available), and probably you want to use the specified version from a given directory. Relying on PATH probably won't work as expected.
Based on my own practice: using well defined commands may avoid some very strange, tricky and unpredictable errors.

I often see uppercase names to clarify, it's local to the script.
This was used in KSH and Bourne as well.
It's so the variable never gets interpreted as a system command.

As for the hard coded path. You may never see it on your own local PC, however,
when you are working in a large system environment, directories are often symlinked to hell
due to network routing. Explicit paths can make a script fly, as having to resolve its path every single time.

Often times, the latest bins are in a disted share, these may be specialized (bastardized) versions of the utilities customized for internal use (kerberized). These are often a restricted form of the command. The joys of working with SoD (Separation of Duties) where NO Dev shall ever touch a PROD space ever again, without applying for Permission from Production Operations.

Once case, when we migrated from RHEL4 to RHEL6, we found KSH had been update SO much in RHEL6, it broke hundreds of scripts. Some opted to use the KSH93 link, and others opted to fix the scripts to use KSH2010.

Another example, the lftp or ssh commands being updated to work with Kerberos libraries. The /bin/ssh won't work on machines, because it will no longer negotiate. So we are forced to hardcode to the disted version in order for the scripts to work properly.

These are cases where `which ssh` would fail miserably.

In the real world, which plays nice an works most of the time. Unless you want or need to use special versions, then the only method is hardcoding to ensure you are using the correct one.



Regards
Rich

If a coding style is not a convention between several people, it has no right of existence. Otherwise, two distinct groups do as they please or discuss a consensus to help organize a joined programming effort.

*I* got rid of many dumb restrictions by quitting professional software-development. Now *I* enjoy my 1 and only coding style which may adapt to the language currently used, or will just be the same with any of them. *I* use upper-case for constants (and do not care about bash, nor the environment), i.e. variables that *I* consider constant.

Should I ever have to hand my code to someone else, we can discuss again. But the presupposition of teamwork or development in communities must be pronounced before a discussion of coding-styles makes any sense. The way it is imposed on us from time to time is not even constructive. Maybe I live in France for too long, already, but then say so. In German, we do not have two words for Liberty and Freedom, which is a handicap sometimes and has, probably, contributed to the way that coding-styles are advocated (not “applied”), nowadays.

Frohe Weihnachten, Ihr Nasen.