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 ★★
()

у тебя ООП головного мозга
подлечись

anTaRes ★★★★
()
Ответ на: комментарий от 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)

Выдыхай

Выдохнул? А теперь постарайся донести свою мысль более внятно.

Sed без -i не умеет сам писать в скормленный ему файл - это раз. Шелловые перенаправления - это уже не задача седа.

ОС за нас уже делает туеву хучу абстракций - это два.

У тебя ООП головного мозга - это три.

Ну и четыре - за «ровно одной вещью» иди в Plan 9 и не возвращайся.

rebforce
()

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

Текстовый редактор умеет добавлять строки в файл. Шок, интриги, расследования %)

router ★★★★★
()

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

Святая толстота. Покормить что ли?

systemd !

router ★★★★★
()

sed можно рассматривать как command, decorator, strategy, facade

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

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

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

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

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

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

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

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

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

При любых упоминаниях unix-way вспоминают systemd.

Что с ним не так?

Я просто не вникал, что он делает кроме того, что должны делать все системы инициализации: старта сервисов и, по сути, waitpid'ов?

evilface ★★
()
Ответ на: Выдыхай от rebforce

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

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

общая мысль в том, что, нет смысла предоставлять классу некоторое поведение, если это поведение можно делегировать другому классу, или унаследовать с тем же самым эффектом.

Спасибо, кэп.

Так вот, ты, по всей видимости, не уловил, откуда в примере с шеллом и седом наследуется функциональность ввода-вывода. Ни одно, ни другое самостоятельно её не реализует.

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

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

В таком случае, раз есть кресла-каталки — ноги не нужны. Можешь ампутировать.

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

это дурацкий аргумент, хотя как ни странно, очень распространенный среди офисных работников, который передергивает понятия, противопоставлением частного и общего, ложный силогизм, или хз, как это правильно называется, короче, вывод по индукции, типа: «если для кресла-каталки колеса уместны, значит колеса уместны для всего»

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

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

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

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

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

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

для текстового редактора вполне логична работа с текстовыми файлами, это близкие обязанности.

текстовый редактор никогда не работает с файлами. Он работает с текстом, представленным буффером. Такой абстракции как работа текстового редактора с файлом(точней, интерфейса, реализующего такую абстракцию) в unix просто не существует.

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

При любых упоминаниях unix-way вспоминают systemd.
Что с ним не так?

Наверное, дело в том, что я отправил в 2014 году Потнику одну строчку е-мейлом: «Lennart, what do you think about UNIX way?»

И с тех пор Лёня исправился, привёл в соответствие.

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

Такой абстракции как работа текстового редактора с файлом(точней, интерфейса, реализующего такую абстракцию) в unix просто не существует.

man: open(2), close(2), read(2), write(2)…

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

читаем еще раз внимательно: работа текстового редактора с файлом

linearisation
() автор топика

1) как связаны unix и ООП?
2) вы считаете, что всё должно укладываться в ООП?
3) если я правильно понял, у sed есть возможность работать в том режиме, какой вам нравится, что не так?

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

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

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

не предоставляет. делая edit somefile явно подразумевается работа с буфером, до тех пор пока ты не выгрузишь содержимое буфера обратно в файл(путем write), изменения файла не произойдет.

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

Все может быть выражено в терминах ООП

Можно ли записать 2/0? Можно, но в арифметике такая запись не имеет смысла.

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

Не знаю, опечатался ты или нет. Но на всякий случай: nmap — утилита для сканирования портов/определения сервисов и всего такого.. Опечатался или уточнил, отвечал я уже на удалённое сообщение.

mmap — системный вызов для отображения файлов в виртуальную память. Ага, тот самый api, позволяющий работать с файлами без всяких read()/write().

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

Когда про него только что рассказал учитель/препод — очень нужно. )

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

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

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