Comments 17
Не, вы серьезно?
То, что если вы не хотите раскрывать маски, нужно брать в кавычки, рассмотрено уже в инете во всех углах, включая в комментах в прошлой статье. Зачем ради этого еще целую статью делать?
Давайте я еще сразу расскажу, что поиск всех файлов в линукс - это *, а в дос это *.* (потому что имя и расширение это в fat16 разные поля directory entry, и Windows как наследница DOS до сих пор поддерживает это для обратной совместимости.
Но это все вытекает из общего правила как идет разрешение wildcard в командной строке Linux, и правил кавычек. Пожалуйста, горшочек не вари.
Давайте я еще сразу расскажу, что поиск всех файлов в линукс - это *, а в дос это . (потому что имя и расширение это в fat16 разные поля directory entry, и Windows как наследница DOS до сих пор поддерживает это для обратной совместимости.
А можно подробнее? Только что выполнил в Windows команду " DIR * " - отобразились все файлы. Сделал то же самое в эмуляторе DosBox - тоже отобразились. Или Вы имеете в виду, что надо именно в 16-разрядном MS DOS выполнять? Но ведь MS DOS мы не обсуждаем?
А, кажется понял. Вы имеете в виду, что в Windows маска *.* удовлетворяет всем файлам, тогда как в Linux - только тем, которые содержат в имени "точку". Ну да, ну да.
Я буду ещё категоричнее. Это прямо в мануале bash описано.
Недавно поймал себя на мысли, что 95% всех околоайтишных статей - это художественные пересказы отдельных абзацев мануалов различного ПО.
Не такого "распространения знаний" хотели создатели Интернета.
Ну, в NTFS расширений уже нет. А суффикс "точка, три символа" --- дань привычке, удобству, совместимости. Просто звёздочка должна в Уиндоуз все файлы подтащить, не?
А если я хочу подтащить файлы в которых есть точка?
Если хотите, чтобы маска "*.*" обрабатывалась как в SH/BASH, то в Windows воспользуйтесь оболочкой PowerShell.
Ну, сходу в cmd я бы воспользовался чем-то таким:where /r . * | find "."
Для примера я создал в директории несколько файлов. Вот, что вывела команда dir и что указанная команда. Во втором случае нет файла file. https://ibb.co/QC25HpK
Ну, в NTFS расширений уже нет.
Зато они по-прежнему есть и играют важнейшую роль для загрузчика у MS — он всё ещё считает, что тип файла определяется его “расширением” (поубивал бы...)
)) Не спорю, что последняя часть имени файла из точки и трёх символов может иметь важное значение для унаследованного кода.
Я о другом. О том, что нет у NTFS поля данных "расширение", как у FAT-12, -16, например. Точка и три символа на конце -- часть поля данных "имя". Потому, называются, просто, суффиксом. И символ точка, потому, часть имени. В FAT-12 точка не хранилась. Её и не зачем было бы хранить там!!! Она не входила ни в одно из двух полей данных, а была разделителем при синтаксическом разборе.
он всё ещё считает, что тип файла определяется его “расширением” (поубивал бы...)
А почему бы и нет?
В fat/ntfs нет поля, которое бы указывало на тип, есть только аттрибут "файл" или "директория". Поэтому или читать сигнатуры (что долго), или расширение.
Вполне нормальная концепция, весьма гибкая.
В *nix своя концепция, и расширение там прикрутили уже только в GUI, но не как часть ОС.
Я вам еще подкину :)
/home/mobaxterm/tt> ll
total 0
-rw-r--r-- 1 mbatal UsersGrp 0 Jan 11 18:39 111
-rw-r--r-- 1 mbatal UsersGrp 0 Jan 11 18:39 222
/home/mobaxterm/tt> for i in '*'; do echo $i; done
111 222
/home/mobaxterm/tt> for i in *; do echo $i; done
111
222
-----------------
Я думаю вдумчивое чтение man bash (1): GNU Bourne-Again SHell (manpages.org) вам откроет еще столько всего :)
давайте еще накинем
$ touch 1 2 .1 .
$ ls *
1 2
$ ls .*
.1 .2
$ ls -A.1 .2 1 2
Спасибо. Интересно было прочитать.
Четвёртое наблюдение о командной строке и путях в файловой системе