Программирование с помощью Unix API

> Не удивлюсь, если на это тему, похоже, можно будет писать и через 50 лет.

ну да, конечно
Этот API ведь меняется и устаревает несколько быстрее чем египетские пирамиды

А разве, уже очень давно, такого рода информации не было?!

смысла не понял - помойму у всех людей есть manpages....

Часть 1 - Программирование файловой системы

Интересная статья )

> смысла не понял - помойму у всех людей есть manpages....

Прежде чем начать читать manpages следует книжек разумных почитать. Собственно говоря я близко к этим текстам не присматривался, так как они вполне соответствовали той картине мира, которую я получил после прочтения Кернигана и Пайка.

>сли на это тему, похоже, можно будет писать и через 50 лет.

не дай бог.

> Программирование с помощью Unix API"

Думаю, стоит убрать двойные кавычки в конце названия новости.

fixed.

Итак по пунктам ... Автор конешно не дурак пописать, но вот со знаниями области у него туго.

К стилю примеров придираться не буду, хотя можно давайте сразу к содержанию первой статьи.

1) Структура FILE это стандарт ANSI C, к unix он имеет весьма косвенное отношение, unix оперирует файловыми дискрипторами а не FILE, FILE он и в винде есть 2) Я понимаю что на linux свет клином сошёлся, но нормальный способ дублировать дискрипторы dup и dup2 , а никак не open("/dev/fd/0", 0) 3) Очевидно автор рассмотрел почти всё, что можно делать с файлом, кроме маппинга файлов, а в 90% случаев именно это самый адекватный и более быстрый способ работы с локальными файлами. 4) Не надо читать файл /proc/self/environ, есть getenv() есть environ() этот файл не есть стандарт unix, зачем писать непереносимые программы, если можно писать переносимые быстрее и проще?? 5) Не слова о ссылках и символических ссылках, вроде тоже фундаментальные понятия unix.

Статья явно нацелена на новичков, причём учит абсолютно неверным вещам, учит как бы так написать программу чтобы она работала в linux но не работала во всех других unix.

Повествование очень неоследовательно работаем то с fd то с FILE, написано про fseek, но не слова про lseek. Потом снова работа с fd для блокировок ....

P.S. Читайте хороших авторов, не читайте плохих.

Итак по пунктам ... 
Автор конешно не дурак пописать, но вот со знаниями области у него туго.

К стилю примеров придираться не буду, хотя можно давайте сразу к содержанию первой статьи.

1) Структура FILE это стандарт ANSI C, к unix он имеет весьма косвенное отношение, unix оперирует файловыми дискрипторами а не FILE, FILE он и в винде есть 
2) Я понимаю что на linux свет клином сошёлся, но нормальный способ дублировать дискрипторы dup и dup2 , а никак не open("/dev/fd/0", 0) 
3) Очевидно автор рассмотрел почти всё, что можно делать с файлом, кроме маппинга файлов, а в 90% случаев именно это самый адекватный и более быстрый способ работы с локальными файлами. 
4) Не надо читать файл /proc/self/environ, есть getenv() есть environ() этот файл не есть стандарт unix, зачем писать непереносимые программы, если можно писать переносимые быстрее и проще?? 
5) Не слова о ссылках и символических ссылках, вроде тоже фундаментальные понятия unix.

Статья явно нацелена на новичков, причём учит абсолютно неверным вещам, учит как бы так написать программу чтобы она работала в linux но не работала во всех других unix.

Повествование очень неоследовательно работаем то с fd то с FILE, написано про fseek, но не слова про lseek. Потом снова работа с fd для блокировок ....

P.S. Читайте хороших авторов, не читайте плохих.

>Структура FILE это стандарт ANSI C

ты ещё для полного удлвольствия скажи что язык С имеет к unix косвенное отношение.

"1) Структура FILE это стандарт ANSI C, к unix он имеет весьма косвенное отношение"

Дааа... Аноним конечно перегнул палку...

Как говорится - пиши, что думаешь, но думай, что пишешь...

Потрясающе верный комментарий.

Если тоже будет через 50 лет, то человечество явно не тот путь выбрала, который нужно...

в смысле выбралО

