Имеет ли значение для oc fedora регистр имен файлов и каталогов
Я должен рекурсивно переименовать полное дерево папок, чтобы нигде не было заглавных букв (это исходный код C ++, но это не должно иметь значения).
Бонусные баллы за игнорирование файлов / папок контроля версий CVS и Subversion. Предпочтительным способом будет сценарий оболочки, поскольку оболочка должна быть доступна на любом компьютере с Linux.
Были некоторые веские аргументы о деталях переименования файла.
Я думаю, что файлы с одинаковыми строчными именами должны быть перезаписаны; это проблема пользователя. При проверке в файловой системе без учета регистра она также перезаписывает первую на последнюю.
Я хотел бы рассмотреть символы AZ и преобразовать их в az, все остальное просто вызывает проблемы (по крайней мере, с исходным кодом).
Сценарий понадобится для запуска сборки в системе Linux, поэтому я думаю, что изменения в файлах управления версиями CVS или Subversion должны быть опущены. В конце концов, это просто проверка заказа. Может быть, «экспорт» более уместен.
Ранее опубликованные данные будут отлично работать "из коробки" или с некоторыми изменениями для простых случаев, но есть некоторые ситуации, которые вы можете принять во внимание перед запуском пакетного переименования: 1. Что должно произойти, если у вас есть два или более имен в один и тот же уровень в иерархии путей, которые отличаются только регистром, например ABCdef , abcDEF и aBcDeF ? Должен ли сценарий переименования прерваться или просто предупредить и продолжить? 2. Как вы определяете нижний регистр для не-US-ASCII имен? Если такие имена могут присутствовать, следует ли сначала выполнить проверку и исключить проход? 3. Если вы выполняете операцию переименования
Краткая версия с помощью "rename" команды:
Это позволяет избежать проблем с переименованием каталогов перед файлами и попыткой перемещения файлов в несуществующие каталоги (например, "A/A" в "a/a" ).
Или более подробная версия без использования "rename" .
Последнее обеспечивает большую гибкость с помощью команды перемещения (например, "svn mv" ).
Осторожно, обе версии не будут работать в нечувствительной к регистру файловой системе. В моем случае я заменил- then закрытую строку на (mv "$
Используя последнюю версию переименования, регулярное выражение не требуется. Полная команда становится find my_root_dir -depth -exec rename -c <> \; . Добавьте -f для переименования, если вы используете файловую систему без
Меньше все же мне очень нравится
В нечувствительных к регистру файловых системах, таких как HFS + в OS X , вы захотите добавить -f флаг:
Это предполагает, что у вас есть perls rename, что не всегда так. например на моем debian переименование совершенно другое
«find» следует заменить любой командой, которую вы используете, чтобы получить список файлов, которые вы хотите переименовать; например, "ls *.
«Консолидированная» версия, из всех комментариев (ответ больше не может быть отредактирован): for f in `find .`; do mv -v "$f" "`echo $f | tr '[A-Z]' '[a-z]'`"; done
Просто попробуйте следующее, если вам не нужно заботиться об эффективности.
Предполагая, что вычислительная эффективность обычно НЕ является проблемой, когда вам нужно переименовать файлы в каталоге . Я думаю, что это, вероятно, самое творчески простое решение в этой теме. На самом деле, эта тривиальная задача не должна быть такой сложной, как демонстрируют принятые ответы, и этот обходной путь гораздо более пропорционален тому, сколько мыслей я хочу инвестировать в такую операцию, как эта. +1000
Мне пришлось изменить более 50 000 имен файлов в разных структурах каталогов. Первоначально принятый ответ выполнил лишь 10% работы за 2 минуты, где это, со -0 сжатием, было почти мгновенным!
Это не просто неэффективно. Это просто невозможно, если для временного архива недостаточно свободного места.
Чувак, вы, ребята, любите усложнять вещи . Использование:
Как мы можем переименовать в чувствительной к регистру файловой системе? rename 'y/a-z/A-Z/' /tmp/*.jpg -> Can't rename /tmp/*.jpg /TMP/*.JPG: No such file or directory , т.е. попробуйте переименовать весь путь, а не только файл.
Вот скрипт, который изменяет только файлы, а не имена каталогов, чтобы не перепутать find :
Я протестировал его, и он работает с именами файлов, содержащими пробелы, всевозможные кавычки и т. Д. Это важно, потому что если вы запускаете от имени root один из тех других сценариев в дереве, который включает файл, созданный
Это работает, если у вас уже есть или настроена команда переименования (например, через brew install в Mac):
rename это не встроенный bash. Это внешняя утилита, и ее синтаксис зависит от версии, которую вы установили. Этот ответ не является достаточным в качестве портативного решения "для всех ОС на основе Unix", как утверждается.
Только что проверил, rename команда, включенная в последнюю Fedora (28) через util-linux-2.31 пакет, не имеет --lower-case опции.
Это работает на CentOS / Red Hat Linux или других дистрибутивах без rename сценария Perl:
(В некоторых дистрибутивах команда по умолчанию rename взята из util-linux, а это другой несовместимый инструмент.)
--force Переименовать, даже если файл с именем назначения уже существует.
--lower-case Конвертировать имена файлов в нижний регистр.
--nows Заменить все последовательности пробелов в имени файла символами подчеркивания.
Вот мое неоптимальное решение с использованием сценария оболочки Bash:
Все папки переименованы правильно и mv не задают вопросов, когда разрешения не совпадают, а папки CVS не переименовываются (к сожалению, контрольные файлы CVS внутри этой папки все еще переименовываются).
Поскольку «find -depth» и «find | sort -r» оба возвращают список папок в порядке, пригодном для переименования, я предпочел использовать «-depth» для поиска папок.
Первоначальный вопрос касался игнорирования каталогов SVN и CVS, что можно сделать, добавив -prune к команде find. Например, игнорировать CVS:
Используя средство для исправления имени Ларри Уолла:
Это так просто, как
(где fix конечно сценарий выше)
Это небольшой сценарий оболочки, который делает то, что вы просили:
Обратите внимание на действие -depth в первой находке.
Не портативный, только Zsh, но довольно лаконичный.
Сначала убедитесь, что zmv загружен.
Также убедитесь, что extendedglob :
Для рекурсивных строчных файлов и каталогов, где имя не CVS .
find -depth печатает каждый файл и каталог с содержимым каталога, напечатанным перед самим каталогом. $ строчные буквы имени файла.
Это не работает: он переименовывает каталог до того, как работает с содержимым, так что последующая попытка содержимого не удалась.
Добавление -depth исправляет это! Это действительно быстрое решение, но, конечно, без -print0 возможности найти, оно не самое надежное
@jpaugh Нет, это не так. Он попытается переименовать ./FOO/BAR в ./foo/bar, но ./foo еще не существует.
Установить rename пакет,
Эта команда находит все файлы с *.py расширением и преобразует имена файлов в нижний регистр.
- I Флаг не является обязательным. Он используется, когда мы выполняем несколько команд с xargs . Ниже приведен пример использования нескольких команд с xargs cat foo.txt | xargs -I % sh -c 'echo %; mkdir %' Вами может работать без -I как find . -iname "*.py" -type f | xargs -I% rename -c -f "%"
В Windows эмуляции, такие как Git Bash , могут не работать, поскольку Windows не учитывает регистр. Для них сначала добавьте шаг, который mv является файлом, к другому имени, например, «$ old.tmp», а затем к $new .
Длительный, но "Работает без сюрпризов и без установок"
Этот скрипт обрабатывает имена файлов с пробелами, кавычками, другими необычными символами и Unicode, работает с нечувствительными к регистру файловыми системами и большинством сред Unix-y , в которых установлены bash и awk (т.е. почти все). Он также сообщает о коллизиях, если таковые имеются (оставляя имя файла в верхнем регистре) и, конечно, переименовывает как файлы, так и каталоги и работает рекурсивно. Наконец, он легко адаптируется: вы можете настроить команду find для выбора нужных вам файлов / каталогов и настроить awk для других манипуляций с именами. Обратите внимание, что под «ручками Unicode» я подразумеваю, что он действительно преобразует их регистр (а не игнорирует их как ответы, которые используют tr ).
Ссылки
Мой сценарий основан на этих превосходных ответах:
Это хорошо работает и в macOS:
Мне нужно было сделать это на установке Cygwin в Windows 7 и обнаружил, что я получил синтаксические ошибки с предложениями из вышеупомянутого, которые я попробовал (хотя, возможно, я пропустил рабочий вариант). Однако, это решение прямо с форумов Ubuntu сработало из банки :-)
(Примечание: ранее я заменил пробел подчеркиванием, используя:
В OS X mv -f показывает ошибку «тот же файл», поэтому я переименовываю дважды:
В этой ситуации я хотел бы обратиться к Python, чтобы избежать оптимистического предположения путей без пробелов и косых черт. Я также обнаружил, что, python2 как правило, устанавливается в большем количестве мест, чем rename .
@Stephen, который предполагает, что у вас есть права администратора для установки переименования. Мне часто приходится извлекать данные в системах, на которых у меня нет возможности устанавливать другое программное обеспечение. В последних версиях Ubuntus он устанавливается только при наличии perl.
Если вы используете Arch Linux , вы можете установить rename пакет, AUR который предоставляет renamexm команду как /usr/bin/renamexm исполняемый файл и страницу руководства вместе с ней.
Это действительно мощный инструмент для быстрого переименования файлов и каталогов.
Принцип установки программ
Если в Windows программы, зачастую, хранят все данные в одной папке, например в «C:Program FilesProgramName», то в Linux файлы программы разделяются по каталогам в зависимости от типа. Например, исполняемые файлы в /bin, библиотеки в /lib, файлы конфигураций в /etc, логи и кэш в /var.
Преобразовать в нижний регистр
Понятие файла
Понятие «файл» в Linux имеет несколько другое значение, нежели в Windows. «Файлом» можно назвать обычный файл, содержащий данные, и интерпретируемый программой. Директория также является «файлом», содержащим в себе ссылки на другие директории или файлы с данными. Файлы устройства указывает на драйвер, благодаря которому система взаимодействует с физическими устройствами. Имеются и многие другие типы файлов.
Преобразовать в верхний регистр
На практике я не смог этого добиться
Чтобы получить два файла в одном каталоге, отличающихся только регистром, вам необходимо включить подсистему Posix .
В POSIX используется полный режим с учетом регистра, в то время как подсистемы MS-DOS, WOW и Win32 используют режим без учета регистра.
Для включения Posix смотрите:
Это для меня новость. Я должен был временно отрицать это, хотя, хотя у вас есть цитаты, на практике я не смог этого сделать . Не могли бы вы дать инструкции о том, как это можно сделать на практике?
Поскольку я нахожу, что UpperCase действительно удобен для чтения по первым буквенным разделениям в длинных сложных именах, я склоняюсь к тому, чтобы дать некоторые имена из моих файлов Linux с некоторым UpperCase. В основном исполняемые файлы, некоторые каталоги тоже.
Но уже несколько недель я отмечаю, что подавляющее большинство всех имен файлов в моем дистрибутиве linux строчные .
Итак, я немного погуглил и обнаружил эту статью: « Имена файлов Linux» , в которой говорится, что в мире Unix следует всегда использовать строчные буквы,
. Лучше всегда использовать строчные буквы в Linux, если вы не можете придумать вескую причину использовать прописные или смешанные буквы. Большинство пользователей Unix используют строчные буквы почти исключительно, но кроме этой «культурной» точки зрения, есть еще одна веская причина использовать строчные буквы. Если вы используете или используете доступ к файловой системе DOS в Linux, DOS не сможет видеть файлы с именами в верхнем или смешанном регистре .
Это действительно так?
да, это действительно так. Unix люди не могут найти клавишу Shift. но на самом деле нет ничего оправданного, чтобы поддержать правила против смешанного случая. это просто напыщенная речь
Программисты ненавидят использование клавиши Shift (а заглавные буквы - это то, с чем многие пытаются избавиться ). Продолжаем с того места, где написано "всегда используйте строчные буквы" .
Лучше всегда использовать строчные буквы в Linux, если вы не можете придумать вескую причину использовать прописные или смешанные буквы. Большинство пользователей Unix используют строчные буквы почти исключительно, но кроме этой «культурной» точки зрения , есть еще одна веская причина использовать строчные буквы. Если вы используете общий доступ или обращаетесь к файловой системе DOS в Linux, DOS не сможет видеть файлы с именами в верхнем или смешанном регистре.
Основная причина этого заключается в том, что если вы переносите два файла, которые разделены только регистром, в систему без учета регистра, на нечувствительной машине могут произойти запутанные вещи.
Файлы на вашем Linux-компьютере принадлежат вам. Делайте с ними так, как вам нравится, так, чтобы это имело смысл для вас.
Я обнаружил, что соглашение об использовании верхнего регистра в качестве начальной буквы каталога облегчает мне навигацию по ним. Выполнение 'ls' в каталоге автоматически помещает все каталоги в верхнюю часть списка и отделяет каталоги от файлов, что облегчает их просмотр и навигацию. Но опять же, это для меня - делай то, что работает для тебя .
@ mh01 Раньше я считал EBCDIC неактуальным, пока в прошлом году мне не приходилось иметь дело с системой, которая посылала этот набор символов, а не ascii. Я видел системы OpenVMS (самый последний выпуск был только 2 года назад, неплохо для того, что был первый выпуск 35 лет назад) . и его файловая система по-прежнему нечувствительна к регистру. Очевидно, у Mac есть регистрозависимый и нечувствительный к регистру (и steam и photoshop не любят регистрозависимые файловые системы на маке ). Регистр нечувствителен, жив.
Не говоря уже о подавляющем большинстве настольных компьютеров, использующих файловые системы Windows без учета регистра.
Хорошее замечание о нечувствительности к регистру по сравнению с сохранением кейса, но если у вас есть разные файлы, которые отличаются только регистром имени файла, я думаю, что есть и другие проблемы, кроме переноса в нечувствительные к регистру файловые системы, которые могут вызвать путаницу. ..
«Ориентированные на потребителя» (что бы это ни значило) применения, как правило, используют Title Case даже в мире Unix. Это чаще всего случается, когда в рассматриваемой организации есть люди, вся работа которых состоит в том, чтобы думать об опыте пользователя.
Например, мой рабочий стол Ubuntu имеет папки в домашнем каталоге, называемые Downloads , Pictures , Documents и т.д. То же самое для моей OSX ноутбук (да, он считает, что это BSD). Хотя стоит отметить, что Apple заходит так далеко, что называет свои собственные системные каталоги заглавными буквами (например /Library/Audio/Apple Loops/ ), сохраняя при этом «классическую» базовую файловую систему строчными (например /usr/libexec/dtrace/ ). Но ни один дистрибутив Linux, о котором я знаю, не использует titlecase где-либо за пределами домашнего каталога пользователя.
Предположительно, различие заключается в том, что каталоги, на которые вы ожидаете, что люди действительно будут смотреть, являются заглавными буквами, а места, где вы ожидаете, что люди не будут изучать, - строчными. Подобное различие, кажется, находится в игре с Ubuntu; только каталоги, которые должны отображаться в виде списка папок в окне Nautilus, являются заглавными буквами, в то время как имена папок, которые должны вводиться (не просматриваться), все ниже.
И это суть этого; titlecase или uppercase труднее набрать. Но titlecase выглядит лучше в списке или наборе плиточных папок. Итак, выбирайте соответственно. Люди из Linux часто имеют дело с командной строкой даже для рутинных задач, поэтому строчные буквы имеют больше смысла.
Тем не менее, это в основном культура, но есть некоторые предпосылки для этого. Причиной, почему это конкретное соглашение застряло в мире UNIX, является удобство использования . Здесь есть два основных аргумента:
- Разделение слов с использованием буквенных символов лучше для удобства чтения, чем использование регистров для обозначения границ слов. Если вы не верите мне, сравните это предложение с предыдущим и расскажите мне, что проще. (И, конечно же, новизна сепарации все хуже).
- Строчные буквы имеют более разнообразные формы, чем прописные, что, в свою очередь, приводит к более разнообразным формам слов. Это делает текст, написанный в нижнем регистре, проще для чтения, чем текст, написанный в верхнем регистре.
Эти наблюдения легко проверить, и они даже были подтверждены научными исследованиями.
Кроме того, культура UNIX предпочитает соглашения, которые не только легко читаются, но и легко пишутся; Хакеры UNIX - это, как правило, люди, которые проводят много времени за клавиатурой, и многие используют либо официальную систему сенсорного ввода, либо какую-то личную производную, настроенную для программирования. Концепция пребывания в домашнем ряду важна в любом случае, поэтому людям нравится избегать использования клавиш, недоступных из домашнего ряда, особенно клавиш переключения регистра.
Если объединить эти три ограничения, есть только действительно один здравомыслящие конвенции, которая all-lowercase-with-dashes .
@StephaneRolland: последовательное присвоение имен таким различным вещам, как идентификаторы в разных языках программирования и имена файлов, нецелесообразно. Будьте последовательны в каждой области и придерживайтесь установленных соглашений, но не пытайтесь найти одно соглашение, чтобы управлять ими всеми. Переменные Java не являются именами таблиц SQL, и они также не являются именами файлов.
Расширения (суффиксы) имён
Термин «расширение» сохранился со времён, когда операционная система Microsoft DOS была самой популярной для персональных компьютеров типа IBM PC. Файловая система DOS позволяла в именах файлов не более 11 знаков; первые не более 8 из них считались основным именем (base name), а не более 3 последних — расширением ( extension ) имени. Для отделения основной части имени от расширения использовалась точка (кроме специальных имён — . и .. ). Сама точка не считалась частью имени. Имена WORK и WORK. означали одно и то же. Вот пример имени файла наиболее длинного имени: AUTOEXEC.BAT . Многие программы для DOS и Windows придают расширениям чересчур большое значение — например, Microsoft Word будет упорно пытаться открыть файл с расширением .DOC как документ в его родном формате, даже если в файле содержится простой текст. В файловых системах Linux точка — такая же часть имени, что и любой другой символ. Теперь уже WORK и WORK. станут ссылаться на разные файлы. Если угодно, можно по-прежнему называть часть имени файла, следующую за точкой, расширением, хотя точек в имени может быть и несколько. Например, файловому архиву в формате tar , сжатому компрессором lzma , часто дают суффикс .tar.lzma . Большинство программ для Linux не связывают расширение имени файла с его содержимым, либо связывают, но позволяют явно указать тип содержимого файла с помощью опций. Тот же Perl будет запускать свои программы по имени, независимо от того, какое расширение использовано — .pl , .plx или .cgi , и есть ли оно вообще.
Некоторые программы вроде текстовых редакторов, работающие с файлами, и «на месте» изменяющие их содержимое, способны оставлять резервные копии. Имена таких копий обычно получаются из исходных имён добавлением знака ~ в конце, например, linux.html~ .
В Linux вы можете иметь файлы example.JPG и example.jpg в том же каталоге.
В Windows у вас есть расширения с учетом регистра, но вы не можете поместить эти два файла в один каталог. Почему бы нет?
FAT держал расширение отдельно от базового имени, а ОС добавляла . для целей ввода и отображения. (Я полагаю, можно с уверенностью сказать, что практически никто не использует FAT для чего-либо, кроме функциональной совместимости в наши дни.) Я не знаю точно, как NTFS делает это, но я полагаю, что это похоже на любую основную файловую систему Linux, которая просто обрабатывает имя файла как строка символов. Здесь нет ничего особенного в расширении файла: оно просто по соглашению и рассматривается файловой системой как часть имени файла.
Преобразовать в нижний регистр
Имена файлов чувствительны к регистру на томах NTFS
Как часть требований к соответствию POSIX, файловая система Windows NT (NTFS) предоставляет соглашение о присвоении имен файлов и каталогов с учетом регистра. Хотя NTFS и подсистема POSIX хорошо справляются с чувствительностью к регистру, 16-разрядные приложения на базе Windows, MS-DOS, OS / 2 и Win32 этого не делают .
В NTFS вы можете создавать уникальные имена файлов, хранящиеся в одном и том же каталоге, которые отличаются только регистром. Например, следующие имена файлов могут сосуществовать в одном каталоге на томе NTFS:
Тем не менее, если вы попытаетесь открыть один из этих файлов в приложении Win32 , например в «Блокноте», у вас будет доступ только к одному из файлов , независимо от того, какое имя файла вы вводите в диалоговом окне «Открыть файл».
NTFS поддерживает два слегка отличающихся режима работы, которые могут быть выбраны подсистемой приложения, взаимодействующей с NTFS. Первый полностью учитывает регистр и требует, чтобы имена файлов, предоставляемые приложением, совпадали с именами, хранящимися на диске, включая случай, если файл на диске должен быть выбран. Второй режим работы - это сохранение регистра, но без учета регистра. Это означает, что приложения могут выбирать файлы на диске, даже если указанное имя отличается в случае от имени, сохраненного на диске. Обратите внимание, что оба режима сохраняют регистр, использованный для создания файлов. Отмеченное здесь различие в поведении применяется только тогда, когда приложению необходимо найти существующий файл. POSIX использует преимущества режима полного регистра, в то время как MS-DOS, WOW иПодсистемы Win32 используют режим без учета регистра .
В Windows у вас есть расширения с учетом регистра, но вы не можете поместить эти два файла в один каталог. Почему бы нет?
Если диск отформатирован как NTFS, вы можете использовать как example.JPG и example.jpg .
Тем не менее, если вы попытаетесь открыть один из этих файлов в приложении Win32 , например в «Блокноте», у вас будет доступ только к одному из файлов , независимо от того, какое имя файла вы вводите в диалоговом окне «Открыть файл».
Структура каталогов
В ОС Windows жесткие диски называются латинскими буквами (С:, D:, . ), и каждый из дисков представляет собой корневой каталог с собственным деревом папок. Подключение же нового устройства приведет к появлению нового корневого каталога со своей буквой (например, F:). В ОС Linux файловая система представлена единым корневым каталогом, обозначаемым как слэш (/). Соответственно, при данной файловой структуре не диски содержат каталоги, а каталог — диски.
Подключение внешних носителей
В ОС Linux имеется процедура монтирования: когда подключается съемный носитель или диск, файл устройства будет виден в каталоге /dev (devices). Чтобы увидеть содержимое этого устройства, его нужно смонтировать в отдельную директорию /mnt. Также файловая система позволяет примонтировать его и в любое другое место, например /home.
Другие варианты
Вы можете получить образец файла Developers.mp3 отсюда , если это необходимо;)
переименование brew в MacOS -l связано с созданием символической ссылки и -c преобразованием в строчные буквы, так что будьте внимательны.
Сначала переименуйте каталоги снизу вверх сортировки -r (где -depth недоступен), затем файлы. Тогда grep -v / CVS вместо find . - prune, потому что это проще. Для больших каталогов, если f in . может переполнить некоторые буферы оболочки. Используйте поиск . | в то время как читать, чтобы избежать этого.
И да, это будет забивать файлы, которые отличаются только в случае .
Во-первых, find YOURDIR -type d | sort -r это слишком много проблем. Вы хотите find YOURDIR -depth -type d . Во-вторых, find -type f ДОЛЖЕН выполняться после того, как каталоги были переименованы.
Я не пробовал более сложные сценарии, упомянутые здесь, но ни одна из версий командной строки не работала для меня на моем Synology NAS. rename нет в наличии, и многие из вариантов find не потому , что он , кажется, прилипает к старшему имени уже переименованный путь (например, если он находит ./FOO затем ./FOO/BAR , не переименовывая ./FOO к ./foo прежнему будет продолжать список , ./FOO/BAR даже если этот путь больше не действует) , Выше команда работала у меня без проблем.
Далее следует объяснение каждой части команды:
При этом будет найден любой файл из текущего каталога (перейдите . в любой каталог, который вы хотите обработать), используя поиск в глубину (например, он будет перечислен ./foo/bar раньше ./foo ), но только для файлов, которые содержат заглавные буквы. -name Фильтр применяется только к базовому имени файла, а не полный путь. Так что это будет список, ./FOO/BAR но нет ./FOO/bar . Это нормально, так как мы не хотим переименовывать ./FOO/bar . Мы хотим переименовать ./FOO хотя, но это перечислено позже (вот почему -depth важно).
Сама по себе эта команда особенно полезна для поиска файлов, которые вы хотите переименовать. Используйте эту команду после полной команды переименования для поиска файлов, которые еще не были заменены из-за конфликтов имен или ошибок.
Эта часть читает файлы, выводимые find и форматирует их в mv команде с помощью регулярного выражения. -n Опция прекращает sed печатать вход, и p команда в поисковых и замены регулярных выражений выходов замененного текста.
Само регулярное выражение состоит из двух захватов: части вплоть до последней / (которая является каталогом файла) и самого имени файла. Каталог оставлен без изменений, но имя файла преобразуется в нижний регистр. Так что, если find выходы ./FOO/BAR , то станет mv -n -v -T ./FOO/BAR ./FOO/bar . -n Вариант mv убеждается существующие строчных файлы не будут перезаписаны. -v Опция делает mv вывод каждое изменение , что он делает (или не делает - если ./FOO/bar уже существует, то он выдает что - то вроде ./FOO/BAR -> ./FOO/BAR , отметив , что никаких изменений не было сделано). Здесь -T очень важно - он рассматривает целевой файл как каталог. Это позволит убедиться, что ./FOO/BAR он не перемещен, ./FOO/bar если этот каталог существует.
Используйте это вместе с, find чтобы сгенерировать список команд, которые будут выполнены (удобно, чтобы проверить, что будет сделано, фактически не делая этого)
Это довольно очевидно. Он направляет все сгенерированные mv команды в интерпретатор оболочки. Вы можете заменить его bash или любую оболочку по своему вкусу.
Файловая система в ОС Linux, как и в ОС Windows, представляет собой иерархическую структуру каталогов и файлов (в виде дерева), но при этом имеет ряд кардинальных отличий.
Регистр имен
Также стоит отметить чувствительность файловой системы Linux к регистру. Файлы Temp.txt и temp.txt будут интерпретироваться как разные файлы и могут находиться в одной директории, в отличие от ОС Windows, который не различает регистр имен. То же правило действует и на каталоги — имена в разных регистрах указывают на разные каталоги.
Назначение каждой директории регламентирует «Стандарт иерархии файловой системы» FHS (Filesystem Hierarchy Standard). Ниже опишем основные директории согласно стандарту FHS:
Файловые системы ext2 и ext3 допускают наличие в именах файлов практически любых символов, кроме разделителя директорий ( / ). Однако я не советую использовать имена, содержащие русские буквы, знаки пунктуации (кроме точки), пробелы, псевдографику, экзотические знаки вроде символа перехода на новую строку. Не стоит также начинать имена файлов с дефиса ( - ). Тут дело в том, что многие программы, работающие с файлами, принимают в командной строке ключи (опции), начинающиеся с дефиса. Например, вы хотите пролистать каталог по имени -lR командой ls -lR . Но -lR будет воспринято программой ls не как имя каталога, а как ключи -l (выдать подробный листинг) и -R (рекурсивно), и в результате вы получите листинг текущего каталога (так как каталог не указан, программа ls по умолчанию работает с текущим). Во всех остальных случаях дефис в именах файлов вполне допустим и часто используется. Советуем ограничиться следующим набором символов — латинские буквы (большие и маленькие), цифры, знак подчёркивания, дефис (но не в начале), точка.
Заглавные и маленькие буквы
В файловых системах ext2 и ext3 (в отличие от файловых систем Microsoft Windows ) имена файлов являются чувствительными к регистру ( case sensitive ) — заглавные и маленькие буквы в именах различаются.
Читайте также: