LINUX.ORG.RU
ФорумTalks

антипаттерны в unix-утилитах

 , ,


1

5
sed 's/foo/FOO/w changed' test
sed -n 's/foo/FOO/p' test>changed

что такое sed с тз ООП? Правильно, это «божественный класс», он и сам с усами, может добавить строки в файл.

Вообще говоря, я считаю, что некоторая разновидность «божественности» в ООП приемлема, если она не является хардкором. Например любой класс может выводить на консоль свое текстовое представление с помощью print, но этот print должен наследоваться, дабы была возможность его переопределить. Тогда это достаточно гибко и object print может рассматриваться как синтаксический сахар над print object, при этом сохраняется универсальность интерфейса.

Однако же это не тот случай, тут чистый хардкор.

Предлагаю тут постить еще примеры демонстрирующие известный принцип дизайна unix «Каждая программа должна делать ровно одну вещь, и делать её хорошо», только наоборот, как в примере выше, инверсию, так сказать этого принципа. К слову, принцип этот, по-сути, совпадает с принципом разделения ответственностей в ООП, не?

Интересно, есть сейчас в юниксах и линуксах хоть что-то, что ему действительно соответствует?

Перемещено tailgunner из development



Последнее исправление: linearisation (всего исправлений: 2)

ООП и не нужно, императивщина наше всё.

А sed делает одну вещь и делает её хорошо: редактирует тексты. Ибо потоковый текстовый редактор. И не важно, с какого файла он их читает, stdin или test.

evilface ★★
()
Последнее исправление: evilface (всего исправлений: 1)
Ответ на: комментарий от evilface

Ну и куда пишет соответственно. На stdout или в указанный аргументом файл.

evilface ★★
()
Ответ на: комментарий от linearisation

Ты не понимаешь, как устроено перенаправление в shell. sed просто пишет в stdout, а твой shell перенаправляет его в «changed».

anonymous
()
Ответ на: комментарий от anonymous

Ну, то что ты сказал то, я как раз понимаю, хоть я и не знаток шелла. И что с того? Так и должно быть. sed не должен делать это сам, он должен делегировать это шеллу, как во втором примере. Первый приведенный случай — антипаттерн

linearisation
() автор топика
Ответ на: комментарий от linearisation

глупенький, «IO-операции» это > в этом и есть твой «ООП»
а про юникс принципы вообще нечего говорить, ты принципы индейцев апачи еще бы привел, глупыш 2017 год на дворе, пора бы уже знать что gnu = gnu not unix
и линукс тоже не юникс
иди в солярке копайся, там чтоб сеть настроить есть аж два сервиса и две команды — unix way

system-root ★★★★★
()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от system-root

ты не понял, видимо. второе выражение — это нормальный пример, это выражение реализует семантику: «сообщить шеллу, чтобы тот послал сообщение sed'у, которое он сам знает как обработать, затем сообщить шеллу, чтобы тот перенаправил стандартный вывод в такой-то файл». Тут разделение ответственности соблюдается. Не соблюдается оно как раз в первом случае, когда sed сам лезет(причем безо всякой на то надобности) в перенаправление потоков.

linearisation
() автор топика
Ответ на: комментарий от linearisation

ахах, а ты хочешь редактор воообще без поддержки ввода вывода да? То есть судя по твоей логике sed внутри себя должен делать так

/*make buffer*/
char * buffer = malloc(sizeof(char)*STARTUPLEN);
/*edit text*/
calloc/realloc/calloc/realloc...,,
/*clean buffer*/
free(buffer);//а ещё до кучи bzero(buffer,strlen(buffer)); :D
return 0;
/*good work!*/

::)

Dron ★★★★★
()
Ответ на: комментарий от Dron

думаю, он просто всегда должен выводить в stdout, а на то чтбы управлять потоками есть шелл

linearisation
() автор топика
Ответ на: комментарий от linearisation

stdin и stdout — это не клавиатура и терминал, это может быть чем угодно.
это полиморфизм.
прямо в ядре, прямо getchar() и putchar(c) делают это, а не шелл
потому что каждый io драйвер имеет 5 магических сигнатур

  • read
  • write
  • open
  • close
  • seek
