Вижте, това е пълен пример, работещ и компилируем пример. Не се колебайте да го компилирате сами и да го тествате, наистина работи. Трябва да извикате програмата от терминал по следния начин:

Нека сега се съсредоточим върху самото повикване за четене:

Подписът за четене е следният (извлечен от man-страниците на Linux):

Първо, аргументът fd представлява дескриптора на файла. Обясних малко тази концепция в статията си за вилицата.  Файловият дескриптор е int, представляващ отворен файл, сокет, тръба, FIFO, устройство, добре, това е много неща, при които данните могат да се четат или записват, обикновено по начин, подобен на поток. Ще разгледам по-задълбочено за това в следваща статия.

отворената функция е един от начините да кажа на Linux: Искам да направя нещата с файла по този път, моля, намерете го там, където е и ми дайте достъп до него. Ще ви върне този int, наречен дескриптор на файл и сега, ако искате да направите нещо с този файл, използвайте този номер. Не забравяйте да се обадите на close, когато приключите с файла, както в примера.

Затова трябва да предоставите този специален номер за четене. Тогава има аргумент buf. Тук трябва да предоставите указател към масива, където четенето ще съхранява вашите данни. И накрая, броят е колко байта ще прочете най-много.

Връщаната стойност е от тип ssize_t. Странен тип, нали? Това означава "подписан размер_т", всъщност това е дълъг int. Той връща броя на байтовете, които успешно чете, или -1, ако има проблем. Можете да намерите точната причина за проблема в грешната глобална променлива, създадена от Linux, дефинирана в . Но за да отпечатате съобщение за грешка, използването на perror е по-добре, тъй като отпечатва грешно от ваше име.

В нормални файлове - и само в този случай - четенето ще върне по-малко от броя, само ако сте стигнали до края на файла. Предоставеният от вас масив buf трябва да да бъде достатъчно голям, за да побере поне байтове, или вашата програма може да се срине или да създаде грешка в сигурността.

Сега четенето не е полезно само за нормални файлове и ако искате да усетите неговите супер-сили - Да, знам, че не е в нито един комикс на Marvel, но има истински сили - ще искате да го използвате с други потоци като тръби или контакти. Нека да разгледаме това:

Специални файлове на Linux и системно обаждане за четене

Фактът четене работи с различни файлове като тръби, контакти, FIFO или специални устройства като диск или сериен порт е това, което го прави наистина по-мощен. С някои адаптации можете да правите наистина интересни неща. Първо, това означава, че можете буквално да пишете функции, работещи върху файл, и вместо това да ги използвате с тръба. Интересно е да предавате данни, без никога да удряте диска, осигурявайки най-добра производителност.

Това обаче задейства и специални правила. Да вземем примера за четене на ред от терминал в сравнение с нормален файл. Когато извикате четене на нормален файл, на Linux му трябват само няколко милисекунди, за да получите количеството данни, които искате.

Но що се отнася до терминала, това е друга история: да речем, че поискате потребителско име. Потребителят пише в терминала своето потребителско име и натиска Enter. Сега следвате съвета ми по-горе и се обаждате на read с голям буфер като 256 байта.

Ако четенето работи както при файловете, ще изчака потребителят да напише 256 знака, преди да се върне! Потребителят ви ще чака завинаги и след това за съжаление ще убие вашето приложение. Със сигурност не е това, което искате, и бихте имали голям проблем.

Добре, можете да четете по един байт, но това решение е ужасно неефективно, както ви казах по-горе. Трябва да работи по-добре от това.

Но разработчиците на Linux смятат, че четат по различен начин, за да избегнат този проблем:

• Когато четете нормални файлове, той се опитва колкото е възможно повече да прочете броя на байтовете и ще получи активно байтове от диска, ако това е необходимо.
• За всички останали типове файлове той ще се върне възможно най-скоро има налични данни и най-много броя байтове:
  1. За терминалите е така в общи линии когато потребителят натисне клавиша Enter.
  2. За TCP сокетите, веднага щом компютърът получи нещо, няма значение количеството байтове, които получава.
  3. За FIFO или тръби обикновено е същата сума като тази, която пише другото приложение, но ядрото на Linux може да доставя по-малко наведнъж, ако това е по-удобно.

Така че можете безопасно да се обаждате с вашия буфер от 2 KiB, без да оставате заключени завинаги. Имайте предвид, че може също да се прекъсне, ако приложението получи сигнал. Тъй като четенето от всички тези източници може да отнеме секунди или дори часове - докато другата страна не реши да пише, в края на краищата - прекъсването от сигнали позволява да спрете да оставате блокирани твърде дълго.

Това обаче има и недостатък: когато искате да прочетете точно 2 KiB с тези специални файлове, ще трябва да проверите връщаната стойност на четенето и да извикате четене няколко пъти. read рядко ще запълни целия ви буфер. Ако вашето приложение използва сигнали, ще трябва също да проверите дали четенето е неуспешно с -1, защото е било прекъснато от сигнал, като използвате errno.

Позволете ми да ви покажа как може да бъде интересно да използвате това специално свойство на read: