Click here to Skip to main content
15,881,172 members
Articles / Operating Systems / Linux

LINUX: Scripts and Alias

Rate me:
Please Sign up or sign in to vote.
4.00/5 (1 vote)
18 Aug 2010CPOL3 min read 12.3K   3  
Scripts and Alias in Linux


This one stumped me for a while; we had build scripts that kept failing, yet if you manually executed the commands from the script, everything worked fine. Eventually I discovered that it wasn't properly executing the "make" command as was setup in the alias. When we set up our build environment, we alias "make" to have a bunch of compiler flags so when you finish running the setupenv file (to set environment variables and such), all you have to do is run "make" and the alias keeps track of all the necessary build flags.

Scripts never work properly because they interpret your "make" command to be just that--"make" with no build flags. It turns out this is because scripts (non-interactive shells):

  1. don't expand aliases and
  2. don't bring in the current environment

Concerning point 2 about the current environment: This is actually a good thing. Imagine if you have a special environment you set up and the script runs fine in your area, then someone else tries to run it in theirs and it fails. It would be a pain to begin debugging by comparing what is in your .bashrc file and what you did to customize your environment. A script should be self contained, able to run in any environment. So when you run it, it doesn't carry over your environment variables into its non-interactive subshell that it runs in.

We are more concerned with point 1 though: A shell script, at least on all the Fedora and RedHat servers I've worked on, do not expand the aliases by default. Before I came across the good solution on the internet, I hacked together my own solution of parsing the expanded command out of the alias output:

`alias | grep make | cut -d\' -f2`

That works, but is not an elegant solution by any means. Recently a coworker was having trouble with a build script and I got into explaining to him he may have a problem with a non-expanding alias. I showed him my solution and then gave the caveat that there is probably a better, easier solution out there. Then I looked for one and found it (don't ask me why I didn't find it the first time when I created my hack solution). Just place the following command in the beginning of your shell script:

shopt -s expand_aliases

What this does is sets the shell option (shopt) to enable (-s) the expansion of aliases (expand_aliases). The main page says that this option is enabled by default for interactive shells, so the implication (and reality we've witnessed) is that it is disabled by default for non-interactive shells.

If you want to see this in action, try this script:

Bash
#!/bin/bash
alias testme="echo It Worked"
alias
testme

The result will print the new alias you assigned (typing alias in line 3 prints out current aliases) for testme. Notice there are no other aliases set, not even the ones that are set globally for the system. The execution of the testme command fails with "command not found" because it is not recognizing the alias.

Now try again with the shopt set:

Bash
#!/bin/bash
shopt -s expand_aliases
alias testme="echo It Worked"
alias
testme

Now it will work perfectly, showing the alias we set and echoing the "It Worked" statement.

This article was originally posted at http://www.chiefsandendians.com/feeds/posts/default

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Chief Technology Officer Chiefs And Endians
United States United States
Come visit us at http://www.chiefsandendians.com

A compilation of varied technical gems learned over many years of experience in the industry.

Hint for the confused: Endian is a Computer Science term--the title is a play on words, not a misspelling.

Comments and Discussions

 
-- There are no messages in this forum --