Общаемся обо всём!

[Dale]

В Юникоде первые 256 кодовых позиций совпадают с ISO-8859-1.
Очередной костыль, который прикрутили к исконной ASCII, дабы позволить унтерменшам приобщиться к великой американской идее.

Не костыль, а всего лишь расширение кодовой таблицы. Да, ASCII находится в самом начале Unicode, но должно же что-то быть в начале, там не может оставаться пустота лишь для того, чтобы унтерменшам не было обидно. Если бы эфиопы или зулусы заложили основы компьютерной науки, их алфавит вполне заслуженно возглавил бы кодовую таблицу, но сложилось так, как сложилось. Те, кто качались на хвостах на верхушке пальмы во времена создания первых ENIAC'ов, сегодня довольствуются хвостом таблицы.

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

Для создания пользовательского интерфейса - не любая. Только ОС, предназначенная для персонального компьютера либо рабочей станции. ОС реального времени для встраиваемых систем такая роскошь ни к чему, равно как и серверной ОС.

ОС действительно должна предоставлять набор вызовов, достаточный для выполнения ее функций. Успешные ОС так и делают, остальные уходят в мусорник. Так и должно быть.

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

Нет в C#, если речь в данном случае о нем, таких нюансов. Сказки про его якобы низкую производительность тоже давно забылись. Не живут неудачные языки в наше время столько лет, да и пятое место в рейтинге TIOBE говорит за себя.

решения в виде c# - политика более, чем наука.

C# - это и не политика, и не наука. Это лишь язык программирования, один из многих. Если на языке трудно и неудобно программировать, никакая политика не удержит его на плаву. Можно искусственно заставить писать на нем, например, военных, госструктуры и прочие подневольные организации. В бизнесе все решает скорость разработки и удобство обеспечения качества кода. Было бы мне сегодня проще решать мои задачи на COBOL'е или FORTRAN'е, никакая политика не удержала бы меня от этого. А вот здравый смысл надежно удерживает.

[Aether]

В некотором смысле стратегия подстроиться под имеющееся проигрывает стратегии делать лучшее. То есть, на государственном уровне я вижу, что люди пытаются удивить изобретениями, например, вот наш процессор на 750МГц, к слову, производительность в DMIPS может быть и выше, чем у пентиума на 1500МГц, но ладно. Главное, что упускаются, казалось бы малозначимые вещи, и, тем не менее, вещи эти серьёзные. Не решив их - нет прямого пути вперёд.

Что касается кодовой таблицы, да первая страница не должна быть пустой, как и говорил её имеет смысл заполнить символами и управляющими элементами. Например, вот такой нюанс: какой использовать терминатор строки? С точки зрения упрощения низкоуровневого программирования имеет смысл начало заполнить цифрами:
0x00 = '0'
0x01 = '1'
...
0xF0 - переключение на режим "слева на право" (по умолчанию)
0xF1 - переключение на режим "справа налево"
0xF2 - переключение шрифта на нормальный вид (по умолчанию)
0xF3 - переключение шрифта на утолщённый вид
0xF4 - переключение на шрифт надстрочного индекса
0xF5 - переключение на шрифт подстрочного индекса
...
0xFE - переключение кодовой страницы, далее следует 64-битный код требуемой страницы. При невозможности отображения какого-либо символа, он отображается служебным знаком 0xFD, например.
0xFF - терминатор строки или абзаца.
Так вот, категория управляющих символов 0xF? должна проходить насквозь всех страниц во избежания некоторых ошибок. Также не стоит строить сложно составные символы, например, ангстрем, собирая его из латинской А и кружка. Один символ - один код. И ещё: система рендеринга текста должна уметь определять где находится символ, и соответственно его видоизменять в зависимости от того в начале он слова, в середине, конце или перед какой-то нужной буквой - суть система, при этом в кодовой странице он должен быть под одним номером.

Ну, это и да и нет, конечно, для микроволновки с интерфейсом на базе семисегментного индикатора не имеет смысла предоставлять графический функционал ядра, однако, как только появляется дисплей он нужен. Даже тот же ЧПУ и АСУТП раздел в современном представлении без графики виден плохо. Возможно, нужна гибкость, например, перекомпиляция ядра с флагом вычета библиотеки - для случая экономии памяти.