и почему тут только редактировать нельзя...

Статьи не понравились. Непонятно на кого ориентированы. Хорошо, что я не покупаю Linux Format. В начале, про файловые системы, идет "пудреж мозгов" про INT 80 и "специальную команду" --- можно подумать, что Linux только на x86 работает. Вместо того, чтобы подробно объяснить open() и все его флаги, а потом read() и write(), сразу идет /dev/cdrom и ioctl(). При этом "наметилась тенденция на отказ от использования ioctl()" --- хоть бы сказал, что используют вместо ioctl(), если такой умный :)

А для обработчиков сигнала даже не упомянут флаг SA_SIGINFO, позволяющий обработчику получать дополнительную информацию...

В общем, пусть процветают традиции ЛОР'а, --- не ходите по ссылке, граждане :))

Может по пункту 1 он и не прав, а вот насчёт 2 и 4 я с ним полностью согласен

RU/FV.......

Статьи рассчитаны на людей, которым ничего не известно о затрагиваемых вопросах и которые никогда не будут применять то, что прочитали, занятые написанием очередного патча к хэлловорлду. Беллетристика, короче.

>В Linux 2.4.22 каждый процесс может открыть ...

жесть. через 50 лет тож будет описываться ядро 2.4

Если кто-то хочет прочитать действительно дельную книгу по программированию с помощью системных вызовов UNIX, пусть читает Марка Рочкинда. Тем более что есть русский перевод.

Хоть я и так с этим неплохо знаком, но, всё же, хороший труд и, главное, верный поступок..

> А для обработчиков сигнала даже не упомянут флаг SA_SIGINFO, позволяющий обработчику получать

В статье про сигналы допущена куда более серьезная ошибка - не рассказано про sig_atomic_t. А это черевато разными проблемами в переносимом коде, когда захочется из этих обработчиков собственно что-то осмысленное делать, оповещая главную часть программы о том, что обработчик был вызван.

> 3) Очевидно автор рассмотрел почти всё, что можно делать с файлом, кроме маппинга файлов, а в 90% случаев именно это самый адекватный и более быстрый способ работы с локальными файлами.

Как человек, "заботящийся" о переносимости (хоть и написавший бред про файл), ты должен понимать, что маппинг - очень специфический способ работы, который во-первых не обязан быть вообще реализован в POSIX-совместимой ОС (т.е. вызов будет, но пустой), во-вторых не обязан работать, и в-третьих способен обламываться без всякой на то видимой причины, что не считается ошибкой или неадекватной ситуацией. Мало ли файл попался больше 3 Гб на 32-х битной ОС, или пользователь "/dev/cdrom" или еще какую гадость на "открыть файл" подсунул, или это вообще не настоящий файл, а через какой-то механизм vfs организован и маппинг не поддерживает в принципе. Или файловая система на fuse, который даже в распоследних версиях не все виды mmap поддерживает.

И любая программа, которая использует mmap всегда должна быть готова к тому, что mmap обломиться и нужно не потерять никакой функциональности, продолжая работать без него. Учитывая тот уровень, на который рассчитаны эти статьи, может это и правильно, что про него не рассказывают - а то руки зачешутся его использовать и полагаться на его работоспособность в каком-то участке кода, а потом от этого одни проблемы будут.

Ребят полно орфографических ошибок.

Не знаю. Я не люблю unix. Но лучше него просто нету. И это грустно.

POSIX, да, он портабелен, но, блин, он убил все иследования в области ОС. По сути все что сейчас есть это просто unix в разных фурмолировках.

Что есть plan9/etc я знаю, но, к сожелению, все занял unix-like. И я не вижу причин которые бы смогли вытеснить его.

Да, в unix есть проблемы, и все это знают. Но к ним привыкли.

Просто грустно.

Прочитал про сигналы, больше читать ничего оттуда не буду...

1) "обработчик сигнала - обычная функция". Ну да, обычная. Почти. Не считая всех маленьких отличий, включающих, например, способ выделения стека.

2) про async signal safe функции - ни слова

3) более того - в первом же примере в обработчике сигнала используется printf(3)

Аффтар, не пеши больше!

