[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

echo "string" > /dev/lp0 vs cups



День добрый.

Пишу прогу (ansi C) которая, среди всего прочего, должна печатать на
матричном принтере некое подобие лога.
Простая запись в /dev/lp0 "что-то там\n\r" дает приемлемый результат, за
исключением одного НО. Если принтер выключен на момент запуска
программы, выполнение останавливается пока что-то (в данном случае
принтер) не прочтет данные с паралельного порта. Предполагаю, что данная
проблема решается записью данных не прямо в порт, а в некий спулер.

Писать свой спулер (для данной задачи) не интересно, поэтому я решил
использовать что-то стандартное, например cups (одним махом решая
пробелму распечатки на удаленном принтере). Установил, принтер завелся
со второго раза, работает удовлетворительно, но я совершенно не понимаю
с какой стороны к этому делу подступится на предмет распечатки не файла
(как заведено) а string.

Посмотрел http://www.cups.org/doc-1.1/spm.html#CUPS_API
Там прямым текстом написанно: The CUPS API library provides some basic
printing services for applications that need to print files.
Очень не хочется писать строку в файл а потом его распечатывать, и
системный вызов echo "bla bla bla" | lpr -l кажется неспортивным.

Скажите, я хочу странного? Как можно загнать не файл а string в spool на
распечатку, не прибегая к системному вызову, и чтобы страницу не
выплевывало а переводило каретку и ждало следующей строки?

Еще заметил неприятную вещь: если что-то послать на печать при
выключенном принтере, а потом его включить, то съедаются первые буквы
(1, 2 или 3 исходя из моих тестов), и это происходит независимо от
метода печати (lp, lpr, просто эхо на /dev/lp0). Только у меня так, или
  у паралельного порта такая фича? Я понимаю, нефига игратся с
тумблером, но все-таки хочется по возможности избавится от подобных потерь.

Спасибо.



Reply to: