Ты сам спросил как прочесть конфиг из stdin. Тебе ответили. Что именно ты не понял? Из stdout обычно нельзя читать, но если ты таки подсунешь туда дескриптор для чтения то -f /dev/stdout так же сработает.
Конфиг будет читаться из базы данных. Программа может его вывести но записывать в файл нельзя. Пусть будет примитивный cat config > /dev/stdin
Как его правильно перенаправить в xbindkeys?
У меня не укладывается в голове
2) Что было непонятно с stdin? Я понимаю если ты задал другой вопрос и тебе бы написали про /dev/stdin и ты не знал куда его засунуть. Но ты же сам спросил про stdin, а когда тебе таки ответили - стал спрашивать как он работает. Как такое могло случиться?
xbindkeys -f config это запустит xbindkeys с параметрами в config. Твой вариант не запускает xbindkeys, не знаю почему
Что было непонятно с stdin? Я понимаю если ты задал другой вопрос и тебе бы написали про /dev/stdin и ты не знал куда его засунуть. Но ты же сам спросил про stdin, а когда тебе таки ответили - стал спрашивать как он работает. Как такое могло случиться?
Думал что понятно куда нужно засунуть, но не работает всё это. Я рассчитывал на пример, а не просто xbindkeys -f /dev/stdin - так и я мог написать, но по факту stdin пусткой когда xbindkeys его читает. Вопрос и состоял в том что бы как-то пропихнуть конфиг что бы xbindkeys его прочитал из stdin.
А /var/log предназначен чтобы в него скидывать логи. Так давай туда будем писать логи обновления системного таймера (каждое изменение текущей секунды).
Из того, что tmp предназначен для временных файлов, не следует что эти самые временные файлы надо злостно создавать даже там, где они не нужны. В данном случае - не нужны.
1) Повторю вопрос: что значит «не запускает»? Ты специально скрываешь «симптомы» чтобы всех позлить, или по глупости считаешь их несущественными? Если есть проблема, описывай её полностью - что именно происходит после запуска команды, что ты ожидаешь, и в чём разница между ожиданием и реальностью. Ответ «ничего не происходит» явно неверный - как минимум курсор переставляется на следующую строчку от нажатия энтера и выводится приглашение к вводу следующей команды. Иными словами, пиши не свою интерпретацию происходящего (оно не запустилось), а строгие факты (на экране не хватает такой-то надписи, или наоборот есть лишнее сообщение об ошибке, при нажатии хоткея то-то не произошло, итд, можешь скрином если по-другому сложно).
2) stdin это поток стандартного ввода; если ты просто запустил команду саму по себе - оно вводится с клавиатуры, если сделал редирект через «< filename» - из указанного файла, если сделал конвеер («|») - из вывода предыдущей команды конвеера.
Пример cat config можно заменить на просто prog.sh
некая программа выводит конфиг в таком виде как если бы его вывел cat config записывать конфиг в файл нельзя - это условие программы. xbindkeys может читать только файл, я не понимаю как ему скормить вывод вместо файла.
Может быть вы отлично соображаете что происходит при этом, но доходчиво это объяснить, что бы было понятно - вы не можете. Если я вас не понимаю, это не значит что я тупой, вам нужно лишь более структурированно излогать свои мысли.
если ты просто запустил команду саму по себе - оно вводится с клавиатуры
как можно понять о чём идёт речь? какую команду запустить, что «оно» вводится с клавиатуры?
если сделал редирект через «< filename» - из указанного файла, если сделал конвеер («|») - из вывода предыдущей команды конвеера.
если сделал то, да это, ну а в итоге то что происходит «если сделал» то и это? Смешно правда. Для вашего уровня задача смешная, но вы вместо примеров предлагаете, на понятном только вам языке, изучить природу stdin и pipe
как можно понять о чём идёт речь? какую команду запустить, что «оно» вводится с клавиатуры?
Если ты запустишь любую прогу, дав ей указание читать /dev/stdin - она будет читать клавиатурный ввод. Если ты сделаешь тоже самое, только с редиректом ввода через < или | - она будет читать данные из этого редиректа. /dev/stdin это не файл с данными на диске или в памяти, это ссылка на поток входных данных команды (повторю: тот самый, который в интерактивной консоли по дефолту берётся с клавиатуры и может быть перенаправлен с помощью <).
Ты же этот скрипт как пример привёл, в реальных данных очевидно будут не три строчки и 18 байт. А размер буфера в локальных пайпах по дефолту неожиданно маленький, сам несколько раз натыкался.
В фон, чтобы записываемые данные сразу кто-то читал, иначе тот кто пишет может зависнуть с фулл буфером. И нет, гонки там не будет (хотя некоторые отличия от настоящего файла будут - например частичное чтение без eof, и теоретически плохо написанная прога может от этого сломаться, но с тем же успехом она может сломаться от неработающего на пайпах lseek).
размер буфера проверяется и регулируется при помощи getconf. считать конфиг сначала из stdin и оценить размер при помощи wc - тоже как два байта переслать. да, «код», который я привел - это PoC. мне не западло показать студенту, куда рыть, но и лабу всю за него делать не буду
размер буфера проверяется и регулируется при помощи getconf. считать конфиг сначала из stdin и оценить размер при помощи wc - тоже как два байта переслать
Это всё круто, но зачем столько лишних действий, когда можно всё сделать в одно?