Вы можете просто добавить еще один блок -exec
с командой echo
для записи в лог-файл, т.е.
find $1* -prune -name "*.$2" -mtime +$3 -exec mv {} $4 \; -exec echo mv {} $4 >> /path/to/log \;
Если вам нужно меньше информации, просто измените последний блок -exec
, например.-exec echo {} >> /path/to/log \;
Если вы также хотите зарегистрировать, была ли команда успешной или нет, вы также можете передать стандартную ошибку из команды mv
в файл журнала. Я не думаю, что гарантировано, что первый -exec
обязательно действует первым, поэтому в этом случае я бы использовал один -exec
. Н.Б. здесь синтаксис становится немного сложнее.
find $1* -prune -name "*.$2" -mtime +$3 -exec mv {} $4 \; -exec sh -c 'echo mv $1 $2 >> /path/to/log; mv $1 $2 2>> /path/to/log'. {} $4 \;
Я не уверен в вашем точном варианте использования, но рекомендуется заключать ваши переменные в кавычки, например. find "$1"* …
, если есть имена файлов с пробелами/и т.д. в них.
Во-вторых, -execdir
предпочтительнее -exec
. Изman find
:
There are unavoidable security problems surrounding use of the -exec action; you should use the -execdir option instead.
В качестве альтернативы, согласно комментарию steeldriver , если ваша версия mv
поддерживает подробный параметр -v
, вместо этого вы можете изменить исходный блок -exec
на
-exec mv -v {} $4 >> /path/to/log \;
, который будет выдавать результат, аналогичный renamed 'foo' -> 'bar'
.
Итак, снижение размера MTU решило все мои проблемы с вводом-выводом через SSHFS. Как указал @roaima, проблемы, вероятно, были вызваны тем, что брандмауэр университетского сервера слишком активно блокировал пакеты ICMP.
Спасибо @roaima за помощь в решении этой проблемы. И спасибо @derobert за предложение снизить MTU.
Файловая система sshfs
FUSE реализована путем представления файловой системы поверх sftp
, протокола передачи файлов. В результате любой доступ к файлу, такой как редактирование с помощью vi[m]
, требует, чтобы подсистема sshfs
сначала скопировала файл в кэш локальной файловой системы. Если файл особенно велик или сеть между вашим клиентом и сервером особенно медленная, потребуется значительное время для передачи файла, прежде чем он станет доступным локально.
Это (очень )в целом эквивалентно следующему (, за исключением того, что здесь используется sftp
вместоscp
)
# Copy the remote file to a temporary local cache
scp -p remote:/path/to/file /tmp/file.tmp
checksum=$(cksum /tmp/file.tmp)
# Action on remote file is implemented by performing the action locally
vi /tmp/file.tmp
# Simplified; we would also need to handle local rm/mv -> remote rm/mv, etc.
[[ "$(cksum /tmp/file.tmp)" != "$checksum" ]] && scp -p /tmp/file.tmp remote:/path/to/file
Как следствие, вы обнаружите, что попытка запустить gcc
локально будет значительно медленнее, чем просто войти на удаленный сервер и запустить его там. Честно говоря, я не слишком удивлен тому, что «gcc падает при попытке скомпилировать файлы на удаленной файловой системе ». Не должно, конечно, но тогда подумайте о том, что на самом деле происходит на заднем плане...