С# - это хорошо, когда интерфейс нужно сделать быстро и на Windows, хоть есть ещё Mono, но это на любителя. А так сами посудите: идёт рендеринг или расчёт методом конечных элементов... Вы обращаетесь к элементу массива, и каждый раз система перехватывает обращение, проверяет лимит индекса, проверяет тип элемента, преобразует индекс в адрес, получает число из собственного изолированного адресного пространства, и далее передаёт его приложению - это не просто медленно, а как минимум на порядок. Ещё и памяти съедает немерено. Просто для типовых задач обслуживания главного цикла приложения, работы с периферией, не требуется больших объёмов вычислений, и поэтому низкая производительность не видна пользователю.
Нюансы - это ссылочные и значимые типы. По идее все типы должны были бы быть ссылочными и проходить через систему, однако, дабы сэкономить память и повысить производительность был приделан механизм, когда размещение можно делать вне управляемой кучи. Был определён оператор struct отличающийся от class - не путать с "С++".

[zubr]

Aether, начинать сейчас менять, к примеру, кодовую таблицу, ну это примерно то же самое как в фильме "Операция Ы" Вицин вытаскивает ночной горшок из стопки из самого низа. То есть посыпится все, что сейчас работает, начиная от ПО, кончая железом.
По данной теме, одна из бед Советской экономики, имхо, это пренебрежительное отношение к таким понятиям, как стандартизация, унификация. Кроме ГОСТов, стандартов СЭВ, были еще ОСТы (отраслевые стандарты), а еще на каждом предприятии СТП (стандарт предприятия). Вот и выходило порой, что на каждом отдельном предприятии изобретали свой велосипед - в итоге, к примеру, токарь на универсальном токарном станке точил болт, вместо того, чтобы предприятие получало стандартные болты от предприятия, выпускающего их на автоматическом оборудовании. Только потому, что конструктор данного предприятия решил, что изобретенный им болт, лучше стандартного.

[Aether]

Не соглашусь, это не идти вопреки, и вынимать тарелку, а строить собственную стопку. Тому же Microsoft не мешает и не жмёт поддержка только широких символов до 16 бит, хотя, как мы знаем, UTF-8 ориентирована на символы вплоть до 32-х бит. А всё потому, что там знай гнут свою линию, и не смотрят где и чья стопка при этом упадёт. С их позиции такие вещи, как UTF сделаны для того, чтобы пресечь конкурентов на том же поприще.
Приведу пример, наверняка знакомые поверхностно с английской системой мер задавались вопросом: почему фунт обозначается lb? А потому, что lb - это с латинского либра, то есть гиря, и гирь таких в каждой стране было тьма. В итоге, Европа перешла на грамм, отказавшись от своих исторических мер ради комфорта. Также происходит и с наукой в целом: при накоплении определённого потенциала знаний возникает потребность в пересмотре ранее имевшихся стандартов - это называется оптимизация, цель её - это снижение издержек, которые, накапливаясь тормозят экономику.

Проблема СССР не в стандартизации, к слову говоря, многое, что у нас, что у них сделано верно, ибо продиктовано чёткой нуждой. Например, у нас и у них есть крепёжная резьба и болты под неё, также есть трубная, но мало кто знает, что у нас в авиации ещё 8 видов резьб, и у них примерно столько же. Дело не в стандарте, а просто для соединения высокопрочного алюминия (В95) с высокопрочной сталью (30ХГСН2А) без особого профиля невыгодно с точки зрения массово-прочностных показателей. Фишка в том, что решение должно быть продумано, а сейчас как раз велосипед и рисуют, но не просто так, а чтобы продать его дважды и трижды. К примеру, тот же HTML - нельзя в тексте ASCII сделать разметку, сделали костыль, под него написали специализированное ПО, выпускают новые версии, заставляют конечного потребителя выбирать это, а не альтернативу - эффект маховика. Далее, HTML стало мало, появились у каждой конторы свои субпродукты: XPS, XML... Тоже в графике, есть DXF, SVG, IGES, WMF, EMF - реализует одно и то же, только конторы разные.