> Если кто-то хочет прочитать действительно дельную книгу по программированию с помощью системных вызовов UNIX, пусть читает Марка Рочкинда. Тем более что есть русский перевод.

Хорошая книжка А у тебя нет случайно его в электронном виде? А то найти не могу.

> Ребят полно орфографических ошибок.

Поправь. Исходники открыты. Лень править самому - отпиши об ошибках автору.

P.S. В журнале правкой ошибок занимается корректор. Выложенный текст находится в состоянии до корректора.

> Да, в unix есть проблемы, и все это знают. Но к ним привыкли.

nixы достаточно хороши. Все улучшения пока дают проценты в удобстве/скорости. Чтобы пошла смена необходимы порядки.

Сейчас реальные пацаны вместо ioctl юзают sysfs. Замена, конечно, неплохая, но необходимо добавлять немалые куски дополнительного кода. Со стороны ядра ioctl выглядит проще, а sysfs сложнее. Со стороны юзерспейса - IMHO, одинаково.

> Не удивлюсь, если на это тему, похоже, можно будет писать и через 50 лет.

Это был бы хороший знак IMXO.

> 1) "обработчик сигнала - обычная функция". Ну да, обычная. Почти.
> Не считая всех маленьких отличий, включающих, например, способ
> выделения стека.
Правда? И какие же эти отличия? И как компилятор
узнаёт о них, если эта функция ни каким специальным
атрибутом не помечена (на х86 по крайней мере)?
Можешь для проверки вызвать её просто из проги и она
отлично сработает. Это - обычнейшая функция. Сделаешь
ты её обработчиком или нет - её код не изменится ни на
одну инструкцию от этого.

> Это - обычнейшая функция. Сделаешь ты её обработчиком или нет - её код не изменится ни на одну инструкцию от этого.

Ее-то код не изменится, проблема в том, что из-за специфики того, как она вызывается, там нельзя делать многое, что допустимо в "обычнейших функциях". Как по реальным операциям, так и по общей логике (например, приходится сраховаться от сюрпризов вида - прислали еще сигнал в момент обработки предыдущего и прервали выполнение функции ей же). И попытка рассматривать ее как таковую приводит к множеству очень трудно диагностируемых проблем. Глюки маловероятны и редки, но это делает их практически неуловимыми.

Ну помедитируй над sigaltstack(2), например. Вдобавок, емнип, на чём-то отличном от линукса так и вовсе такой вот примерно конструкцией можно было похерить стек в основном коде:

#include <signal.h>
#include <stdlib.h>
#include <string.h>

static void
sigint(int signo)
{
    int a[8192];
    memset(a, 'A', sizeof(a));
    write(STDOUT_FILENO, a, sizeof(a));
}

int
main()
{
    signal(SIGINT, sigint);
    blah-blah-blah
    return(0);
}

Про файл вовсе не бред АКСТИТЕСЬ, есть Unix есть ANSI C ...
ANSI C это подмножество всех файловы операций, а вовсе не родной  unix интерфейс.
Ещё раз для самых умных -  FILE есть везде где есть стандартная библитека С.
Файловые дискрипторы - это именно особенность UNIX и реализация FILE основана на них.  
Огромное число операций через FILE напрямую не доступно poll(select/epoll), создание ссылок, ioctl.
FILE это универсальный способ чтения файловой системе для языка С но не для unix.

Mapping давно уже стандарт в том числе  POSIX.1b. 
Сказки про то что он имеет право обламываться оставьте для детей. Сейчас чедо доброго
вам кто нть поверит и начнутся рассказы о том как неполноценен unix в мём даже маппинга файлов в память нету.
Проблемы fuse -  это проблемы  fuse, а не  unix.
VFS слово умное я понимаю - ознакомьтесь с теорией, все файловые системы во всех
современных unix реализованы через интерфейс vfs. 

Насчём того что все будьте готовы что mmap обломится, ну что за бред.
И IPC через  sharem memory который через mmap реализовывается тоже не обязан работать. 

А что Стивенс уже не в моде? Unix Network Programming первая и вторая части. Шнайдер уже не в моде? давно уже куча достойных книг на эту тему.

> Файловые дискрипторы - это именно особенность UNIX и реализация FILE основана на них.

