Linux.by

Эт точно, я никогда абсолютно точно не помню ни опций sed'а ни grep'а и regexp'ов я не знаю в совершенстве, т.к. не практикую постоянно, но когда надо чё нибудь на bash'е сбацать - man и пару книжек + google рулят.

Спасибо!
RTFM должно помочь. (Читаю Bash Scripting Guide...)

Строчек 10-15 это на С выйдет , на мой взгял это будет проще поисков , чтения и перевода инфы из манов/гуглов

Gnida писал(а):Строчек 10-15 это на С выйдет , на мой взгял это будет проще поисков , чтения и перевода инфы из манов/гуглов

Абсолютно в корне не прав!
Вместо написания своих кривых поделий нужно юзать то, что уже надёжно, отлажено, заточено под задачу. Что и является одним из основополагающих принципов пользования UNIX'ов. В итоге получишь надёжность + универсальность (тебя будут понимать другие люди и смогут развивать нечто уже сделанное тобой).
По поводу чтения и переводов - если нет склероза, то после первого удачного применения некоторых подходов и прог, маны, книжки и гугл юзаются по большей части в качестве шпаргалок, т.е. как справочная информация. В итоге скорость решения задачи больше нежели сидеть и
изобретать велосипеды с квадратными колёсами.

Gnida, только man ты прочитаешь один раз.

А курить свои 20-40 (если с комментами!) строчек будешь каждый раз при отладке кода.

Абсолютно в корне не прав!
Вместо написания своих кривых поделий нужно юзать то, что уже надёжно, отлажено, заточено под задачу. Что и является одним из основополагающих принципов пользования UNIX'ов. В итоге получишь надёжность + универсальность (тебя будут понимать другие люди и смогут развивать нечто уже сделанное тобой).
По поводу чтения и переводов - если нет склероза, то после первого удачного применения некоторых подходов и прог, маны, книжки и гугл юзаются по большей части в качестве шпаргалок, т.е. как справочная информация. В итоге скорость решения задачи больше нежели сидеть и
изобретать велосипеды с квадратными колёсами.

Иногда велосипед изобретать надо , хотябы для того что бы добиться кроссплотформенности или что б система не обрастала софтом разработчиков третих стран. Первое конечно для 15 строчек - глупость, второе нет , когда для эконимии время , надежности и тд надо скачать пускай даже 100кбайт софта при том что хватило бы дописать 5 строчек.
Unix-way давно уже не unix-way , возмите например qt/gtk - жутко не удобно , криво и медленно.
Моё мнение надо смотреть по ситуации.

Gnida, только man ты прочитаешь один раз.

А курить свои 20-40 (если с комментами!) строчек будешь каждый раз при отладке кода.

Может и так , только код тоже можно вынести в отдельную функцию , и мы не будем знать как она работает , а только то что работает
Возможно написал бред , научите тогда товарисчи уму разуму)

Подавляющее большинство попадвших мне в руки *nix систем имели по дефолту perl. И все - sed/awk. Систем которые по умолчанию ставтся с компилятором C гораааздо меньше... Так что не надо о кроссплатформенности...

речь не только о юниксах.
Да и зачем С компилятор , если С программе достаточно быть 1 раз откомпилированой для системы

Gnida, гм, а если уловия чуть-чуть поменяются...? Переписывать и перекомпилировать программу?
Вобщем-то именно для задач обработки текста реализовано масса всяческиз инструментов - perl/sed/awk портированы на все распространенные платформы и реализовывать велосипед на C имеет смыл только в случае когда несколько порцентов производительности действительно что-то значат.
PS: если уж очень хочется - то тот же perl компилировать в бинари никто не мешает...

Давайте признаем очевидное
1) некоторые :) не знают базовых принципов работы с текстовыми потоками в unix и боятся их изучать
2) они считают, что изучение одного языка сделало их универсальными программистами
3) они априори полагают, что знают все лучше всех :)

и закончим эту бесполезную дискуссию :)

P.S. Можно вообще все на асме написать, включая операционную систему с live-cd. Действительно, мало ли какая ОС третьих сторон будет стоять на компе у клиента....