'mv', эквивалентный из перетаскивания с заменой?

awk/sed/bash/Python/Perl/Ruby и большинство других инструментов/языков программирования все могут сделать управление файлами. "Лучшим" путем является способ, которым Вы знакомы и довольны. Если Вы ничего не знаете о sed, ищете его и узнаете об этом. Иначе, если у Вас есть язык программирования, Вы знаете, просто сделайте с ним. Вот пример сценария удара

exec 6<"file"
while read -r line <&6
do
  case "$line" in 
    *pattern* )
       line="${line//word/replace}"
  esac
  echo "$line"
done > "out"
exec 6<&-
mv out file

пример sed

sed 's/word/replace/g' file

пример awk

awk '{gsub(/word/,"replace")}1' file > t && mv t file

Пример Python (используют 'с' для более поздних версий),

for line in open("file"):
    if "pattern" in line:
        line=line.replace("pattern","replace")
    print line
19
23.05.2012, 22:49
4 ответа

Не с mv.

Базовая функция mv (несмотря на его имя), должен переименовать объект. Одна из гарантий, что UNIX делает, это переименовывает, являются атомарными - Вам никогда не разрешают видеть, что частично завершенное переименовывает. Эта гарантия может быть очень полезной, если Вы хотите изменить файл (/etc/passwd, например), что другие программы могут смотреть на, и Вы хотите, чтобы они видели или старую или новую версию файла и никакую другую возможность. Но "рекурсивный переименовывают" как Вы, описывают, повредил бы ту гарантию - Вы могли остановить ее в середине, и у Вас будут полуперемещенное дерево и вероятно путаница - и таким образом, она действительно не согласуется с философией mv. Это - мое предположение относительно почему mv -r не существует.

(Не берите в голову это mv повреждения, что философия в другом, меньших путях. Например, mv на самом деле делает a cp сопровождаемый rm когда движущиеся файлы от одной файловой системы до другого.)

Достаточно философии. Если Вы хотите рекурсивно переместить ("перетаскивать-отбрасывание") дерево от одного места до другого в той же файловой системе, можно получить эффективность и скорость mv следующим образом (например):

cp -al source/* dest/ && rm -r source/*

-l флаг к cp означает, "создают жесткую ссылку вместо того, чтобы копировать" - она эффективно создает новое имя файла, которое указывает на те же данные файла как старое имя файла. Это только работает над файловыми системами, которые поддерживают жесткие ссылки, хотя - таким образом, любая собственная файловая система выхода UNIX прекрасна, но она не будет работать с FAT.

&& означает, "только выполняет следующую команду если предыдущая команда, за которой следуют". Если Вам нравится, можно выполнить две команды по одному вместо этого.

20
27.01.2020, 19:45
  • 1
    Чрезвычайно информационный.Большое спасибо! –  user7089 24.05.2012, 17:36

Я не думаю, что можно копировать поведение перетаскивать-отбрасывания, с которым Вы описываете mv, поскольку непустые подкаталоги в цели не будут заменены.

Возможно, rsync? Что-то как rsync -a -r source/ target/? Выполненный с -v -n чтобы сделать подробный пробный прогон сначала для проверки, это делает то, что Вы хотите.

4
27.01.2020, 19:45

mv -f /path/to/source/folder/* /destination/folder/

Переместит все в/path/to/source/folder, включая файлы и каталоги к/destination/folder.

И перезапишет существующие файлы и каталоги.

3
27.01.2020, 19:45

Вы, вероятно, собираетесь хотеть изменить корректный ответ на это:

https://github.com/iaindooley/pickdrop

Пример:

скажите, что я имею:

test/
test/index.php
test/images/
test/images/a.jpg
test/images/thing.png

и я хочу переместить эти вещи в / сайт

таким образом, это похоже:

site/
site/public/
site/public/index.php
site/public/a.jpg
site/public/thing.png

Я могу пойти:

cd images &&
pick a.jpg thing.png
cd .. &&
pick index.php &&
cd .. &&
mkdir site &&
mkdir site/public &&
cd site/public &&
drop

Это буквально сокращается, и вставить.

1
27.01.2020, 19:45
  • 1
    Очень прохладный, и определенно стоящий изучения. Однако вопрос был конкретно о 'mv', таким образом, я думаю, что оставлю корректный ответ как тот, который объясняет философию позади mv подробно. Спасибо за этот вклад, хотя, определенно очень полезный. –  user7089 25.05.2012, 19:29
  • 2
    Также известный, от readme: "Это не устойчиво вообще - это хранит Ваши выборы в ~/.pick до Вас сброс вызова, при котором времени это использует пути к файлам в ~/.pick для создания нового исполняемого файла ~/.drop файл для копирования каждого из файлов, которые Вы выбрали к текущему рабочему каталогу". –  user7089 26.05.2012, 19:31

Теги

Похожие вопросы