Можно ли скрыть вывод не перенаправляя в /dev/null

Я не в курсе последних нововведенией, но обычно в chroot распаковывали stage3, а он содержал /dev/null и т.д.

скрипт, устанавливащий gentoo в lxc-контейнер не такой (не знаю, почему)

чё мешает втупую создать devnull в произвольном месте файловой системы ??

mknod FILE_NAME c 1 3

А зачем? Задача же не сделать чтобы работало тяп-ляп, а сделать, чтобы работало хорошо, во имя Луны.

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

#!/bin/sh
blackhole() {
    while read L; do
        true;
    done
}
{
    echo '123';
    echo '456';
} | blackhole

Спасибо.

Я так и не понял что страшного в том, если pipe не будет вычитываться. Ведь то, что выше писали про SIGPIPE - оно было про сокеты. А это другое.

По идее заблокируется вывод в stdout/stderr вышестоящей команды. Но лучше перепроверить.

заблокируется вывод в stdout/stderr вышестоящей команды

Почему? вышестоящая будет записывать в pipe,
а эти самые pipe - они безразмерные, разве нет?

https://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer

grem - смотри пост выше (пользователя neumond) и учись как надо отвечать на вопросы.

Набросал простую программу чтобы проверить:

import sys
from itertools import count
k = 100_000
for i in count():
    if i % k == 0:
        print(i // k, file=sys.stderr)
    print(i)

Результаты такие:

python3.10 pt.py | blackhole
# всё нормально

python3.10 pt.py | true
# [Errno 32] Broken pipe
# true сразу завершается и закрывает stdin

python3.10 pt.py | sleep 3600
# блокируется, дальше 0 не идёт, буфер не безразмерный

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

https://stackoverflow.com/questions/49837534/what-do-1-000-and-100-000-mean

Вы сейчас напоминает мужика из этого анектода https://baneks.site/в-исполком-поступило-заявление-мужчина-жаловался/

Нашли скрипт, который хочет tar.bz2 архив, но кормили ему tar.xz, потом поняли, что скрипт расчитна на openrc систему инициализации, но пихали ему llvm-systemd, а теперь во всём виноват /dev/null.

Судя по вашему выхлопу, скрипт lxc-create пытается установить gentoo нормальным путём — через скачивание stage3. Сейчас не поленился, скачал файл http://distfiles.gentoo.org/releases/amd64/autobuilds/20221114T111652Z/stage3...
Там есть файл-устройство /dev/null. Получается, что вы изобретаете альтернативный способо установки gentoo, вам остаётся только страдать.

А если уж пошло дальше, то emerge обыно запускают от root, если от root выполните любую команду с перенаправлением в /dev/null, при размонтированом /dev, то будет просто создан обычный файл /dev/null. Раз у вас выскакивает ошибка, значит и каталога /dev нету. Дальше от вас будет тема: «сделайте мне систему без /dev»?

Во-первых, всё это надо было писать в той теме, а не в этой. Во-вторых, в вашем сообщении фактические ошибки. Дальше можно и не обсуждать.

всё это надо было писать в той теме

Ктож знал, что всё так зайдёт так далеко. Там казалось, что вы умеете читать слова на английском, и что stage3 в начале имени архива вам понятно.

в вашем сообщении фактические ошибки

Ну укажите на них, чтобы остальным форумчанам и гостям было понятно.

это где это нет нулевого файла?

дык пишешь в сборочный скрипт создать dev_null вот прям здесь. и все океюшки, ты не зависишь от замудрений дистропейсателей !!

ТС не ответил на комментарий от token_polyak, но похоже, что у него всё стопорится на том, что emerge делат проверку, что /dev/null это файл-устройство. Из этого начались фантазии про идеальный emerge, который не должен ничего прятать, а вести полный лог и т.д. Никакой сборочный скрипт ТС писать не собирается.

Уверены, что ваш blackhole работает быстрее, чем sed -d или grep .^ ?

Задачи сделать быстро не было. Там требуется только sh, даже не баш, без каких-либо внешних программ, насколько помню read и true встроены. Так-то шелл не самая быстрая вещь на свете.

Там требуется только sh

Он еще где-то остался?

В докерах. Да и зачем что-то большее? Разве что заменить на fish.

Моя цель в том, чтобы emerge работал как обычно, но не падал с ошибкой из-за отсутствия /dev/null.

Соя цель, чтобы emerge работал как обычно, но не падал с ошибкой из-за отсутствия python/bash/linux/поддержки elf/etc...

Там требуется только sh, даже не баш

Странное требование, особенно если учесть что ТС начал тему про emerge, написаный на питоне и занимающийся сборкой gentoo. grep/sed входят в stage3.

насколько помню read и true встроены

″read″, понято, встроен, по другому быть не может, он же переменные выставляет. А ″true″, ИМХО, встроен в меньшее число shell'ом, чем ″:″, про которое в этой теме уже писали.

От балды первое что в голову пришло

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    while(getc(stdin) != EOF);
    return 0;
}