system-root ★★★★★
()
Ответ на: комментарий от system-root

stdin и stdout — это не клавиатура и терминал, это может быть чем угодно.

а я что, утверждал обратное? Это абстрактный объект. Какое это имеет отношение к сабжу?

прямо в ядре, прямо getchar() и putchar(c) делают это, а не шелл

потому что каждый io драйвер имеет 5 магических сигнатур это детали реализации, которые нас не должны интересовать, в данном случае.

linearisation
() автор топика
Ответ на: комментарий от linearisation

которые нас не должны интересовать, в данном случае

правда?

«но и производить IO-операции самостоятельно»

совершенно не важно, ведь

это детали реализации

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

system-root ★★★★★
()
Ответ на: комментарий от system-root

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

прямо getchar() и putchar(c) делают это, а не шелл

==

прямо <something else> делают это а не getchar() и putchar(c)

и более того, это мог бы быть не getchar() и putchar(c), а <another things> <on another virtual machine> при сохранении того же поведения шелла

Это все переливание из пустого в порожнее, чтобы прояснять вопросы семантики нам надо абстрагироваться от реализации, а ты делаешь ровно наоборот, залезаешь в дебри этой реализации. Твои рассуждения напоминают рассуждения Царя.

linearisation
() автор топика
Ответ на: комментарий от linearisation

Ну так текстовый редактор же. Естественно, что он производит IO-операции. Его цель — читать текст, редактировать, записывать.

evilface ★★
()
Ответ на: комментарий от linearisation

надо абстрагироваться от реализации
Твой getchar, который в ядре

вот в этом то и проблема
ты видишь поведение некой программы, не зная о реализации ты считаешь что это неправильное поведение или делаешь выводы, что некая программа сама делает IO операции
но getchar не в ядре, а ещё есть vtable и это нужно знать (хотя бы на уровне прочел статью), чтобы не путать некоторые вещи
это базовые концепции, они как раз созданы для абстрагирования, для полиморфизма

system-root ★★★★★
()
Последнее исправление: system-root (всего исправлений: 2)
Ответ на: комментарий от evilface

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

linearisation
() автор топика
Ответ на: комментарий от linearisation

Приведи, пожалуйста, реализацию поведения sed -i.backup -e '…' filename на перенаправлениях. А если получится, подумай, что удобнее.

Unix-way в простоте.

evilface ★★
()
Последнее исправление: evilface (всего исправлений: 1)
Ответ на: комментарий от evilface

Приведи, пожалуйста, реализацию поведения

ммм... странный пример... cat filename>backup; sed -i '...' filename

Это не простота, а сложность системы. Вместо обобщения поведения мы плодим лишние сущности и кучу частных, несовместимых интерфейсов, ради экономии на спичках. Пожалуй, это как раз самый уродливый принцип дизайна из всех возможных.

linearisation
() автор топика
Ответ на: комментарий от linearisation

Ты понимаешь, что перенаправление в этом примере высосано как минимум из пальца, т.к. cat test>filename можно и нужно заменить вменяемым cp test filename? Быстрее и правильнее сразу указать ОС скопировать один файл в другой, чем указать ОС скопировать файл в stdout, затем указать шеллу, чтобы тот указал ОС скопировать stdout первой команды в файл.

rebforce
()
Ответ на: комментарий от linearisation

Это длиннее, это запуск двух программ вместо одной, это в принципе другой процесс. Вместо «отредактировать файл, сохранив резервную копию» получается «сделать ещё один файл с тем же содержимым; отредактировать файл». При этом ещё и бездумное использование инструментов: для копирования есть cp, а не cat, а sed'у в твоём примере -i не нужен.

evilface ★★
()
Ответ на: комментарий от anonymous

sed просто пишет в stdout, а твой shell перенаправляет его в «changed».

Что? А sed -i значит не делает open() файлу, да? Ну ты юморист.

DELIRIUM ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.