Global variables in shell scripts
 

I am not sure how to word this. Let's say I write a lot of shell scripts for my Macs at work and I want to set up an array of global variables that any script can call, outside of the script. Eample:

$1 = current user

$2 = name of start up volume

$3 = computer name

$4 = current IP address of the NIC


You get the point? How would one go about accomplishing such a thing? Run all scripts through a framework?

#Edit#

I guess I could maybe alter the profiles for every user for bash and set functions and aliases and variables in the bash profile and then whenever that user runs a script, they could call those variables....

The easiest (and probably best) way is to define those variables in a script that is then 'source'd by the other scripts.

globalVariables.sh
otherScript.sh

Hayne,

As always you are right on the money. My top google hits pretty much returned what you posted. Thanks as always.

Don't use bash for such simple tasks. Use the 'standard' bourne shell (/bin/sh).

Current user is already defined with $USER. So is the computername; $HOST.

I always use bash, as it is the default shell and has all functionality of shell. If you can please explain to me why I should use shell over bash I'd be glad to hear it.

Also, sometimes a script will run as root, so I need to figure out what the current user is. My method is seeing who currently owns the console, since the currently logged in user should always own the console.

This will return the current user, if I just use $USER it will return root if my script is running as root.

I'd be interested to hear more about why you recommend that.
(I'm assuming that the scripts are for OS X only, so availability of 'bash' (e.g. on older hardware) is not an issue.)

By the way, note that on OS X, 'sh' is just 'bash' invoked under another name.

Bash is slow compared to sh. Also /bin/sh is a POSIX shell. If you write a script in bourne shell it will run on pretty much every *nix flavor under the sun.

That will be root, as the script runs as root.

There's no notion of "current user". Unix is a multi-user system and so is OS-X. There can be multiple users logged in at the same time.

I'd be very interested to see some numbers showing this (on OS X).
See my comment above about 'bash' and 'sh' being essentially the same program on OS X.

But there is still only one user who has access to the graphical facilities of OS X - the user who is sitting in front of the Mac.

On Linux it is. /bin/sh is actually hardlinked to /bin/bash. On *BSD it certainly isn't. Not sure about OS-X though.

Still, I would use the bourne syntax. I've seen to many scripts riddled with bashisms that people try to run on systems that only have the 'regular' bourne shell.

It's easier to learn new things then it is to unlearn bad habbits :D

I used to agree.
But nowadays I don't think there are many people who care about any Unix system other than OS X and Linux.

I have BSD 8, Ubuntu 9, Fedora 10, OS X, and open SuSe at home. All of them by default use /bin/bash as the default shell. I just recently bought a few books on bash, and the books all tell me, that bash has full functionality of shell, and in most cases works both ways. With some exceptions where bash is more functional than bourne shell.

I looked around, and the only other shell I can see that is close to being as widely used as bash seems to be korn. I don't know all the differences of the shell because I haven't extensively used them all. In the current O'Reilly book I am reading, which is all about bash 3.0. The first chapter states that bash takes all the good things from c shell, korn, and bourne shell, and combines them with other robust features to create bash.

Also, there are many global variables I could use while scripting. If I want to invoke say the defaults write command on a script to modify a property list, I need to do so as the user, not as root, because that will just modify the root user. So, I could hard code these global variables to get a list of all user accounts, and then loop it to modify that plist. That is just one small tiny example.

Not to mention, this is my enterprise, these are my organizations systems with the image I created. So, setting up a series of global variables may be very beneficial for me from a systems management view. Also, everything is standard, so I know what is going on and I know by default every shell is set to bash.

Thanks for your time guys, it is always appreciated.

FreeBSD does NOT and never has bash as the default shell. It's not even part of the base OS.

Look more closely. All startup (init) scripts on AIX, Solaris, HP-UX, BSD and quite a few others use the bourne shell (that's /bin/sh) not bash.

Great, this means more work for me as I can work with AIX, HP-UX, Solaris and *BSD. It also means I can increase my rates :D

That alone tells us all we need to know: for Linux bash is the shell of choice... and that hard link:

1. saves folks the trouble of having to change (rewrite/save) every silly script that has #!/bin/sh into #!/bin/bash
   
   Remember: bash is designed to be fully backwards compatible and able to run any sh script, but sh OTOH does not make that claim (about bash). Essentially, bash replaces sh... not vice versa.
   
   
2. forces every script that even tries to run sh to actually call bash.

So the notion that folks 'should' prefer sh is false... or, only true if we want our scripts to run on machines which have no bash binary. (safe to say: Mac users need not have that care).

sh is an ancient relic too old to be concerned about, and bash offers too many improvements to ignore.

It's just as old as Unix. Maybe we should forget about that too?

And you're completely missing the point. But that seems to happen a lot on this board :rolleyes:

No, we get your point - some people disagree.


Got some benchmarks to support this? Speed of a simple shell script on a multi-gigahertz machine really isn't a big issue anymore. If sh runs my script 0.0003 sec faster than bash I probably won't notice, and I'm definitely not boning up on another language for it.

I write ~80% of my maintenance scripts in PHP anyway.

Sure can be, but only one has the Desktop, and only one will be listed in /dev/console

What Hayne said. In Leopard, /bin/sh and /bin/bash are nearly identical in size (32 bytes difference) so it really smells like the same codebase.

Sounds like someone needs to update their base OS. I see that as a defect, not a feature.

Which tells me they were written (and re-written) by people more familiar with sh. Or the script is a legacy item from the days when sh did things better.

The original question was for OSX scripts, and bash is omnipresent, so no problem.

Fair enough.

I look for it. Don't have one handy. But I do know the differences are a lot more significant then that.

True. But the naming "current user" isn't correct and can lead to misunderstandings.

Then I'm wondering why they didn't take the linux route and just symling /bin/sh to /bin/bash. One codebase instead of two.

Why? It works perfectly fine with the bourne shell. For interactive use we have (t)csh. And if you really must you can always install korn, bash, zsh and quite a few others as a port. Why clutter up the base? Also bash is GPL and thus cannot be added to the base (BSD Licensed).

Init scripts have been around for as long as Unix has been around. Those scripts aren't going to be re-written in another shell.

Hey, it's your system. I just think learning bourne will benefit you more. Maybe it's because I use and maintain more different flavors of *nix.

Bash is an excellent replacement for sh, because that was the precise purpose of its design. If you know about something that replaces all of "Unix" with as much precision and inherent *backwards* compatibility -- please share.


Perhaps because this is a Mac OSX-oriented board, and thus caters to an audience to which your "point" was less significant.

;)

Seriously though: over the years, Bash has borrowed little bits here and there from zsh (and Perl?), and those enhancements are becoming (have become?) the 'norm' now. Bash *is* the new sh. I don't think anyone here is worried about running their scripts on a PDP-11.

:D

Sorry i didn't catch this last night (perhaps since it's part of a reply to someone else, i just skipped it before):