dron@gnu:~/Рабочий-стол/null$ gcc main.c -o null
dron@gnu:~/Рабочий-стол/null$ ls  | ./null 
dron@gnu:~/Рабочий-стол/null$ 

Можно ещё создать файл /dev/null и перенаправлять вывод в него как обычно $command > /dev/null попутно запустив программу в фоне которая по fstat будет проверять его изменения и как только они произошли перезаписывать файл пустотой. Но эт такое себе. Лучше отправить в пайп который просто ничего не делает со своим вводом.

Мозгодробильный конечно этот :, не знал что такой есть. Да, в моём примере лучше его использовать, это более настоящий no-op, чем даже true, который у меня в системе аж целый бинарь.

Странное требование

Да в целом странное требование отсутствующего /dev/null. Но познавательно, всякие mknod, которые наверное никогда в жизни не пригодятся.

python меняем на C++, получаем cave из exherbo
bash меняем на power shell, например, получаем caffe.clr
linux меняем на freebsd, получаем ports
elf на coff, получаем windows

Всё в общем реально, не знаю, почему такое негодование.

Иметь число башевое решение (с read и :) это круче, чем использовать sed или grep. Потому что есть они в stage3 или их там нет - это зависит от того, кто тот stage3 собирал.

вместо того, чтобы, черт побери, сразу указать, что тебе (вероятно) emerge сообщает

Потому что меня заинтересовал вопрос технической возможности проделать это в принципе, а не в той конкретной ситуации. Я задал вопрос так, как мне показалось наиболее правильным. Получил ответ, который меня полностью устраивает. И только вам что-то постоянно не нравится.

Никакой сборочный скрипт ТС писать не собирается.

Верно

начались фантазии про идеальный emerge, который не должен ничего прятать, а вести полный лог и т.д.

ну да. Правильные же мысли.

