Gunzip & wildcards not working inside bash script

[st44985753]

I'm new to Linux and would appreciate any help.

I have a bash script that includes the line below. By the time the script gets to this line, it's already working from the same directory as the .gz file.

/bin/gunzip -k < *.gz | /usr/bin/mysql -u root -p"************" sites

With the above, I keep getting a "file not found" error for the *.gz file. But when I change it to the full file name below, it works:

/bin/gunzip -k < backup_2021-01-16-0915_sitename_c1c565464574-db.gz | /usr/bin/mysql -u root -p"************" sites

I'd really like to use the wildcard so I don't have to edit the bash script with the latest file name every time I run it.

Any ideas why the wildcard isn't working?

Thanks!

 

[BlakeF]

make sure you have the following line as the very first line in your script to specify the shell environment.

#!/bin/bash

 

[JasKinasis]

@st44985753 :
So what you're doing there is using input redirection to redirect the file into gunzip, which will cause it to extract the file to stdout. Then you're piping it to mysql and running whatever commands are in the file? Is this correct?

Are you only ever using one .gz file? or is it possible that there will be several .gz files there?

Because you are using input redirection, if there is more than one .gz fiile, you will end up with an error about an ambiguous redirect.
But if you only have one file - the pattern *.gz should be sufficient enough for it to be able to find that file and the command should work.
So I don't think you'll get an error from gunzip about "*.gz" not existing.

I haven't used mysql in a very long time, but I don't think mysql will yield an error about *.gz not existing either because the content of the file is directly piped to it, so it won't receive the filename, just the unzipped contents of the file.... So that's weird!

If you have more than one .gz, you can redirect all of them at once like this:

gunzip -k < <(cat *.gz) | mysql -u root -p "************" sites

That should unzip ALL of the .gz files in the current directory and pipe them to mysql in one go.

Alternatively, perhaps consider using a loop and processing them one at a time?:

for file in *.gz ; do
    gunzip -k < "$file" | mysql -u root -p "************" sites
done

Hopefully one of these solutions will help!
If not, give a few more details about what you're trying to do and I'll see what I can come up with.

 

[st44985753]

make sure you have the following line as the very first line in your script to specify the shell environment.

#!/bin/bash

Thanks. I currently have #!/bin/sh and will try this.

 

[st44985753]

@st44985753 :
So what you're doing there is using input redirection to redirect the file into gunzip, which will cause it to extract the file to stdout. Then you're piping it to mysql and running whatever commands are in the file? Is this correct?

Thanks for all this! You're right—the script looks in a directory for a mysql backup file in .gz format and then imports it into MySQL. (I import the unzipped .gz file, as MySQL reports database errors if I import the unzipped db file even via PHPMyAdmin—it always works with the .gz, though).

It is the only .gz file in that directory so I can write the script based on that. I was playing around with it the other day and was able to get it to work with this modified code (with the start of the script still being #!/bin/sh):

backuppath=/my/backup/path
sqlfiles=$backuppath/*.gz
gzfile=$(echo $sqlfiles)
/bin/gunzip -k < $gzfile | /usr/bin/mysql -u root -p"mypassword" mydbname

It seems a little clunky, but it does seem to work. I had tried it this way, as I remembered that it worked on my Mac when I was passing the path-to-the-file as a variable into gunzip, rather than spelling out the path and wildcard on the same line as the gunzip command.

Out of curiosity, is there anything else in the new code that explains why this works with gunzip rather than my first attempt when it's invoked on the same line? Is it possible it relates to a sh vs bash difference per @BlakeF?

Thanks again for your help with this!