Правильно. Везде, где есть UNIX, обязана быть libc, в которой есть FILE, и он является стандартной реализацией. То, что при этом можно использовать так же и низкоуровневую, не делает ее менее станадартной.

> Сказки про то что он имеет право обламываться оставьте для детей.

Ой ли? Ну и что прикажете делать с приведенными мной примерами?

> Проблемы fuse - это проблемы fuse, а не unix.

POSIX-программа потому и является переносимой, что ей без разницы на низкоуровневую реализацию. А mmap может как работать, так и не работать - это она обрабатывать должна всегда, а уж почему он там не работает..

> VFS слово умное я понимаю - ознакомьтесь с теорией, все файловые системы во всех современных unix реализованы через интерфейс vfs.

Видимо, _слишком_ для вас умное, что вы даже не задумывались о том, что некоторые термины бывают многозначные. Примеры gnome-vfs, avfs о чем-нибудь говорят? А vfs в ядре никто и не трогает.

sysfs можно юзать хоть из скриптов на bash, а ioctl - нельзя/очень сложно. Следовательно, sysfs - более unix-way, ибо как говорил Учитель, "в одной строчке на bash может быть больше unix-way, чем в 1000 строк на С".

Да нет проблем с вашими примерами никаких, файл большой так не мапьте весь, смапьте нужный кусок/куски.

/dev/cdrom мапится как ни странно без проблем, другое дело, что доступ так будет медленный достаточно.

А уж где подсовывают что не поподя это уж извольте честные случаи. 
Я нигде не писал что только маппинг и ничего кроме.

> POSIX-программа потому и является переносимой, что ей без разницы на низкоуровневую реализацию. А mmap может как работать, так и не работать - это она обрабатывать должна всегда, а уж почему он там не работает..
POSIX программа должна работать на POSIX системе, файловая система POSIX 
совместимой OS должна поддерживать маппинг

P.S. Как пишете так и понимаю, писали бы gnome-vfs понял бы как gnome-vfs. Пишете vfs читабю как vfs.

Я не очен понял, anonymous (*) (21.05.2007 11:02:58) вы выступаете
за то что про мапинг писать не надо даже в такой биллетристической статье
как та что здесь обсуждается?

Скачал все статьи, на досуге обязательно почитаю. Несмотря на возможные неточности, опечатки и неплоноту материала всё равно автору спасибо!

Почитай лучше Столлингса.

>ибо как говорил Учитель, "в одной строчке на bash

Яйца бы отбить этому Учителю железным прутом, за использование нестандартных расширений shell.

> ты ещё для полного удлвольствия скажи что язык С имеет к unix косвенное отношение.

Неверно. Компилятор С - стандартная утилита Unix.

+1

товарищи "линуксёнки" :) читать надо _только_ оригинальных авторов, а не перевранное и дополненное "аффтарами". Сказали же уже есть замечательные книги, например тот же Стивенс, последнее издание в формате chm можно загрузить здесь: http://dalt.1000mb.ru/file/?fileid=430

доки формате chm можно посмотреть GPL-ным просмотрщиком xchm http://xchm.sourceforge.net/

"ослиная" ссылка есть тут: http://lib.mexmat.ru/books/15716

в каком формате ослиный вариант не знаю, если в pdf, выкачайте плиз кто-нибудь и поделитесь, мне лень это делать

английский надо учить!

Лучше купить: http://www.bolero.ru/product-38790007.html

Не знаю, мне бумага больше нравится

В который раз заглядываю в "черепаху" Робачевского, и не знаю горя (читай "не испытываю потребности в подобных статейках"). Иногда мне кажется, что авторы статей LF пишут только ради того, чтобы что-нибудь написать. Порой такой бред и откровенная ложь встречается, что диву даёшься. Однако, бывает и хороший материал, это стоит признать.

> Яйца бы отбить этому Учителю железным прутом, за использование нестандартных расширений shell.

GNU-несовместимые системы, где "стандартный" недошел не понимает возможностей bash, давно должны умереть в биореакторе.

> Лучше купить: http://www.bolero.ru/product-38790007.html

> Не знаю, мне бумага больше нравится

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