Нам с Вами, как инженерам, конечно, с одной стороны - не наш уровень, а с другой "что прикажут, то и делаем", и таки сделаем. В то же время поговорить об этом нужно, я думаю. А людям, которые продвигают продукты на государственном уровне лучше было бы не только думать об этом в свободное время, но и заниматься этими задачами профессионально, а не создавать успешные псевдорешения для получения диссертаций, льгот, мест под Солнцем...

[zubr]

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

[Aether]

Зачем так категорично: либо раз, либо два. Всегда есть и три, и четыре. Если кто-то продвигает своё - никто не мешает также гнуть свою линию. Порой люди забывают, что компьютер - это инструмент по обработке информации. Средний пользователь, а таких большинство, пользуется ради: послушать, посмотреть, написать, позвонить. Каждая компания обновляет ветку продуктов с циклом 2-3 года, а значит не так всё относительно трудоёмко, как кажется. Была бы цель, и средства. Та же оборонка варится, и ничего, обидно, что их (западные) изобретения кочуют в гражданский сектор, а потом к нам, а наши нет. Возьмите дизель - их Common Rail является современной системой впрыска с гидроаккумулятором и прочей хитростью, которая позволяет значительно повысить эксплуатационные показатели, унифицировать ремонт... А изначально делалась для танков и тягачей... Теперь её ставят и на КАМАЗ...

Я всё таки считаю, что не решив, и не поставив нужным образом фундамент, невозможно рассчитывать на серьёзный успех. Всё упрётся в копирование, тщетные попытки догнать, и приспособить под свои нужды. Мне смешно, когда говорят: "Вот, раз, два и мы откажемся от Visa и сделаем свою платёжную систему..." Мда, когда даже элементной базы своей нет, идут рассуждения о задачах четвёртого и пятого порядка. В лучшем случае систему купят в Китае, и будет их, адаптированный костылями, ChinaCard. Естественно, всё это будет сопровождать эпический отмыв на фоне модернизации, и банальное воровство на фоне списания старого оборудования.

[zubr]

Те же Китай и Южная Корея мало чего своего изобрели, но опираясь и копируя западные технологии уже почти догнали их, а кое в чем и перегнали.
Казалось бы, все просто - есть задача, есть цель, есть уже готовые решения. Для быстрого решения - применяй эти готовые решения и получай прибыль. У нас же не не так, у нас все сложно - мы пойдем своим путем. Идеологи вон по сей день третий путь ищут.

[Aether]

Вот именно, они сначала стали делать компоненты, затем периферию, затем продвигать свои стандарты, сейчас и на процессоры покушаются.
У нас - покушаются с головы на процессор, игнорируя пустоту не только в другом, но даже в основах. Суть в нежелании потерять власть, чиновники изобретают пути для отмыва себе денег. Они не заинтересованы в бизнесе, и поэтому у нас даже нет нормальных работающих юридических законов в гражданском секторе - это да. Ваш уже отличился, продвинув тему с тунеядством - то есть на деле сократил путь к изъятию денег до кратчайшей прямой линии.

Чем мне не нравятся мега компании - даже за деньги ты получаешь продукт с косяками. Каждый раз, будь-то Microchip или Atmel изучение идёт: читаем даташит, следом эррату, и там... Нас ждут танцы с бубнами, хороводом негров... Дело не в косяках самих по себе, просто мы то и дело покупаем старый продукт в новой обёртке.

Вот почему Linux проект там развивается, а у нас такие проекты нет?

[Dale]

Вот почему Linux проект там развивается, а у нас такие проекты нет?

А что можно украсть на таком проекте? Это же не зимняя олимпиада на южном курорте и не космодром на Востоке. Нет заинтересованных людей - нет и развития.

Разве что отдельные энтузиасты вроде Дениса Попова.

[zubr]

Ваш уже отличился, продвинув тему с тунеядством - то есть на деле сократил путь к изъятию денег до кратчайшей прямой линии.

Облом произошел с этой темой. Расчет был на 400 тыс. тунеядцев, а выявили только 70 тыс. Налог оплатили только 30 тыс., остальные показали кукиш. Теперь закон спускают на тормозах, принято решение с каждым тунеядцем разбираться индивидуально (тунеядец-не тунеядец) на местном уровне. Просто кое кто не хочет признавать своих ошибок.

[RXL]

Aether, ты вот все напираешь на "все сломать и сделать заново". Посмотри внимательно на ПО долгого срока жизни: ты думаешь, что версия 1.0 не имеет ничего общего с 10.0? Заблуждение! Это тот же самый 1.0, в котором часть кода была переписана, часть удалена, много дописано дополнительно, но не мало строк живут со времен 1.0 и являются частью архитектуры приложения. Взять и переписать все с нуля, это извечная идея фикс: иногда только так и нужно, если имеющаяся архитектура просто швах, иногда можно, но не обязательно, т.к. что переписывать, что поддерживать старое — равноценно по сложности и цене, но, как правило, полное переписывание дороже и требует много времени, а главное, не гарантирует, что новый путь не такой же ущербный. Если есть необходимость в продукте Б, реализующем часть функционала продукта А и плюс еще свой специфичный функционал, то лучше написать этот продукт и пусть они конкурируют. Это эволюция. По этому так много форматов файлов и параллельных стандартов.

[Finch]

На какой рынок оринтирован сей продукт. Рынок геймеров отпадает. Слишком не стандартный и медленный продукт. Хотя я видел ролик на youtube, в котором играют на нем в Doom 3. Правда еше ставят дополнительную видеокарту.  Рынок офисных и домашних ПК тоже отпадает. Намного превыщен 1000 баксовый предел. Рынок промыщленных ПК тоже отпадает. Исполнение его не предназначено для этого. Он хоть и является статусным продуктом. Но готовы ли фанаты "статуса" выкладывать суммы, сопостовимые с серверным оборудованием от Apple? Остается только рынок гос. закупок. Вопрос, готово ли государство выкладывать 200-300 миллионов долларов в год, чтобы хотя бы на 70-90 процентов закрыть производственные мошности?
Миф о его полной безопасности, только потому, что процессор не стандартный. Остается мифом. И очень опасным мифом. От целенаправленной атаки это не поможет. Тому пример история с управляюшей системой обогатительных заводов Ирана. Вроде закрытую сеть смогли внедрить опасный код, который выводил из строя оборудование.

[RXL]

Архитектура совсем не новая: MIPS32. Ядра процессора лицензированы у компании Imagination Technologies. Цитирую из Вики назначение этих ядер: "Предполагается, что на базе чипа будут создаваться различные сетевые устройства, например беспроводные маршрутизаторы, домашние маршрутизаторы, устройства промышленной автоматизации". Т.е. ПК не предполагался. По цене процессора он на изначально предполагавшемся рынке не конкурент никому. Для снижения цены нужны инвестиции и массовое производство.

[Aether]

Aether, ты вот все напираешь на "все сломать и сделать заново".

Я говорю: не сломать, а о том, что если стратеги задумываются о будущем, то это должно быть видно и понятно. Я как раз минимален в плане национализма - типа: построим великую российскую идею, и она всем обязательно понравится. Как раз такая идея лишена перспективы, как и американская, например, про что и речь.

Кстати, о "швах" - как кто относится к факту существования антивирусных программ?

[RXL]

А что не так с антивирусами? Изменение алгоритмов поиска вируса не меняет сути программы: проверка памяти процессов, проверка файлов, проверка своей целостности.

[Aether]

А что не так с антивирусами? Изменение алгоритмов поиска вируса не меняет сути программы: проверка памяти процессов, проверка файлов, проверка своей целостности.

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

Очень раздражает, когда системы типа Windows создают на диске теневые разделы, скрытые файлы и т.п. Моё мнение в том, что пользователь должен иметь возможность полного контроля своего информационного пространства, но человеческие способности ограничены, поэтому политика того, что всё должно быть простым и понятным - актуальна.