Learning sh more beneficial than learning Bash? :confused:

Two things about that...

• Bash is an extension of sh -- or viewed from another angle, sh is a subset of bash. Learning bash is learning sh... plus a few enhancements.
  
  
• i count a total of 15 instances of the string “bourne” so far, and not one of them has been capitalized (to honor Steve Bourne).

Good Sir Dice, may i suggest it's not too late to be Bourne again. :)

well back on topic....

So, when I set up my commands, and then source it, it does not seem to be working. What is the best method? Can I literally just put 1=`some commands` and then echo $1 or call for $1 in a script sourced to my global variables?

Thanks

So for example, I am looking at using functions, but not sure how to output them to numbered variables...

I just can't quite wrap my head to output that code so that it equals $1, and then when I source it in a script I can just use $1 and it will always pull the currently logged in user.

As usual when asking about a problem, you need to supply details of what happens and why this is not what you want.

I don't think "1" is an allowable variable name. $1, $2, etc are special variables that get set to the command-line arguments of a script.

Well, certain things get parsed at log in with hard coded variables in OS X, so when a script runs as a log in hook, $1 is always something, $2 is always something, so I was assuming that login hooks sourced some commands which output the desired result to $1.

So, in my case, if I sourced my global variables, and say the currently logged in user is output to $1 I could do this in a script

defaults write /Users/$1/Library/Preferences/com.mycompany "some_options" -bool true

I think I want to build functions, but just not sure how to set them to certain variables. I know some third party stuff also uses $1, $2, $3 at log in to utilize certain hard coded variables.

Sorry if I am not making much sense

Third party stuff does not set $1, $2, etc to values - as I said before, those values come from the command-line args used when the script was invoked.

I'm not sure what you are missing - i.e. why the sort of example (with suggested variable names) I gave above is not what you want.

Well, in the specific example I gave, parameters do get passed to $1, $2, and $3 by third party framework, but only at login. I assume that is because they modified the existing Apple stuff when running scripts as log in hooks.

I guess, I don't have to output it to a number, but I was thinking it may be easiest that way.

Thanks

Your use of the word "framework" makes me think that you are talking about shell scripts invoked from a compiled program (e.g. one written in C). In that case, the compiled program specifies what command-line arguments it wants the shell script to receive. And then Bash sets $1, $2, etc to those command-line arguments.

That very well could be what it is

It sure seemed that post#2 (hayne) covered it pretty well. Observe how "numbers" (positional parameters) are not connected to "global variables" through any special relationship.

From post #2:
Note how otherScript.sh echos some variable called "computerName" seemingly out of nowhere? It didn't declare or initialize it anywhere. Where did it come from? Did you test out his two files to understand how they work?


If you want "numbered" variables, i'll show you how it can be done (but usually there are reasons for doing this... which probably don't apply here). Note: in bash, a period '.' (as a command) is the same as the "source" builtin...

# SHELL SCRIPT:
$ cat foo
Note how (like hayne's post #2 example) that foo prints out 3 variables without ever declaring or initializing them. Here's the hidden config file it sources to get the data...

# CONFIG FILE:
$ cat .myConfigs
. . .

And, here is what it looks like when it's run:
Try it out, and then decide. [i don't think reassigning the number variables offers any advantage here.]

BTW...
Functions also get assigned their own positional parameters (arg list), so that adds even more to the potential confusion. The body of a script gets its numbered variables and functions get whatever args we call them with.

I was thinking I could pass a bunch of arguments to a function and then just call that function in a script. I could, case things for different OS versions and what not. Though, this is getting slightly above my skill level, but I am willing to learn.

I just think numbers would be easier than word variables, but then again as long as I am writing everything I can kind of do it how I want. I was thinking more along the lines of setting this up, so when other people in my department need to write a script they can call global variables for simple one liners instead of hashing everything out.

Thanks

Still using my foo script from post #27, perhaps this run (including some args on the command line this time) will better illustrate what's happening: