Ipc: pipe и fd

Фиолетовые велосипеды мурлыкают под дождём из мармеладных котов.

Cat просто читает stdin. Ничего «переназначать» для этого не требуется.

cat test_data|myprg

А зачем тут mkfifo? Ну и это, ты бы код показал.

P.S. если ты полез читать исходники гнутого cat, то лучше не надо. Держи нормальный: https://github.com/openbsd/src/blob/master/bin/cat/cat.c

https://github.com/pete/cats/blob/master/unix7-cat.c

Теоритически можно получить ввод через переназначение: https:/yztm.ru/epo/epo_z615 Профессор зря пи%#ть не будет. Но ничего не вышло.

Можно не показывать весь код? Опять все настроение испортят.

Гнутый cat выбрал потому, что не хотел разбираться с компиляцие, а сразу printf’ами посмотреть, что и как работает.

bsd cat скомпилился так:

gcc -o cat cat.c -lbsd

Кому интересно.

и в нем используется read(rfd…)

read - системная функции (не точно), их я использовать не хотел, потому, что мешать системные функции и высокоуровневые обертки для них «плохой тон».

я так пробовал:

#define STDIN 0

int main(int argc,char **argv)
{
    int sym;
    int count = 1;
    while((sym=getc(STDIN))!=EOF)
    {
	printf("%d %c\n", count++, sym);
    }
    return 0;
}

получил ошибку сегментации, поэтому пошел дальше пробовать прочитать символы из STDIN_FILENO функцией getc.

т.е. https://yztm.ru/epo/epo_z6l5/

А надо было getc(stdin). И #include <stdio.h> не забыть.

stdin = 0, это значит разницы быть не должно.

Пишу программу получающую данные через пайп, как cat

ЯННП при чём тут mkfifo, но в любом случае, канал, или не канал – для cat это не имеет значения и ни чем не отличается от чтения из файла. Канал (хоть именованный, хоть нет) это и есть файл.

А почему ты решил, что getc принимает fd? На самом деле это синоним fgetc и параметр у нее FILE*.

Особеность fifo в том что прочитал одно сообщение, насиловать дальше смысла нет ничего не придёт, закрывай файл и открывай по новой чтобы прочитать следущее, можно юзать сокеты, но fifo на чтении мелких сообщений лидируют, а сокеты на передаче большого количества данных за раз становятся оправданы.

Да, я уже посмотрел исходники studio.h Просто везде пишут дискриптор, когда это указатель, а в другом случае константа. Вот и заентересовался как из константы получается указатель и зачем это вобще понадобилось. Код исправил работает. Значит надо исходники stdlib смотреть?

Ну я как бы в тегах указал ipc, хотя мне shared memory больше нравиться. Как в amiga OS. Было бы круто сп@#&ть это в Linux.

я храмотный наверно тебя запутал.
В твоём случае вызов cat test_data|myprg сработает один раз после echo «хи-хи-ха-ха»>test_data нужно в цикле снова вызывать cat test_data|myprg.
Или в проге написать открыть файл test_data, прочитать, закрыть и снова открыть файл test_data ....

протестируй в tmux в отдельных окнах запусти

while :;do cat test_data;done

echo "хи-хи-ха-ха">test_data

#define STDIN 0

А почему 0? А что это за макрос?

getc

А ты случайно с char *gets(char *buf); или getchar() не путаешь?

С другой стороны зачем так сложно, вот у тебя

int argc

Номера строк.

char **argv

А это массив того что ты cat’ом туда загоняешь.

Ну или я тебя. test_Data уже содержит данные (строку «привет мир», но не важно). Тест нужен для того, что бы прочитать это строку побайтно (кодировка ansi) , передав её через пайп. Это будет означать, что алгоритм верный. Читаю и передаю cat’ом. Цыкл в пироге есть, да, когда, читаю байты. С открытием файла и чтением проблем нет, но хотел читать через пайп. Всё получилось.

STDIN, это я так stdin определил, потому, что нельзя быть уверенным, что stdin_fileno не переопределят.

Gets же строку читает, не не путаю.

Насчёт argv, а если бинарные данные передавать? Там же будет. 00 argc её посчитает?

Просто везде пишут дискриптор, когда это указатель

Дескриптор это не указатель. Это внутренняя структура в ядре, описывающая файл. Которая идентифицируется со стороны пользовательского процесса числом. А FILE это вообще никакого отношения к ядру не имеющая структура уже в libc. Внезапно, но libc может работать и не в юникс системах, где работа с файлами может быть организованно как-то по другому. Но т.к. libc предоставляет абстракцию в виде FILE то это делает код переносимым

У меня roxterm.

Сбило с толку, что fgetc(file* высокоуровневая обёртка над read(fd,…), это значит, что file содержит какую-то инфу о fd и конвертация file -> fd должна быть в libc, надо смотреть fileno. План такой.

это значит, что file содержит какую-то инфу о fd

Оно содержит этот самый fd в том числе, а ещё буфер. Когда ты делаешь fgetc оно читает не 1 символ, а сразу целый буфер, а потом отдаёт по одному в следующих вызовах fgetc и т.п. Но вникать во всё это не надо, и тем более как-то это использовать. libc даёт тебе заранее настроенный указатель STDIN. Всё, больше никуда лезть не нужно.

Вот нашел: libio/iolibio.h

#define _IO_fileno(FP) ((FP)->_fileno

Это значит, что File содержит дискриптор в _fileno. Похоже, что мне хотелось странного получить File из fd, но такой функции нет. Из File можно fd получить, а обратно - нет, стандартными способами во всяком случае.

Но Вы же в этом разбираетесь, Вам зачем это понадобилось?

Да и в лекции

https://yztm.ru/epo/epo_z6l5/ Профессор говорит, что «Каналы не могут использоваться в качестве средства межпроцессного взаимодействия между независимыми процессами.» Но если форкнуть дочерний процесс, все можно. А оказывается можно и так читать. Это какой-то другой канал? Или выкинуть нафиг эту лекцию. Так и появился код выше, идея была такой: форкаю процесс, sh конвертит fd в file* и fgetc(fd) сработает нормально. Хотел на него всю работу свалить.

Я не понял, что ты хочешь и зачем, ну вот например можно так:

#include <stdio.h>


int main(int argc, char **argv)
{
    char sym;
    int count = 1;
    while ((sym = getchar()) != EOF)
    {
        printf("%d %c\n", count++, sym);
    }
    return 0;
}

Вам зачем это понадобилось

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

Но если форкнуть дочерний процесс, все можно

Не можно. Дочерний процесс, это не независимый процесс. Он наследует дескрипторы родителя и разумеется через них он может с родителем общаться. И речь тут идёт про неименованные каналы. Именованные каналы на то и именованные, что их по имени может открыть любой процесс.

Так и появился код выше, идея была такой: форкаю процесс, sh конвертит fd в file*

У тебя какая-то каша в голове до сих пор. Ещё раз, не надо мешать в кучу fd и FILE*. Это разные интерфейсы работы с файлами. Внутренне они связаны, но лезть туда не надо. Используй что-то одно. При чём тут шелл вообще непонятно. Шелл тебе инициализирует стандартный ввод-вывод, libc для работы с FILE* сама тебе даёт FILE* STDIN/STDOUT для этого ввода-вывода. Т.е. тебе для этого не надо делать вообще ничего.

Для понимания как это работает. Если ты хочешь просто потыкать палкой, тогда конечно вперёд.

Я следую Федеральной программе импорта замещения одобренной правительством РФ :)

Я имел в виду, что не нужно это использовать в прикладном коде.

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

Не можно. Дочерний процесс, это не независимый процесс. Он наследует дескрипторы родителя и разумеется через них он может с родителем общаться. И речь тут идёт про неименованные каналы.

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

У тебя какая-то каша в голове до сих пор.

Я меня план все разложить по полочкам.

Ещё раз, не надо мешать в кучу fd и FILE*. Это разные интерфейсы работы с файлами.

У меня программа на c.

Внутренне они связаны, но лезть туда не надо.

Что за буфер создаёт libc при инициализации структуры file?

Используй что-то одно.

А можно хотя бы библиотеки прилинковывать?

При чём тут шелл вообще непонятно.

См. выше.

Шелл тебе инициализирует стандартный ввод-вывод, libc для работы с FILE* сама тебе даёт FILE* STDIN/STDOUT для этого ввода-вывода. Т.е. тебе для этого не надо делать вообще ничего.

Есть промт для нейросети про эту инициализацию?

П.с. Как квотирование делать?

Это ошибка компилятора gcc явного преобразования типа из int в File* нет, но программа компилируется, это значит мне полагается вознаграждение. Кто там gcc занимается? Столман-пидарас?

Столман-пидарас?

Нет, это ты - дебил.