В Linux, как Вы сами сказали, "пользователю не запрещается гадить на диске" - то есть, механизм ограничения прав пользовательских процессов ещё не отточен до приемлемого состояния.

[RXL]

Я такое про Linux сказал? Не помню. Руту никто не запрещает, юзеру — где разрешено. И также в Linux полно всяго скрытого от юзера, включая скрытые файлы и разделы.

[Aether]

Я такое про Linux сказал? Не помню. Руту никто не запрещает, юзеру — где разрешено. И также в Linux полно всяго скрытого от юзера, включая скрытые файлы и разделы.

2. Вхождение в домен не запрещает юзерам гадить на локальный диск.

Сорри за мою терминологию, я под пользователем имею ввиду - пользователя ПК. В общем, Linux в режиме root позволяет увидеть всё, насколько я знаю, с Windows не так.

Тем не менее, мне вот интересно: зачем было в правах доступа создавать систему из трёх атрибутов: wrx? По поводу исполнения - это нечто, если я могу прочесть, значит могу скопировать, а если могу скопировать - могу запустить.

[RXL]

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

Концепция рута (суперюзера) наследована из ранних Unix. Когда это хорошо, а когда - проблема.

По правам: скопировать в свою домашнюю директорию и запустить. Если исходные права r - на здоровье. Обычно r оставляют для скриптов, чтобы интерпретатор мог читать файл. Что в этом не так? Если файл тебе доступен, то значит его от тебя и не скрывали. Скрытие было бы в директории, в которую у тебя нет доступа.

[Aether]

По правам: скопировать в свою домашнюю директорию и запустить. Если исходные права r - на здоровье. Обычно r оставляют для скриптов, чтобы интерпретатор мог читать файл. Что в этом не так? Если файл тебе доступен, то значит его от тебя и не скрывали. Скрытие было бы в директории, в которую у тебя нет доступа.

Так "х" то зачем, если его можно обойти... В общем, дублирование.

Кстати, а как он реализует эти аттрибуты? На уровне файловой системы? Или же создаёт какие-нибудь файлы-описатели? Мне просто интересна реакция, скажем, если создать раздел ntfs и на нём назначить разные права, затем записать на него что-нибудь через Windows...

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

[RXL]

Все понятно без лишних слов:
/bin (x-r x-r x-r root:root)
  bash (--x --x --x root:root) --- нормальная всем доступная бинарная программа
  normal.sh (r-x r-x r-x root:root) --- нормальная всем доступная скриптовая программа
  admin_mudak.sh (r-- r-- r-- root:root) --- у админа руки из жопы
  bash.bak (--- --- r-x root:root) --- видимо это тут временно, но с правами все путем (только рут)

Калитку без забора тоже можно поставить. Только зачем....

Атрибуты принадлежат inode. Также есть более новые расширенные атрибуты.
С NTFS не стоит сравнивать - у нее свои заморочки от MS.
Файловых систем много.

[Aether]

Все понятно без лишних слов:
/bin (x-rx-rx-r root:root)
  bash (x--x--x-- root:root) --- нормальная всем доступная бинарная программа
  normal.sh (x-rx-rx-r root:root) --- нормальная всем доступная скриптовая программа
  admin_mudak.sh (--r--r--r root:root) --- у админа руки из жопы
  bash.bak (------x-r root:root) --- видимо это тут временно, но с правами все путем (только рут)

Атрибуты принадлежат inode. Также есть более новые расширенные атрибуты.
С NTFS не стоит сравнивать - у нее свои заморочки от MS.
Файловых систем много.

Что-то много "-".

//директория - тип - права владельца - права группы - права остальных - владелец - группа
/bin d r-x r-x r-- root:root
  // root имеет право на чтение и выполнение
  // группа root имеет право на чтение и выполнение
  // остальные могут читать
bash - --x --x --x root:root
  // все могут выполнить, но не читать и не писать,
  // хотя почему нельзя читать - это на случай как раз скопировать и перезапустить?
  // Но зачем копировать, если и так запустить можем?
