I have a script that works okay on my dev server but when I try to run it in production doesn't work.
I'm getting the following error which I can't figure out:
./test.sh: line 5: UID: readonly variable
Any suggestions?
#!/bin/sh
while read inputline
do
UID="$(echo $inputline | cut -d '"' -f4)"
PASSWORD="$(echo $inputline | cut -d '"' -f8)"
FIRST="$(echo $inputline | cut -d '"' -f6 | cut -d ' ' -f1)"
LAST="$(echo $inputline | cut -d '"' -f6 | cut -d ' ' -f2)"
zmprov createAccount $UID $PASSWORD displayName "$FIRST $LAST" givenName $FIRST sn $LAST
done < company.csv
It's a good idea to use lowercase variables in your shell scripts, as uppercase variables are usually reserved for shell internals. (Environment variables are an exception to this, but should really be treated the same way, as things with special meanings that you shouldn't arbitrarily change without understanding what you're doing.) In this case,
bash
sets$UID
to the Unix uid it's running under, and won't allow it to be changed or the variable to be used for anything else. Shells other thanbash
(sh
may bedash
or some other shell on some platforms) may not use$UID
that way, and ifbash
was built to work in Bourne shell compatibility mode when invoked assh
(which is the default, but many Linux distributions disable that) it won't treat$UID
as special either.UID
is a system reserved variable with information about the user id your script is running as. You should be careful not to use standard variable names that the system might be using. You can useenv
to get a list of what is currently set. Don't change any of those. You might also google variable names to see if they turn up in other users before you go ahead with them.In this case, using lower case will probably fix your problem since only the upper case variants are reserved, but you could also make your variables unique by calling them something like $input_uid so it's clear that value came from input to the script. This will make your code easier to maintain in the long run.