Is My Computer Broken?

carlarogers

Member
Joined
Jan 1, 2020
Messages
58
Reaction score
10
Credits
527
I cannot understand this behavior that comes up at the end of a sequence that makes sense until this happens. The server seems to assign a value from no where.

I know this looks like a lot of stuff, but it is pretty simple. I am forming commands, putting them into a file to run, but then a value shows up from now where , as if I entered the name of a zipped file for a db instead of just the db name.

Debian 10 web server, with LAMP. My goal is to make a script to load databases and create the user accounts that goes with them, to save time and improve accuracy. I work in an environment that allows one and only one account per mysql (mareiadb) database. So we give the account and the DB the same name to keep it simploer.

Starting with a db dump from another server, delivered to me in gzip format.

That db dump comes in as dadc.sql.gz Here is my script. It all runs great until the very end.

Code:
#To run this script, enter
#load_rm 'dbname' 'password' name of the db is the one t comes with.  Password is up to you

# formulate commands to run in mariadb or mysql, put the commands into a file,
# then submit the file for processing
zcmd_file="sql.sql"
rm $zcmd_file  #delete old files from previous runs if they are not already deleted.
zcall_mysql="mysql -u admin -p`cat /home/carla/db/password`"  #admin password saved in my home directory at db/password

zcmd="drop database if exists "${1}";"
echo $zcmd > $zcmd_file  #now the first command is in a file that can be submitted with bash

zcmd="CREATE DATABASE "$1" CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"
echo $zcmd >> $zcmd_file  #2nd command loaded to file

$zcall_mysql < $zcmd_file  # this submits the file to mysql/mariadb and its commands process as expected

# next line unzips the db and loads it into the new, empty database created n the previous steps.
gunzip < ${1}.sql.gz | $zcall_mysql $1

# so far so good

zcmd="DROP USER IF EXISTS "$1
echo $zcmd > $zcmd_file  # start loading the rest of the commands into the file.  Using one > causes the file to be blanked out before loading new commands.

zcmd="DROP USER IF EXISTS "$1
echo $zcmd > $zcmd_file  # start loading the rest of the commands into the file.  Using one > causes the file to be blanked out before loading new commands.

$zcall_mysql < $zcmd_file  # run one command, due to problem about to show up

zcmd="create USER '"${1}"'@'localhost' IDENTIFIED BY '"${2}"';"
echo $zcmd > $zcmd_file  # runs ok

$zcall_mysql < $zcmd_file  # run one command, due to problem about to show up

#This is where it starts acting like there is something wrong with my computer.
zcmd="GRANT ALL PRIVILEGES ON "$1".* TO '"${1}"'@'localhost' WITH GRANT OPTION;"
echo $zcmd > $zcmd_file

$zcall_mysql < $zcmd_file  # run the command.....and the system says:
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '.gz TO 'dadc'@'localhost' WITH GRANT OPTION' at line 1

.gz???  Where is that coming from?  Looking in the file with the command that bombed:

GRANT ALL PRIVILEGES ON dadc.sql.gz TO 'dadc'@'localhost' WITH GRANT OPTION;

I cannot figure out where that dadc.sql.gz is getting in there.  To run the commands,I am always entering it like tis

load_rm 'dadc' 'password'

For a reason I do not have any knowledge of, where the script says to use the value of the first parameter ($1), it is putting in the name of archive file.

I am really wracking my brain on this one.

Thank you for taking a look,
 


A simpler explanation of the problem. I cannot form a command like this and submit it mysql.

GRANT ALL PRIVILEGES ON dadc.* TO dadc@localhost WITH GRANT OPTION;

The .* gets translated into .sql.gz

I have no idea why that happenes. I have been unabe to find a way to beat this. It is preventing this process of loading databases from being automated. I have to submit the granting of privileges separately from running the script that does everything else. This is crazyo_O:eek::oops::rolleyes::confused::mad::(
 
Hey there carla, welcome to linux.org!

It sounds like maybe you're missing a closing quote, bracket, etc.. somewhere.. have you tried pasting the script into somewhere like shellcheck?
https://www.shellcheck.net/
Thank you for responding. Lord knows I need help with this.

Great tip. Using Shell Check it was no problem fixing my script. THANK YOU!
 
Last edited:
Nice, what was it?
At first, I did not isolate the specific problem, because the checker informed me that the I was using single and double quotation marks incorrectly. As a result, there were changes throughout the script. The particular problem I was having did not seem specially relevant at that point.

Since my last post, I found out my script had been working when I posted here. The error was coming after the script had done what it was supposed to.

So I learned better scripting, then found a stupid mistake not affecting anything except making me upset.

Here is an example of what got me onto a bad road on this script. Take the following command for mysql/mariadb :

CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';

That looks to me as if single quotes are required around three terms. In addition, if you want a bash script to put that command into a file that is to be submitted to mysql/mariadb. the whole string is going to need to be inside quotes, something like:

cmd="CREATE USER 'username'@'localhost' IDENTIFIED BY 'user_password';"

Then again, why put this into a bash script unless the username and password are input parameters, that gave me:
cmd="CREATE USER '$1'@'localhost' IDENTIFIED BY '$2';"

I still am not sure, but that looked wrong to me, because I thought the single quotes around $1 would prevent the $1 from being replaced with the input, so I turned that into this:
cmd="CREATE USER '"$1"'@'localhost' IDENTIFIED BY '"$2"';"

shell check did not approve.
5305


Plus, shellcheck disagreed with the statement I had setup to submit the command file to mysql. Now, these statements were running correctly, not part of the problem I was having. But when I found that shell check's revisions worked.

Then I discovered the cause of the strange output referencing a string that seemed to be from outside the process. Several lines below the end of the script, a leftover fragment from when I was putting the script together was throwing the error after the script I had was already finished doing what it was supposed to. i didn't even know, because I thought the error message meant the script had failed!

One of the improvements by shellcheck is something I did not know is allowed. Specifically, the command above, when shellcheck was done with it, did not have single quotes around the username in that statement:
5307
 
awesome! Also, I didn't realize you can install shellcheck locally - i'm going to do that :)

Edit: I thought some of the screenshots showed that you had shellcheck installed locally... that's just the output on the site - well, i installed it locally anyway just now lol
 
Last edited:

Members online


Latest posts

Top