Comments 25
Просто прорекламирую здесь свой веб сервер написанный ради развлечения на bash.
UFO just landed and posted this here
В какой такой таблице и структуре?
Информация о файле хранится в iNode, и при открытии файла, вы работаете с ним именно через iNode.
Но номер iNode и номер дескриптора — совершенно разные вещи.
Информация о файле хранится в iNode, и при открытии файла, вы работаете с ним именно через iNode.
Но номер iNode и номер дескриптора — совершенно разные вещи.
UFO just landed and posted this here
вообще-то stdin/stdout/stderr это стандартные потоки для каждого процесса, и они уже открыты под зарезервированными для них дескрипторами 0, 1, 2 — о чем и говорит их наличие в /proc/xxx/fd. Если вы открываете еще один файл — появляется еще один поток с очередным дескриптором в /fd
Как таковых файлов stdin/stdout/stderr на файловой системе нет — это зарезервированные слова для обращения к этим дескрипторам.
А так как вся информация о файловой сущности хранится именно в iNode, а не в «номер структуры в таблице, в полях хранится вся информация о файле.», я и переспросил какую структуру вы имеете ввиду. Поскольку в каталоге есть только имя и ссылка на iNode на устройстве.
Как таковых файлов stdin/stdout/stderr на файловой системе нет — это зарезервированные слова для обращения к этим дескрипторам.
А так как вся информация о файловой сущности хранится именно в iNode, а не в «номер структуры в таблице, в полях хранится вся информация о файле.», я и переспросил какую структуру вы имеете ввиду. Поскольку в каталоге есть только имя и ссылка на iNode на устройстве.
Понял, вы спутали файловый дескриптор (номер открытого потока) и индексный дескриптор (iNode).
Сами iNode не хранятся в структуре каталога, там хранится только тип, имя и номер соответствующей iNode для файлов/каталогов/ссылок, и другая информация для остальных файловых сущностей (блочных устройств, пайпов..)
А сами iNode хранятся в отдельных блоках. В старых файловых системах блоки с iNode сразу создавались при форматировании, сейчас (в ext4, например), создается часть iNode, но если их не хватит, дополнительные iNode могут быть созданы позже.
Следовательно первичны именно 0, 1, 2. А STDIN, STDOUT, STDERR это уже алиасы, которые появились в POSIX позже
Сами iNode не хранятся в структуре каталога, там хранится только тип, имя и номер соответствующей iNode для файлов/каталогов/ссылок, и другая информация для остальных файловых сущностей (блочных устройств, пайпов..)
А сами iNode хранятся в отдельных блоках. В старых файловых системах блоки с iNode сразу создавались при форматировании, сейчас (в ext4, например), создается часть iNode, но если их не хватит, дополнительные iNode могут быть созданы позже.
Следовательно первичны именно 0, 1, 2. А STDIN, STDOUT, STDERR это уже алиасы, которые появились в POSIX позже
UFO just landed and posted this here
Простите, но это все — про индексный дескриптор.
А файловый дескриптор — это поток, открытый в конкретном процессе. Он имеет порядковый номер, начиная с нуля. Так как в linux мы имеем виртуальную файловую систему procfs, то файловый дескриптор мы можем увидеть в виде файла с именем 0, 1, 2 в /procfs — в данном случае имя файла и номер файлового дескриптора совпадают (и практически являются одним и тем же) — procfs это прямой интерфейс к процессам.
А вот файлов stdin,stdout и stderror — не существует ни на какой файловой системе.
А файловый дескриптор — это поток, открытый в конкретном процессе. Он имеет порядковый номер, начиная с нуля. Так как в linux мы имеем виртуальную файловую систему procfs, то файловый дескриптор мы можем увидеть в виде файла с именем 0, 1, 2 в /procfs — в данном случае имя файла и номер файлового дескриптора совпадают (и практически являются одним и тем же) — procfs это прямой интерфейс к процессам.
А вот файлов stdin,stdout и stderror — не существует ни на какой файловой системе.
UFO just landed and posted this here
Снова не соглашусь )
Поток и поток — разные вещи. Не путайте stream и thread — там ничего не смазано.
FD = File Descriptor. Быть указателем на открытый файл и есть суть дескриптора. При открытии файла, у процесса появляется новый file descriptor, который ссылается на конкретный iNode. Да, у дескриптора есть номер, чтобы программист мог обратиться к конкретному дескриптору.
Но чтобы записать в файл данные, обычная программа их пишет не в iNode, а в дескриптор. Как именно данные положить в файл/поток или что там по этому дескриптору на самом деле открыто — думает не разработчик приложения а операционная система (драйвер этого устройства, драйвер конкретной файловой системы), разработчик, пользуясь готовыми функциями должен лишь соблюдать правильный формат данных.
Поток и поток — разные вещи. Не путайте stream и thread — там ничего не смазано.
Fd это всего лишь целое число
FD = File Descriptor. Быть указателем на открытый файл и есть суть дескриптора. При открытии файла, у процесса появляется новый file descriptor, который ссылается на конкретный iNode. Да, у дескриптора есть номер, чтобы программист мог обратиться к конкретному дескриптору.
Но чтобы записать в файл данные, обычная программа их пишет не в iNode, а в дескриптор. Как именно данные положить в файл/поток или что там по этому дескриптору на самом деле открыто — думает не разработчик приложения а операционная система (драйвер этого устройства, драйвер конкретной файловой системы), разработчик, пользуясь готовыми функциями должен лишь соблюдать правильный формат данных.
За пример с sqlplus и с <<< отдельный респект!!! Возьму на вооружение.
1. Я сделал так:
ln -s /dev/tty 1
3. grep будет искать слово «file1» в файлах «file2» «file3» и т.д.
ln -s /dev/tty 1
3. grep будет искать слово «file1» в файлах «file2» «file3» и т.д.
1. Можно также примаунтить конкретный /dev/pts/xx, или тот же /proc/$$/fd/1, вариантов много, но оставляет за собой мусор =), а я хотел как раз сделать акцент на /fd в этом вопросе
3. Дополнил статью, спасибо!
3. Дополнил статью, спасибо!
Ну, кстати ещё, что надо понимать — [1-5] не генерирует диапазон, а именно что ищет файлы, попадающие под маску и передает маску как есть, если ни одного не нашло. e.g.:
mick@mick-office:~$ mkdir fffg
mick@mick-office:~$ cd fffg
mick@mick-office:~/fffg$ echo [1-3]
[1-3]
mick@mick-office:~/fffg$ touch 2
mick@mick-office:~/fffg$ echo [1-3]
2
Задача 3 — кавычки. Синтаксис грепания как и в любом языке, поиск подстроки в строке. То есть надо сказать грепу именно строку "", а не последовательность названий файлов. Хз его поведение, я кавычки не пропускаю и не пользуюсь им соло.
Ну смотрите
То есть кавычки совершенно не обязательны, и это нормалная практика.
Но о том, что маски файлов поддерживают перечень символов — я не знал, и в какой-то момент впал в ступор (примерный случай в статье привел), не понимая что происходит.
$ cd /dev/shm
$ echo -e "hello\nworld" > file.txt
$ grep hello ./*
hello
$ grep hel* ./*
helloТо есть кавычки совершенно не обязательны, и это нормалная практика.
Но о том, что маски файлов поддерживают перечень символов — я не знал, и в какой-то момент впал в ступор (примерный случай в статье привел), не понимая что происходит.
Да, я глянул под спойлер потом. Занятно… Но пофигу, кавычки забывать нельзя =) Оно может и не возбраняется… Но как и у хейтеров перла это главный аргумент против. Одно дело разок забыть и это не повлияет на результат, другое — систематически забивать. Я грепаю только с кавычками, благо не так часто оно мне надо.
Тут, видимо, важно учитывать поведение именно самого баша, потому что регулярку он развернул согласно команде (файл1 файл2… — вот уже и логическая ошибка при валидном синтаксисе). Если ищем строку, то надо оформлять как строку.
Тут, видимо, важно учитывать поведение именно самого баша, потому что регулярку он развернул согласно команде (файл1 файл2… — вот уже и логическая ошибка при валидном синтаксисе). Если ищем строку, то надо оформлять как строку.
Update: поправлено форматирование и исправлена замеченая неточность.
Вау, шикарная статья! Спасибо! Жаль, она прошла мимо моего внимания в период голосования…
Особенно за первую задачку спасибо! У нас в офисе нет таких гуру линукса, поэтому, когда я начал строчить коллегам сообщения в терминалы на общем сервере, то получилось эффектно)
Особенно за первую задачку спасибо! У нас в офисе нет таких гуру линукса, поэтому, когда я начал строчить коллегам сообщения в терминалы на общем сервере, то получилось эффектно)
Sign up to leave a comment.
Немного предпятничных задачек на Bash