normal.sh - r-x r-x r-- root:root
  // Все могут читать, ну и bash по идее это может обработать - он же читает.
admin_mudak.sh - r-- r-- r--
  // Все тоже могут выполнить, но, как понимаю, у админа будет геморрой, если
  //потребуется изменить скрипт, тем более через sudo. Но это не смертельно?
bash.bak - --- --- r-x root:root

О, нет, я не сравниваю, просто в Linux есть поддержка ntfs, но не совсем понятно где ОС будет хранить параметры прав, так как в Windows это организовано иначе.

[RXL]

http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/

[Aether]

http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/

Спасибо, прочёл.

Ну, а по поводу у админа руки из жопы...
Я то думал:

normal.sh - rwx rwx r-- root:root

[RXL]

Тут я опечатался. Поправил пост.

[Aether]

  normal.sh (r-x r-x r-x root:root) --- нормальная всем доступная скриптовая программа
  admin_mudak.sh (r-- r-- r-- root:root) --- у админа руки из жопы

Тут я опечатался. Поправил пост.

Так я про что:
По идеи, но может и не прав: normal.sh, как и любой скрипт - это просто файл, просто текст... Как бы это не программа.
В свою очередь, исполнителем его является командный процессор, который доступен к исполнению. То есть он должен открыть доступный на чтение скрипт и его выполнить, аттрибут "х" при этом не нужен. Возможно, внутри, командный процессор сам проверяет на аттрибут перед выполнением - тогда, да, разница будет, а cat, например, проверять аттрибуты не будет...

[RXL]

В директории bin не должно лежать конфигов и сторонних скриптов. Это место для команд: запуск как somecommand, а не bash /bin/somecommand.sh
Вторичные вспомогательные скрипты обычно прячут в другие места: /usr/lib/.../, /usr/libexec/.../, /usr/share/.../ или еще куда. Запускают их не напрямую, а, к примеру, команды из bin.

[Aether]

... сторонних скриптов.

Немного хочу расширить познания. Вот есть, например, команда:

cat /proc/cpuinfo | grep -i 'Model'

Результат понятен, а путь нет. Я предполагаю, что командный процессор вызовет сначала cat, образуется поток данных для которого возможно будет создан временный файл, этот файл будет передан в grep, который извлечёт нужные строки. А в целом, что происходит с аргументами, куда и что поступает, и что возвращается? Интересует отработка именно: "|".

[RXL]

Это два дочерних процесса — cat и grep — соединенных однонаправленным каналом (pipe). Один конец трубы в качестве стандартного вывода cat, второй — стандартный ввод grep. Таким образом в цепочку можно соединить несколько процессов, где ввод с предыдущего обрабатывается и результат выводится в следующий.

Если детализировать происходящее, то родительский процесс создал pipe (выглядит как два файловых дескриптора - для записи и для чтения) и дважды сделал свою копию (fork). Первая копия закрыла свой stdout, на освободившийся номер дескриптора продублировала дескриптор трубы для записи, после оригинальные дескрипторы трубы закрыла, после чего запустила (exec) новую команду cat, которая наследовала файловые дескрипторы. Вторая копия делает похоже: закрывает stdin, на его место дублирует читающий дескриптор трубы, закрывает старые дескрипторы трубы и запускает команду grep. Родительский процесс ожидает завершения дочек. Когда пишущий процесс завершится, труба на его стороне закроется и читающий процесс распознает это как "конец файла" и сам закончит свои дела. Если же первым завершится читающий процесс (например из-за сбоя программы или такая логика, что нужное уже найдено и дальнейшая обработка входящий данных не требуется), то его сторона трубы закроется, а писать в закрытую трубу нельзя и пишущий процесс получит сигнал SIGPIPE.

[Aether]

Это два дочерних процесса — cat и grep — соединенных однонаправленным каналом (pipe).

Тогда как правильно писать приложения, вроде, grep... Получается как бы иллюзия, что мы работаем с stdin. Значит его надо анализировать, копировать в свой буфер до встречи с концом строки, после этого обрабатывать, если конца файла нет, снова читать... Как-то так?