0

I came into an environment were when users log into our system, they log in with the csh by default. We also have an automation login (let's call it "autologin") that also invokes the csh by default.

This login in used to execute (via its crontab) all of our scripts (50+) used to send and receive files with our vendors. The results of these individual file transmissions are used to feed a dashboard for each transmission.

The dashboard simply has a light for each file transmission (green light if the last file transmission was successful and red if it failed). This success/fail status is set (in a SQL Server database) from the scripts, using a tsql -H connection.

We are currently using SQL Server 2008, but are upgrading to 2016. So I need to change are 50+ scripts' tsql connection from sql_2008 to sql_2016. I had the idea to use an environment variable (let's say AUTOSQL) that could use.

I could then change all of the 50+ scripts to reference AUTOSQL, instead of sql_2008, and then set the environment variable to sql_2008/sql_2016/and whatever we upgrade to in the future. As I previously mentioned, all users log in with csh as the default shell. The problem I've encountered is all of the shell scripts are written in bash.

How can I set up an environment variable for the bash (our automation) scripts to use, so when we upgrade in the future, I simply have to change the value of one environment variable, instead of changes to 50+ scripts? Thank you

RSteffy
  • 1
  • 2
  • Is this Windows or macOS or Linux? Is it one server or some network of servers or some nasty Active Directory thing? – Mark Setchell Aug 09 '19 at 18:16
  • Update your bash scripts to take parameters, `$1` being the first one on the command line. Invoke with `bash script.bash sql_xxx`. – bishop Aug 09 '19 at 18:16
  • 1
    The environment (at least in a POSIX environment like Unix of macOS) is just a list of strings of the form `NAME=VALUE` that every *process* (shell or not) inherits from its parent (again, shell or not). They are called environment variables because shells typically expose them as automatically defined shell variables. – chepner Aug 09 '19 at 18:17
  • (That is, whether you execute `setenv foo bar` in `csh` or `export foo=bar` in `bash`, the end result is the string `foo=bar` in the environment.) – chepner Aug 09 '19 at 18:39

2 Answers2

1

Environment-variables are an operating system feature that is "application agnostic". In Unix-like environments, any kind of program can pass environment variables to any other, that is its child.

The real issue here is that the fifty scripts are run by cron from a crontab file. This means that they will not inherit the AUTOSQL variable, even if it is exported by the csh login script.

See:

Where can I set environment variables that crontab will use?

Also, on the ServerFault StackExchange:

https://serverfault.com/questions/337631/crontab-execution-doesnt-have-the-same-environment-variables-as-executing-user

Kaz
  • 55,781
  • 9
  • 100
  • 149
0

It's great to see someone simplifying and consolidating their scripts.

If all these scripts are executed in cron (by root), /root is the first place I'd look.

Step 1:

Choice A.) Set and export AUTOSQL in root's .profile

Choice B.) Set and export AUTOSQL in root's .bashrc

Choice C.) Set and export AUTOSQL in root's (whatever you wanna call the file)

export AUTOSQL='sql_{year}'

Step 2:

Make sure you source this file at the top of your scripts. From now on, you can add environment switches at will to this file, since all of your scripts will source it.

. /root/.{bashrc || profile || whatever you decide to name the file}

Hope this helped! Again, the decision is yours.

Ben Van Camp
  • 136
  • 3