Между прочим, ещё никто не рассказал, зачем нужны все эти /dev/* для emerge, почему без них нельзя обойтись.

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

зачем нужны все эти /dev/* для emerge, почему без них нельзя обойтись.

Потому что это усложнит сам emerge(реализовывать «свой» /dev/null, когда есть готовый) с одной стороны и урежет его функциональность(как без доступа к /dev/ посчитать объём доступного пространства на /tmp/portage и как без доступа к /proc/ управлять порождаемыми в процессе потомками и проверять параметры досутпности на запись разделов?). И это только на самый-самый первый взгляд даже без закапывания в исходники.

На прошлой неделе мне пригодился mknod на работе для фикса одной специфичной баги. :)

Ну укажите на них

Я дополнил ту тему правильным вариантом команды. А вы не смогли со всем своим «навыком в английский».

В коде emerge два комментария по этому поводу:

# Verify that /dev/null exists and is a device file as a cheap early
# filter for obviously broken /dev/s.

# Verify that BASH process substitution works as another cheap early
# filter. Process substitution uses '/dev/fd'.

emerge не собирает пакеты, по сути всё что он делает — это запуск ebuild в нужном порядке. ebuild тоже делает немного работы. В основном сборку (компиляцию) пакета организует его разработчик, как ему захотелось, всякими autotools, cmake и т.д.

И это всё написано исходя из того, что /dev/null, /dev/zero, /dev/urandom — это файлы-устройсва. Никто не хочет всё это переписывать, тестировать на корректность работы без /dev/null и т.д.

Раз нет никакой уверености, что сборка всех пакетов пройдёт без ошибок в отсутствии /dev/null, разработчики emerge считает, что лучше не давать запустить сборку в таких условиях, чем потом разбираться непонятно с чем. Народ ведь начнёт постить сообщения о ошибках...

То есть emerge особо не нужен /dev/null, но переписывать весь софт, чтобы он обходился без /dev/null разработчики gentoo не хотят.

То есть emerge особо не нужен /dev/null

Так и софту при сборке он тоже не нужен. И даже если подумать - всё равно не нужен. Ну вот просто незачем при сборке что-то глушить (вместо того, чтобы фильтровать).

по сути всё что emerge делает — это запуск ebuild в нужном порядке

А тут выше писали, что emerge проверяет размер свободного места перед установкой. Значит не «просто запуск».

Но я не знаю точно, достаточно ли для проверки свободного места на дисках только /proc или нужен таки /dev.

всё написано исходя из того, что /dev/null, /dev/zero, /dev/urandom — это файлы-устройства

Всё - это что конкретно? Ни один пакет всё это наверняка не использует при сборке. Может быть каталист, но не при установке, а при работе. И то это неточно.

configure скрипт, который от аutotools, весь напичкан /dev/null, причём там не только >/dev/null, а именно использование свойства файл-устройства /dev/null, что из него ничего нельзя прочитать, например (из glibc):

ac_cs_awk_cr=`$AWK 'BEGIN { print "a\rb" }' </dev/null 2>/dev/null`
...
if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then

# On cygwin, bash can eat \r inside `` if the user requested igncr.

Классический способ создать файл нужного размера — это dd if=/dev/zero of=, его использует memtest86+ для создания образа загрузочной дискеты.

В исходниках ядра есть файлик randstruct_hash.h, который создаётся при компиляции с чтением байт из /dev/urandom.

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

Четыре примера, то есть использования можно пересчитать по пальцам одной руки. И ни одно из них не среди прикладных программ - главного, что интересует пользователя.

configure скрипт, который от аutotools

Это, конечно, засада. Но в этой теме мы же уже выяснили, что исправимая. Из true или : тоже ничего прочитать нельзя.

Тебе же написали, что это первое попавшееся. Ну и в gentoo считать не прикладными autotools и ядро linux - странно как-то.

Хочется больше - во многих пакетах используются тесты сразу после сборки. И во многих тестах по понятным причинам используются /dev/{null,urandom,zero}. Из развёрнутого у меня сейчас бегло глянул по сырцам udev, например.

Это, конечно, засада. Но в этой теме мы же уже выяснили, что исправимая. Из true или : тоже ничего прочитать нельзя.

Ты не понимаешь что ли, что это вопрос не к авторам portage, а к авторам непосредственно софта? Ты их хочешь заставить переписывать свой софт, отказавшись использовать имеющиеся стандартные элементы окружения.

Значит не «просто запуск».

Доступное место ebuild проверяет. Это тоже часть portage, если что.

Я так и говорил, что portage проверяет. Если ебилд это часть portage, значит всё верно, ошибок нет.

Однако как именно он это делает - тайна, незадокументированая разработчиками.

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

Ты уверен? Прочитал всю документацию по portage/emerge/ebuild/etc?

А потом ещё документацию на список используемых в portage утилит?

Если мне эта информация в глаза сама не лезет, значит система информирования пользователей непроработана. Гиперссылку на документацию должны были выдать из кода программы ещё в сообщении про /dev/null.

Аналогично, при проверках места тоже должно быть приписано, где читать подробнее.

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

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

главного, что интересует пользователя.

Пользователя, конечно, может не интересовать glibc, только мало какой софт без неё работает.

И большинство пользователей вобще не интересует gentoo, их устраивают готовые бинарные пакеты и им вобще без разницы был ли /dev/null на той машине, где собирали эти пакеты.

выяснили, что исправимая.

Кем исправимая? То, что можно всё форкнуть, написать заново и т.д. итак понятно, тему для этого создавать не нужно. Только никто этого делать не будет. А так есть ReactOS, где вобще нет /dev/ :)

пересчитать по пальцам одной руки.

Число патчей, исправляющих зависимость от /dev/null вобще равно нулю.

Плюс это примеры использования файлов-устройств при сборке. А при работе какой софт куда обращается это отдельная тема. А в gentoo много, если не большинство, софта компилируется только для того, чтоб компилировать другой софт. То есть сборка одного софта подразумевает работу другого софта. Ваше разделение:

но не при установке, а при работе.

некорректно.

Сделал новую тему, потому что вопрос этой темы был о глушении вывода.