BASH脚本-测试年龄和压缩文件

首先是一些背景。我们有一个供应商应用程序，它生成日志和配置文件，并将它们存储在一组特定的文件夹中。然后，它将在预定的时间量之后自己记录gzip日志

我们使用备份服务器上的脚本定期（至少每天一次）将这些文件夹同步到备份服务器。为了减少空间，我们运行另一个脚本来gzip任何30天未修改的文件。这会导致一个问题，因为最终源服务器将运行其rsync并向备份服务器发送*.gz文件。因为我们将同时拥有旧的明文文件和新的GZ文件的副本，所以当压缩脚本运行时，它会试图覆盖.GZ文件。这将创建一个竞争条件

我正在编写下面的代码片段来修复它。这是我的测试脚本

#!/bin/bash

#Array of local directories
localDirs=("./testdir/")

#Loop through local directories
for i in "${localDirs[@]}"
        do
#Find non-gz files in current local dir
        for FILE in `ls --hide=*.gz $i`;
#If the file doesn't have a matching .gz file, compress it
                do if [ ! -f ${FILE}.gz ]
                        then
                        echo "$FILE: Gzip doesn't exist"
                        echo compressing $file
#test to make sure that the file is 30 days old, and if it is, gzip
                        #find $i$FILE -type f -mtime 30 -exec gzip {} \;
                fi
                done
        done
exit

这不起作用-它似乎仍然列出了目录中的每个文件，不管它是否有gzip对应物。如果您对代码有任何其他建议，我将不胜感激，因为我还是一个BASH新手

编辑：

已根据建议对此代码进行了修改（不知道反勾号已被弃用！）：

我创建了一个名为./testdir/oldfile.txt的文件，还有一个名为./testdir/oldfile.txt.gzip的文件。它仍然尝试将./testdir/oldfile.txt压缩为./testdir/oldfile.txt.gzip。奇怪的是，如果我删除压缩文本，echos将不会显示列出的旧文件，因为它有一个对应的.gzip文件。但它仍然想压缩它。不确定是什么导致了这种行为

以下是输出（compress语句被注释掉）：

以下是保留compress语句的输出：

[logsync@baschinfs01 ~]$ ls -lah testdir
total 12K
drwxr-x--- 2 logsync logsync 4.0K Dec  7 17:18 .
drwxr-x--- 5 logsync logsync 4.0K Dec  7 17:35 ..
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 cat
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 dog
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 duck
-rw-r----- 1 logsync logsync    0 Nov  7 12:21 oldfile.txt
-rw-r----- 1 logsync logsync   32 Nov  7 12:21 oldfile.txt.gz
-rw-r----- 1 logsync logsync    0 Dec  7 16:12 testfile
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 testfile2
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 testfile2.gz
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 testfile3
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 testfile3.gz
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 testfile4.gz
-rw-r----- 1 logsync logsync    0 Dec  7 16:13 testfile5
-rw-r----- 1 logsync logsync    0 Dec  7 16:12 testfile.gz
[logsync@baschinfs01 ~]$ ./test.sh 
./testdir/: Gzip doesn't exist
compressing ./testdir/
gzip: ./testdir/oldfile.txt.gz already exists; do you wish to overwrite (y or n)? n
        not overwritten
gzip: ./testdir/oldfile.txt.gz already has .gz suffix -- unchanged
./testdir/duck: Gzip doesn't exist
compressing ./testdir/duck
./testdir/dog: Gzip doesn't exist
compressing ./testdir/dog
./testdir/testfile5: Gzip doesn't exist
compressing ./testdir/testfile5
./testdir/cat: Gzip doesn't exist
compressing ./testdir/cat
[logsync@baschinfs01 ~]$

正如您所见，它仍在尝试压缩文件，即使IF条件中的其余语句被忽略

编辑#2：终于让它和一些黑客一起工作了。下面是最后一段被导入脚本的代码（直到我找到更好的方法为止）：

---

这是在我的测试用例中测试和工作的。希望它能顺利地融入到主脚本中。谢谢大家的帮助

在最终代码中编辑。正如我在评论中提到的，依赖find会引发一些问题。根据它所做的工作，看起来gzip试图gzip目录中的每个文件，而它将./testdir/视为列表中的一个项目。这避免了现在总是使用filemtime和当前日期的情况。

第一次编辑中的find命令忽略了之前的测试，而只是压缩任何file（-type f）类型的文件和30分钟前修改的文件

find $FILE -type f -mtime 30 -exec gzip {} \;

与注释2类似，您可以执行以下操作

find $FILE -type f -not -name '*.gz' -mtime 30 -exec gzip {} \;

请记住，即使文件扩展名不是gzip，也可以对其进行压缩

luis@linux:~> gzip -c talk.tmp > talk
luis@linux:~> file talk
talk: gzip compressed data, was "talk.tmp", from Unix, last modified: Mon Oct  7 15:07:10 2013

---

rsync--exclude=“*.gz”如何？替换。。。在$（find.！-name“*.gz”）？+1个很好的问题，格式很好，在发布前展示了一些研究成果

以$（find..）表示f

是个好主意。但是为了解决前面提到的问题，您是说如果您从命令行运行

ls--hide=*.gz$i

（使用$i的适当值），它在那里工作，但在for循环中不工作？我打赌它在命令行上也不起作用。作为一种单独的咆哮，早在1995年就被弃用的反报价，为什么人们继续使用它们！；-）使用$（…）并从此幸福地生活！诚实的祝你好运。现在我怀疑你的

查找$FILE…

。找到的第一个参数通常是路径名，而不是文件名。同样，在为变量替换合适的值后，确保这会产生您期望的输出。祝你好运。另外，你说了“（gzip的默认值是filename.ext.gzip）”。您确定吗，您的所有代码和示例都显示了.gz，这就是我认为的默认gzip fileExt。还是说filename.ext.gz？如果您真的要使用exts.gzip获取文件，那么可以添加到代码中来处理这种可能性，或者构建一个脚本，将这种不一致性作为批处理过程进行修复，与此脚本分离。祝你好运

find $FILE -type f -mtime 30 -exec gzip {} \;

find $FILE -type f -not -name '*.gz' -mtime 30 -exec gzip {} \;

luis@linux:~> gzip -c talk.tmp > talk
luis@linux:~> file talk
talk: gzip compressed data, was "talk.tmp", from Unix, last modified: Mon Oct  7 15:07:10 2013