The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Представлена новая командная оболочка nushell, opennews (??), 29-Авг-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


17. "Представлена новая командная оболочка nushell"  –4 +/–
Сообщение от Аноним (17), 29-Авг-19, 12:36 
Согласен, что баш скрипты в общем случае более гибки. Особенно если сравнивать с текущей веврсии этого nushell, в которой судя по всему ещё даже условий, циклов и прочего не завезли.

Но если гововорить про пример с ls, то аналогичный эффект в баше можно достичь вот так:
find . -maxdepth 1 -type f -size +10k -exec ls {} \;

Мне кажется, что в nushell всё же более лаконичный синтаксис.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

23. "Представлена новая командная оболочка nushell"  +2 +/–
Сообщение от Аноним (5), 29-Авг-19, 12:43 
Метаязыки не нужны.
Ответить | Правка | Наверх | Cообщить модератору

25. "Представлена новая командная оболочка nushell"  +5 +/–
Сообщение от Аноним (25), 29-Авг-19, 12:55 
А вы дошли до страницы в мане, где find болванки прожигает?
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

26. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от Аноним84701 (ok), 29-Авг-19, 12:56 

> Но если гововорить про пример с ls, то аналогичный эффект в баше
> можно достичь вот так:
> find . -maxdepth 1 -type f -size +10k -exec ls {} \;

% ls -l | awk '$5>10000'

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

47. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Аноним (17), 29-Авг-19, 14:30 
Ну так гораздо понятнее да. Ну и эффект не соответствует выводу команды ls, из которого убрали отфильтрованные файлы.
Ответить | Правка | Наверх | Cообщить модератору

57. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Crazy Alex (??), 29-Авг-19, 14:59 
...и вместо читаемого слёту получаем нечто, где надо понимать, а что там за пятое поле. Хотя компактнее, конечно.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

62. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от Аноним84701 (ok), 29-Авг-19, 15:09 
> ...и вместо читаемого слёту получаем нечто, где надо понимать, а что там

Если хочется получить максимально близкий "перевод"  примера
> ls | where size>10k

то придется так.

Для эстетствующих  есть вариант:


ls -l | awk -v 'size_col=5' '$size_col>10000'

Ответить | Правка | Наверх | Cообщить модератору

175. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Анонимный Алкоголик (??), 31-Авг-19, 21:05 
>> ...и вместо читаемого слёту получаем нечто, где надо понимать, а что там
> Если хочется получить максимально близкий "перевод"  примера
>> ls | where size>10k
> то придется так.
> Для эстетствующих  есть вариант:
> 
 
> ls -l | awk -v 'size_col=5' '$size_col>10000' 
>  

У нас из любимых файлов такие:
Инцидент "Бедфорд".mpeg
Stormy Daniels.mp

(короче, правильно find)

Ответить | Правка | Наверх | Cообщить модератору

177. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Аноним84701 (ok), 31-Авг-19, 21:48 
> У нас из любимых файлов такие:
> Инцидент "Бедфорд".mpeg
> Stormy Daniels.mp
> (короче, правильно find)

Зачем писать загадками?
Что не так (нет, я догадываюсь, но неплохо бы услышать подтверждение)?
long listing format -l, если что, отнюдь не глупые люди придумали:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l...
> I "%s %u %s %s %u %s %s\n", <file mode>, <number of links>,
>   <owner name>, <group name>, <size>, <date and time>,
>   <pathname>
>

Ответить | Правка | Наверх | Cообщить модератору

185. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Анонимный Алкоголик (??), 02-Сен-19, 05:09 
> Зачем писать загадками?
> Что не так (нет, я догадываюсь, но неплохо бы услышать подтверждение)?
> long listing format -l, если что, отнюдь не глупые люди придумали:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l...
>> I "%s %u %s %s %u %s %s\n", <file mode>, <number of links>,
> >   <owner name>, <group name>, <size>, <date and time>,
>>   <pathname>

Ну эта... Как эта... Эта ну такой вот файл. Допустим их там не 2... Это в глазах двоится.
Опровергаем. Поднимаем.

Ответить | Правка | Наверх | Cообщить модератору

31. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от bubuka (?), 29-Авг-19, 13:22 
find . -maxdepth 1 -type f -size +10k -ls, тогда не будет на каждый файл по процессу запускать
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

43. "Представлена новая командная оболочка nushell"  –1 +/–
Сообщение от Ordu (ok), 29-Авг-19, 14:17 
> Но если гововорить про пример с ls, то аналогичный эффект в баше можно достичь вот так:
> find . -maxdepth 1 -type f -size +10k -exec ls {} \;

А это уже синтаксис find, а не синтаксис bash. ad hoc решение для файлов.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

93. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от anonymous (??), 29-Авг-19, 20:42 
Вообще это юнихвей, когда одна программа делает одно действие и делает это хорошо.
Ответить | Правка | Наверх | Cообщить модератору

97. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 29-Авг-19, 21:28 
> Вообще это юнихвей, когда одна программа делает одно действие и делает это
> хорошо.

Это ты намекаешь, что find делает одно действие? find -- это комбайн, да такой, что таких ещё поискать надо. Сделай man find в консольке и почитай.

Ответить | Правка | Наверх | Cообщить модератору

120. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от Аноним (120), 30-Авг-19, 08:34 
и что этому комбайну мешает быть одной программой, которая делает эти действия хорошо?
Ответить | Правка | Наверх | Cообщить модератору

134. "Представлена новая командная оболочка nushell"  –2 +/–
Сообщение от Ordu (ok), 30-Авг-19, 13:45 
> и что этому комбайну мешает быть одной программой, которая делает эти действия
> хорошо?

Ничто. Но и тем не менее, если unixway -- это на каждое действие по программе, то find -- это не unixway, потому что тут на много действий одна программа.

Ответить | Правка | Наверх | Cообщить модератору

136. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от Andrey Mitrofanov_N0 (??), 30-Авг-19, 14:19 
>если unixway -- это на каждое
> действие по программе,

Нет.

>то find -- это не unixway

Нет.

>, потому что
> тут на много действий одна программа.

Ответить | Правка | Наверх | Cообщить модератору

138. "Представлена новая командная оболочка nushell"  –2 +/–
Сообщение от Ordu (ok), 30-Авг-19, 14:33 
>>если unixway -- это на каждое
>> действие по программе,
> Нет.

Нет.

>>то find -- это не unixway
> Нет.

Нет.


Ответить | Правка | Наверх | Cообщить модератору

140. "Представлена новая командная оболочка nushell"  +1 +/–
Сообщение от Andrey Mitrofanov_N0 (??), 30-Авг-19, 14:54 
>>>если unixway -- это на каждое
>>> действие по программе,
>> Нет.
> Нет.

Уникальное расширенное предложение.  Торопитесь!

"" Если Вы хорошо попросите [и не раньше!], я дам вам ссылочку на taoup -- на объяснения про юникс, про принципы, про почему не нарушение, про ... ""
я-- https://www.opennet.ru/openforum/vsluhforumID3/117299.html#132

Ответить | Правка | Наверх | Cообщить модератору

142. "Представлена новая командная оболочка nushell"  –3 +/–
Сообщение от Ordu (ok), 30-Авг-19, 17:57 
>>>>если unixway -- это на каждое
>>>> действие по программе,
>>> Нет.
>> Нет.
> Уникальное расширенное предложение.  Торопитесь!
> "" Если Вы хорошо попросите [и не раньше!], я дам вам ссылочку
> на taoup -- на объяснения про юникс, про принципы, про почему
> не нарушение, про ... ""
> я-- https://www.opennet.ru/openforum/vsluhforumID3/117299.html#132

Я читал TAOUP лет пятнадцать назад, оно выглядело тогда откровением свыше, но сегодня я стал старше и умнее, и теперь оно выглядит попыткой натянуть сову на глобус. То есть попыткой взять существующий unix, и написать концепцию рационализирующую существующее положение дел, которая будет говорить, что то что есть -- хорошо, то чего нет -- плохо. Если X11 не влезает в концепцию и использует бинарный протокол вместо текстового, значит мы подопрём концепцию ad hoc костылём. Если find не влезает в концепцию, потому что комбайн, мы подопрём концепцию ещё одним ad hoc костылём. И на каждое несоответствие теоретической концепции с реальностью, мы воткнём ещё один рационализирующий ad hoc костыль.

Это ущербная методология, потому что действуя таким образом, под любое явление можно создать концепцию, которому это явление будет соответствовать. Любая правильная методология построения концепции даст концепцию, которой ни одно практическое решение не соответствует. Такая концепция будет _полезна_, потому что она позволит видеть, что не соответствует, а значит искать способы сделать это лучше. Концепция же которая рационализирует статус кво может быть полезна только в политических целях, чтобы громить оппонентов или воодушевлять сторонников. Но мы же, вроде, технари, а не политики? Или я ошибаюсь?

find содержит себе, например, синтаксис описания выборки, чтобы фильтровать данные, выбирая из них интересующее. Мы легко можем представить себе универсальный синтаксис, который будет работать не только с файлами, а с любыми данными. Есть sql, есть R, есть awk -- есть куча _универсальных_ вещей для фильтрации. В coreutils есть ряд утилит, позволяющих фильтровать поток данных. В конце-концов, в shell'е есть условные конструкции, которые позволяют фильтровать даные. Но find использует свой собственный ad hoc костыль. Но Эрик Раймонд рассказывает нам о том, что find -- это unix way. Его концепция unix-way ущербна и непригодна для применения без доработки напильником, потому что совершенно очевидно, что наличие в unix такого комбайна как find -- это провал концепции "программа делает одну небольшую вещь, но делает её хорошо". SQL и R, позволяют описывать гораздо лучше и понятнее гораздо более сложные выборки данных. awk позволяет работать с выборками гораздо лучше, выписывая много фильтров одновременно, и вешая на каждый фильтр свой обработчик. find же запиливает свой собственный ущербный синтаксис, только потому, что авторы не нашли способа как написать маленькую программу, которая хорошо умеет только рекурсивно обходить директории, обрабатывая всякие нюансы типа ссылок, а фильтрацию оставить другим утилитам, тому же awk'у например.

find -- это провал концепции, но для Эрика Раймонда -- это успех концепции. Чёрное -- это белое. Война -- это мир. Любовь -- это ненависть. И всё из-за ущербности методологии.

Ответить | Правка | Наверх | Cообщить модератору

168. "Представлена новая командная оболочка nushell"  –1 +/–
Сообщение от Дон Ягон (ok), 31-Авг-19, 00:59 
> Эрик Раймонд

Так себе авторитет, ИМХО.

>  find -- это провал концепции "программа делает одну небольшую вещь, но делает её хорошо"

Позвольте полюбопытствовать, почему именно? Потому что там есть опции а-ля "--ls" или "--delete"? Если так, то имхо это придирка.

> find же запиливает свой собственный ущербный синтаксис, только потому, что авторы не нашли способа как написать маленькую программу, которая хорошо умеет только рекурсивно обходить директории, обрабатывая всякие нюансы типа ссылок, а фильтрацию оставить другим утилитам, тому же awk'у например.
> Есть sql, есть R, есть awk -- есть куча _универсальных_ вещей для фильтрации. В coreutils (findutils же вроде?) есть ряд утилит, позволяющих фильтровать поток данных. В конце-концов, в shell'е есть условные конструкции, которые позволяют фильтровать даные. Но find использует свой собственный ad hoc костыль

find делает всё правильно. awk - утилита для обработки текста. Она не знает ничего ни про права, ни про овнера/группу, ни про любое другое свойства любого объекта фс. В то же время, find только про это и знает, его возможности фильтрации по имени файла ограничены глобами, если хочется чего-то бОльшего, то нужно передавать выхлоп find через пайп хоть тому же awk.
Что касается sql и R, то лично я бы не хотел использовать подобный синтаксис в find. Это слишком многословно. Да, в теории это гибче, на практике, задачи, решаемые при помощи find крайне редко требуют что-то сложнее or|not|and и сравнения свойств объектов фс - такая гибкость просто не требуется, а она не бесплатна. Не имею ничего против приложения, которое работает как find, но вместо его аргументов принимает на вход, например, SQL запросы, но только не в базовой поставке, пожалуйста.

Ответить | Правка | Наверх | Cообщить модератору

173. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 31-Авг-19, 11:28 
> awk - утилита для обработки текста.

Так я о том и говорю. Для обработки текста свой язык фильтрации. Для обработки файлов ещё один язык фильтрации. Для обработки чего угодно ещё запилим ещё один язык фильтрации. На каждый чих запилим по языку фильтрации. Разве нужна концепция unix, чтобы заниматься этой хнёй?

> Не имею ничего против приложения, которое работает как find, но вместо его аргументов принимает на вход, например, SQL запросы, но только не в базовой поставке, пожалуйста.

Не нужен find со встроенным sql -- это не unix-way. Нужен find, который на выходе выдаёт вывод, который затем можно обрабатывать универсальной утилитой с синтаксисом sql. Или с синтаксисом R. Или ещё каким. Можно иметь несколько таких утилиток, с синтаксисами заточенными под разные случаи или вкусы. И вот тогда это будет unix-way: я беру задачу, разбиваю её на подзадачи, под каждую подзадачу выбираю ту утилиту, которая лучше всего на неё заточена, после чего комбинирую эти утилиты в единую командную строку и получаю результат. Если же поисковой синтаксис прибит гвоздями к find, то выбора уже не остаётся.

Ответить | Правка | Наверх | Cообщить модератору

176. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Дон Ягон (ok), 31-Авг-19, 21:34 
>> awk - утилита для обработки текста.
> На каждый чих запилим по языку фильтрации. Разве нужна концепция unix, чтобы заниматься этой хнёй?

Она именно в этом и заключается. Поэтому, например, мы имеем отдельно awk и sed (были бы они ещё одинаковые в bsd и linux.. но это уже другая история).

> Не нужен find со встроенным sql -- это не unix-way.

Нет, это не так. Синтаксис тут вообще вторичен. Парсер SQL сложнее, синтаксис многословнее, а бОльшая гибкость в задачах find будет почти никогда не нужна. Но find принимающий на вход текущие аргументы или find, принимающий на вход sql будут "юниксвейны" в одинаковой степени.

> Нужен find, который на выходе выдаёт вывод, который затем можно обрабатывать универсальной утилитой с синтаксисом sql. Или с синтаксисом R. Или ещё каким.

А зачем он нужен? Чтобы выпендриваться типа крутой архитектурой? Но она выходит сильно круче решаемых задач -> оверинжиниринг.
Ей богу, я могу придумать только какую-то оторваную от реальности жесть, чтобы sql в find был оправдан. В обычных задачах пользы от этого не будет.
Следовательно конструировать весь этот ужас со "сменными насадками" смысла нет.

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

> Можно иметь несколько таких утилиток, с синтаксисами заточенными под разные случаи или вкусы.

Можно, но не нужно.

> И вот тогда это будет unix-way:

Это будет оверинжиниринг.

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

А где грань разумности? Можно ведь чуть ли не каждый сискол обернуть примитивной программой и потом конвееры из них строить. Или наоборот, писать монстров на все случаи жизни, а-ля systemd - некоторые тоже считают, что это юниксвейно, ведь оно решает задачу только одну задачу - запуск программ, просто смотрит на неё "достаточно широко"...
Как мне кажется, делать нужно только самые основные возможности, плюс наиболее практичные и часто нужные, если их тривиально написать. Остальной функционал, при необходимости, реализуется сторонними приложениями, которым через пайп передаются данные от предыдущего и так далее.
Если мы говорим о юниксвейном приложении для базовой поставки с ОС.

> Если же поисковой синтаксис прибит гвоздями к find, то выбора уже не остаётся.

Всё так. Но синтаксис не является признаком "юниксвейности".

Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

178. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 31-Авг-19, 22:37 
>>> awk - утилита для обработки текста.
>> На каждый чих запилим по языку фильтрации. Разве нужна концепция unix, чтобы заниматься этой хнёй?
> Она именно в этом и заключается. Поэтому, например, мы имеем отдельно awk
> и sed (были бы они ещё одинаковые в bsd и linux..
> но это уже другая история).
>> Не нужен find со встроенным sql -- это не unix-way.
> Нет, это не так. Синтаксис тут вообще вторичен. Парсер SQL сложнее, синтаксис
> многословнее, а бОльшая гибкость в задачах find будет почти никогда не
> нужна.

Но когда она будет нужна, я не смогу использовать find с sql. Мне придётся выёживаться мухой на стекле, чтобы получить csv, который затем можно будет затолкать в sqlite, чтобы затем сделать оттуда выборку.

> Но find принимающий на вход текущие аргументы или find, принимающий
> на вход sql будут "юниксвейны" в одинаковой степени.

Мне не нужен find принимающий на вход sql. Всё что он должен принимать -- это список файлов/директорий, которые выданы ему шеллом. По-хорошему, он даже вообще не нужен, потому что это умеет ls, и рекурсивно обходить директории ls тоже умеет. Ещё du умеет обходить рекурсивно. Зачем нужен этот десяток реализаций рекурсивного обхода директорий, когда можно обойтись одним?

>> Нужен find, который на выходе выдаёт вывод, который затем можно обрабатывать универсальной утилитой с синтаксисом sql. Или с синтаксисом R. Или ещё каким.
> А зачем он нужен? Чтобы выпендриваться типа крутой архитектурой? Но она выходит
> сильно круче решаемых задач -> оверинжиниринг.

Да ладно, оверинжиниринг -- это find, в который напихали всё что нужно, всё что не нужно, и ещё немного.

> Ей богу, я могу придумать только какую-то оторваную от реальности жесть, чтобы
> sql в find был оправдан. В обычных задачах пользы от этого
> не будет.

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

Попробуй сделать это find'ом, и ты быстро придёшь к выводу, что проще использовать ad hoc решения, типа всяких там интересных опций cp, которые позволяют условно копировать файлы. Если конечно в списке опций cp есть набор, позволяющий выполнить нужную тебе операцию над множествами. Или ещё проще даже забить болт, и сделать cp -r dir1/* dir2/, забив на ненужные копирования файлов. Ну будет оно 10-20-30 лишних минут копировать, и чё? Зато не надо 10 минут возиться с сочинением злой командной строки, покуривая между делом маны.

А если найденные файлы можно скормить языку, который умеет в sql, то... эмм... А нужен ли нам вообще в системе find? Нужен ли нам du? Может там ещё пяток утилит, которые можно выкинуть? И ещё можно будет опции cp прочистить, избавив его от всех этих условных копирований. Оставить только то, что часто используется, и поэтому удобно иметь аббревиатуры,

>[оверквотинг удален]
> в каком-то бинарном формате и произвольное число фронтендов, этот формат читающих?
> Если да, то это абсурд, потому что не понятно, зачем в этой
> схеме недо-find нужен вообще - можно же сразу читать данные с
> ФС, из самой программы, недо-find тут - избыточная абстракция.
>> Можно иметь несколько таких утилиток, с синтаксисами заточенными под разные случаи или вкусы.
> Можно, но не нужно.
>> И вот тогда это будет unix-way:
> Это будет оверинжиниринг.
>> я беру задачу, разбиваю  её на подзадачи, под каждую подзадачу выбираю ту утилиту, которая лучше всего на неё заточена, после чего комбинирую эти утилиты в единую командную строку и получаю результат.
> А где грань разумности?

Задача фильтрации информации -- это вещь, которая нужна везде и постоянно. Вынести её в отдельную утилиту, которая умеет _хорошо_ фильтровать: сам бог велел.

>> Если же поисковой синтаксис прибит гвоздями к find, то выбора уже не остаётся.
> Всё так. Но синтаксис не является признаком "юниксвейности".

Ой, ну давайте теперь будем жонглировать словами, играя в самую низкопошибную демагогию. Я уже третий? четвёртый? раз объясняю что я имею в виду? Не надо делать вид, что ты до сих пор не понял.

Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

179. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Дон Ягон (ok), 01-Сен-19, 16:50 
> Но когда она будет нужна, я не смогу использовать find с sql. Мне придётся выёживаться мухой на стекле, чтобы получить csv, который затем можно будет затолкать в sqlite, чтобы затем сделать оттуда выборку.

Ключевой вопрос: а когда она будет нужна? Но безусловно, если есть регулярная задача, в которой нужно делать выборку по объектам ФС, да так хитро, что без SQL не обойтись - это повод написать своё, всецело устраивающее решение. Но не тянуть ничем не оправданные во всех прочих случаях костыли в стандартные утилиты.

> Мне не нужен find принимающий на вход sql. Всё что он должен принимать -- это список файлов/директорий, которые выданы ему шеллом.

Конечно, ведь это так эффективно - гонять данные от одного процесса к другому, особенно, когда нет никаких причин сразу не сделать всё во втором процессе.

> По-хорошему, он даже вообще не нужен, потому что это умеет ls, и рекурсивно обходить директории ls тоже умеет. Ещё du умеет обходить рекурсивно. Зачем нужен этот десяток реализаций рекурсивного обхода директорий, когда можно обойтись одним?

Скопипасть или вынеси в библиотеку. Проблема то.

> Да ладно, оверинжиниринг -- это find, в который напихали всё что нужно, всё что не нужно, и ещё немного.

Например, что? --delete? --ls? Ну да, это небольшое пренебрежение идеологией во имя практичности.
Но настолько очевидно нужное и тривиальное, что всерьёз к этому цепляться на мой взгляд - придирки.
find делает, в целом, ровно то, что должен - показывает те объекты дерева ФС, которые удовлетворяют описанным опциями командной строки требованиями.

>> Ей богу, я могу придумать только какую-то оторваную от реальности жесть, чтобы sql в find был оправдан. В обычных задачах пользы от этого не будет.
> Есть две директории, в них много одинаковых файлов, но есть разные, я хочу создать третью директорию как объединение/пересечение/дополнение/любая-другая-операция-над-множествами из этих двух. В идеале даже сделать так, чтобы из одной из первых двух была бы сделана "третья", минимальным копированием файлов, потому что она находится на тормозном внешнем носителе, а файлы довольно большие.

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

> Попробуй сделать это find'ом, и ты быстро придёшь к выводу, что проще использовать ad hoc решения, типа всяких там интересных опций cp, которые позволяют условно копировать файлы. Если конечно в списке опций cp есть набор, позволяющий выполнить нужную тебе операцию над множествами. Или ещё проще даже забить болт, и сделать cp -r dir1/* dir2/, забив на ненужные копирования файлов. Ну будет оно 10-20-30 лишних минут копировать, и чё? Зато не надо 10 минут возиться с сочинением злой командной строки, покуривая между делом маны.

Конечно же я не буду решать эту задачу find'ом. Есть же rsync.

> А если найденные файлы можно скормить языку, который умеет в sql, то... эмм... А нужен ли нам вообще в системе find? Нужен ли нам du? Может там ещё пяток утилит, которые можно выкинуть? И ещё можно будет опции cp прочистить, избавив его от всех этих условных копирований. Оставить только то, что часто используется, и поэтому удобно иметь аббревиатуры,

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

> Задача фильтрации информации -- это вещь, которая нужна везде и постоянно. Вынести её в отдельную утилиту, которая умеет _хорошо_ фильтровать: сам бог велел.

1) Такие утилиты уже есть.
2) Отрывать функционал фильтрации там, где он действительно нужен - вредительство и больше ничего. Наличие ограниченного функционала фильтрации где-то не отменяет утилит из пункта 1.

>>> Если же поисковой синтаксис прибит гвоздями к find, то выбора уже не остаётся.
>> Всё так. Но синтаксис не является признаком "юниксвейности".
> Ой, ну давайте теперь будем жонглировать словами, играя в самую низкопошибную демагогию. Я уже третий? четвёртый? раз объясняю что я имею в виду? Не надо делать вид, что ты до сих пор не понял.

По тексту моих ответов ты мог бы и сообразить, что я тебя понял.
Только я продолжаю утверждать, что то, чего хочешь ты не имеет отношения к "unix way".

PS: Идеология должна служить коллективу, а не коллектив идеологии. Иначе это уже тоталитарная секта, а не коллектив.

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

180. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 01-Сен-19, 19:42 
>> Мне не нужен find принимающий на вход sql. Всё что он должен принимать -- это список файлов/директорий, которые выданы ему шеллом.
> Конечно, ведь это так эффективно - гонять данные от одного процесса к
> другому, особенно, когда нет никаких причин сразу не сделать всё во
> втором процессе.

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

> Скопипасть или вынеси в библиотеку. Проблема то.

Угу. И где это сделано кроме как в busybox?

>> Да ладно, оверинжиниринг -- это find, в который напихали всё что нужно, всё что не нужно, и ещё немного.
> Например, что? --delete? --ls? Ну да, это небольшое пренебрежение идеологией во имя
> практичности.

Прикинь, я даже не знал про такие опции, я постоянно пользовался фишкой: -exec rm {} \;. Про ортогональность API разработчики find тоже ничего не слышали?

> Но настолько очевидно нужное и тривиальное, что всерьёз к этому цепляться на
> мой взгляд - придирки.

Вот Реймонд тоже так считает. Когда что-то буквально следует его принципам unix way, он говорит, что это победа unix way. Когда что-то самым гнусным образом нарушает эти принципы, он говорит, что это придирки, практичность важнее, и поэтому это тоже победа unix-way. Поэтому я и говорю, что вся концепция unix-way (её ведь Реймонд назвал словами "unix way" и сформулировал, так?) -- это гнилой политический базар.

> find делает, в целом, ровно то, что должен - показывает те объекты
> дерева ФС, которые удовлетворяют описанным опциями командной строки требованиями.

И он совершенно был бы не нужен, если бы в unix-овом шелле был бы предусмотрен стандартный метод передачи табличных данных через пайп.

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

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

> Конечно же я не буду решать эту задачу find'ом. Есть же rsync.

Во-во. Ещё один ман с тысячью опций. И на каждую специфическую задачу по ещё одному man'у.

> А с чего ты решил, что твоя конструкция вообще будет эффективнее? Она
> также обойдёт ВСЕ файлы в директориях и потрогает диск столько же
> раз.

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

> Замена N маленьких приложений на один комбайн - действие противоположное "юниксвею" по
> смыслу.

Во-во. Я о том же.

>> Задача фильтрации информации -- это вещь, которая нужна везде и постоянно. Вынести её в отдельную утилиту, которая умеет _хорошо_ фильтровать: сам бог велел.
> 1) Такие утилиты уже есть.

Пример?
grep? Ха-ха.
awk? Он так и не научился в заголовки столбцов, их так и приходится отсчитывать на пальцах, чтобы выбрать нужный. Да и синтаксис его совершенно не совместим с shell'ом, приходится жестоко экранировать. Ну, и мне не нравится, то, что в awk не стоит умолчательного действия "вывести совпадающую строку".
R? R умеет в заголовки столбцов, но вот несовместимость синтаксиса с шеллом остаётся. Плюс он ещё менее awk заточен на использование в составе более сложной команды.

> 2) Отрывать функционал фильтрации там, где он действительно нужен - вредительство и
> больше ничего.

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


>>>> Если же поисковой синтаксис прибит гвоздями к find, то выбора уже не остаётся.
>>> Всё так. Но синтаксис не является признаком "юниксвейности".
>> Ой, ну давайте теперь будем жонглировать словами, играя в самую низкопошибную демагогию. Я уже третий? четвёртый? раз объясняю что я имею в виду? Не надо делать вид, что ты до сих пор не понял.
> По тексту моих ответов ты мог бы и сообразить, что я тебя понял.

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

> Только я продолжаю утверждать, что то, чего хочешь ты не имеет отношения к "unix way".

Давай уточним. Что ты понимаешь под unix-way? То что описал Раймонд в TAOUP? Естественно, что то, что я говорю, не имеет отношения к TAOUP. Я бы себя уважать перестал, если бы оно имело бы отношение. Вот если взять TAOUP, выкинуть оттуда всю воду, разборы конкретных случаев, и оставить исключительно два-три принципа, и ещё две-три цели, которых unix-way пытается достичь, следуя этим принципам. Затем заявить, что эти принципы требуют неукоснительного выполнения, а отклонения от них -- это отклонения от unix-way, то получится декларация, которая уместится в трёх абзацах. К ней можно приложить несколько страниц более развёрнутого описания, и вот тогда, может быть, я и соглашусь с тем, что получится. Смотря что именно будет в том списке принципов. А TAOUP, может быть и описывает unix-way, но если так, то тогда нахрен он нужен такой unix-way? Зигмунд Фройд бы, чётко определил бы TAOUP в тяжкий случай психологической защиты под названием рационализация. Мне не нужны многостраничные высеры порождённые действием психологических защит.

> PS: Идеология должна служить коллективу, а не коллектив идеологии. Иначе это уже
> тоталитарная секта, а не коллектив.

Идея unix-way служит исключительно политическим целям. Никаких технических целей она решить не в состоянии. Тебе интересна политика? Мне интересна, но все эти насквозь прогнившие идеологии единственное предназначение которых пудрить мозги широким массам я изучаю исключительно чтобы лучше понять ущербности мышления широких масс. Других применений им я не могу найти.

Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

182. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Дон Ягон (ok), 02-Сен-19, 02:56 
> Если нужна эффективность, то тебе не нужен shell -- интерпретатор на интерпретаторе, интерпретатором погоняет. Тебе нужна программа на C. Эффективность -- это к компилируемым языкам, а интерпретаторы -- это для того, чтобы быстро слепить.

Это совершенно не повод всё усугублять. Считать иначе - странно. Будь все программы, которые предполагается объединять в конвеер толстыми и неэффективными, пользоваться ими в стиле unix-way было бы просто невозможно.

> Угу. И где это сделано кроме как в busybox?

Подсказываю: нигде особенно не делают не потому что не знают, что так можно и/или не умеют. А в busybox есть требование к объёму.

> Прикинь, я даже не знал про такие опции, я постоянно пользовался фишкой: -exec rm {} \;. Про ортогональность API разработчики find тоже ничего не слышали?

Без понятия. Но наличие такой опции в find - логично, правильно и последовательно, чтобы ты там не говорил. Что за любовь к ничем не оправданным fork + exec, блин?

>> Но настолько очевидно нужное и тривиальное, что всерьёз к этому цепляться на мой взгляд - придирки.
> Вот Реймонд тоже так считает.

Почему тебя это вообще волнует? Реймонд - бесполезный горлопан и к принципам unix-way имеет очень мало отношения - по сути, он примазался к тому что уже было сформулировано до него. Смотри да хотя бы википедию.

> Когда что-то буквально следует его принципам unix way, он говорит, что это победа unix way. Когда что-то самым гнусным образом нарушает эти принципы, он говорит, что это придирки, практичность важнее, и поэтому это тоже победа unix-way.

Самым гнусным образом? Нет, не согласен.
Краеугольный камень в философии UNIX - это принцип KISS. Наличие опций вроде -delete и -ls в find не сильно усложняют код (по очевидным причинам) и сильно упрощают решение некоторых задач.
Задача программ - решать те или иные задачи в той или иной среде, а не соответствовать всем заповедям unix-way.

> Поэтому я и говорю, что вся концепция unix-way (её ведь Реймонд назвал словами "unix way" и сформулировал, так?) -- это гнилой политический базар.

Нет, это не так. И вообще, строгих заповедей нет. Реймонд (кажется) сказл как раз про то, что unix-way - это, в целом, KISS. Но он именно сформулировал, т.е. сказал то, что уже делалось по-факту. На мой взгляд, вот лучшая формулировка философии unix:
"Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools."

К DOTADIW Реймонд не имеет никакого отношения.

>> find делает, в целом, ровно то, что должен - показывает те объекты дерева ФС, которые удовлетворяют описанным опциями командной строки требованиями.
> И он совершенно был бы не нужен, если бы в unix-овом шелле был бы предусмотрен стандартный метод передачи табличных данных через пайп.

В теории - да.  А на практике.. А на практике быстро захочется не "стандартный метод передачи табличных данных", а как в powershell - когда всё, что передаётся через "пайп" объект.
Круто? С одной стороны - да. Например, потому что имена файлов с пробелами перестанут быть хоть какой-то проблемой. А с другой стороны, это полный ад, потому что использовать shell интерактивно становится почти невозможно. И из-за многословности и из-за того, что каждый отдельный случай требует помнить, какой объект возвращает та или иная команда и какие методы к этому объекту применимы есть.
Сравни, например, создание структуры директорий, аналогичной имеющейся (код для PS не мой):
find . -type d -exec mkdir -p /new/path/{} \;
и
cd $oldDir
Get-ChildItem ./ -Recurse -Directory |Resolve-Path -Relative |ForEach-Object {New-Item -ItemType Directory $newDir/$_}

Нужно ли тут что-то добавлять, или и так всё понятно?

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

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

> Во-во. Ещё один ман с тысячью опций. И на каждую специфическую задачу по ещё одному man'у.

А как ты хотел? Если через пайпы будут гоняться объекты, а не текст, маны придётся читать ещё чаще, к слову.

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

Я сравнивал с не существующей конструкцией "недо-find + нечто, умеющее фильтровать и парсить sql".
Но в любом случае, тебе тогда был нужен rsync, судя по тому, что ты описал.

>> Замена N маленьких приложений на один комбайн - действие противоположное "юниксвею" по смыслу.
> Во-во. Я о том же.

Нет. Я понимаю, что, в теории, ты хочешь утилиту которая умеет рекурсивно обходить директории, которая передаёт всё в фильтратор, который уже передаёт всё в удалятор/переименоватор/что-то ещё.
Но на практике это жестокая жесть и верховенство идеологии над здравым смыслом.
Условное "find ./ | xargs rm -f" вместо "rm -fr ./" - это УЖОС и оверинжиниринг в чистом виде.
Простые вещи должны делаться просто.
Твоя конструкция решает только одну проблему: буквальное соответствие принципу DOTADIW.
Никакие практические проблемы не решаются. Более того, облегчив донельзя условные find и rm мы приходим не только к тому, что удаление директории теперь делается двумя командами, а не одной, но и к тому, что если мы захотим воткнуть в эту схему фильтратор между find'ом и rm'ом, то, в отличие от кастрированных find и rm, фильтратор обречён быть переусложнённым комбайном. Почему? Потому что он должен уметь фильтровать ВСЕ типы объектов, которые подаются ему на вход. Уметь понимать, какие объекты можно друг с другом сравнивать, какие нет. Уметь достаточно сложные выражения. Да много чего ещё должен будет уметь.

>> 1) Такие утилиты уже есть.
> Пример?
> grep? Ха-ха.
> awk? Он так и не научился в заголовки столбцов, их так и приходится отсчитывать на пальцах, чтобы выбрать нужный. Да и синтаксис его совершенно не совместим с shell'ом, приходится жестоко экранировать. Ну, и мне не нравится, то, что в awk не стоит умолчательного действия "вывести совпадающую строку".

Да, например, grep, awk, sed. Perl/python как вариант, хотя это уже часто повод сразу на них и написать.
Снова повторяю: юниксвей - это не когда у тебя одна тулза на все случаи жизни, а когда ты из кучи можешь слепить то, что решает твою проблему.
Серебряной пули всё равно не существует, предположение о том, что мы можем написать универсальный фильтратор на все случаи жизни - ложно. И дело не в синтаксисе, хоть с sql, хоть c R - всё равно их рано или поздно не хватит. Или хватит, но только уродливой конструкцией. Это, кстати, при том, что бОльшую часть времени это будет избыточный и неиспользуемый функционал.

>> 2) Отрывать функционал фильтрации там, где он действительно нужен - вредительство и больше ничего.
> Это утверждение, которое необосновано ничем. В этом треде никто ни разу не высказал ни единого слова, которое можно было бы считать аргументом в пользу этого утверждения.

Оно обосновано принципом KISS и нежеланием городить избыточные абстракции. См. выше примеры про powershell и про find + rm.

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

Да, кажется я всё же не в тему немного сказал, извиняюсь. Ну или просто не могу сейчас вспомнить, к чему это было.

> Давай уточним. Что ты понимаешь под unix-way?

Принципы проектирования приложений, главным образом, для использования в базовой поставке unix-like систем.

> То что описал Раймонд в TAOUP?

Знаком с этими принципами (по раймонду) только в рамках страницы на русскоязычной вики.
Вот этой: https://ru.wikipedia.org/wiki/%D0%A4%D0%...

Для меня юниксвейность всегда была тем, что там описано в начале (авторство - Дуг Макилрой).
И - самое главное - это _философия_ unix, а не заповеди, которым нужно следовать с неистовством религиозных фанатиков. Реймонд, на мой взгляд, прав только про KISS, но как по мне, его неправильно считать основоположником этого принципа хоть в какой-то мере.

> что эти принципы требуют неукоснительного выполнения, а отклонения от них -- это отклонения от unix-way

Понимаю, почему у тебя так бомбит даже не читая дальше. Конечно, пересказанное тобою - трэш.

> Зигмунд Фройд бы, чётко определил бы TAOUP в тяжкий случай психологической защиты под названием рационализация.

Вполне возможно. Я не читал. В целом, Реймонд воспринимается мной как балабол, который очень много говорит и советует, но не понятно, что на самом деле сделал нужного.

> Мне не нужны многостраничные высеры порождённые действием психологических защит.

Так игнорируй. И "Закон Линуса" и "Собор и Базар" реймонда - графоманские высеры, например, почему я не удивлён, что TAOUP, судя по всему, тоже?
Немного не в тему, но освежая в википедии память о реймонде не смог не заржать в голос с этого: "Реймонд — активный либертарианец (также называет себя политическим анархистом), имеет чёрный пояс в тхэквондо, он неоязычник и выступает за право носить и использовать огнестрельное оружие."
Неплохо так у чувака в голове намешано, да?)

> Идея unix-way служит исключительно политическим целям. Никаких технических целей она решить не в состоянии. Тебе интересна политика? Мне интересна, но все эти насквозь прогнившие идеологии единственное предназначение которых пудрить мозги широким массам я изучаю исключительно чтобы лучше понять ущербности мышления широких масс. Других применений им я не могу найти.

Unix-way - это философия написания простых и практичных программ. Ограниченно применимая.
Хотя это конечно как посмотреть. Для кого-то это религия или полит. идеология.
Вот это мне как раз (в конексте юниксвея) не интересно.
Ущербность мышления - считать, что unix-way (или любая иная философия проектирования чего-либо, сформулированная сложнее чем KISS) должна беспрекословно соблюдаться. Например, и vi и top появились ещё в ТЕ времена, формально являются нарушением "строгого" unix-way, но ничего от этого не случилось. И их даже нельзя назвать такими уж комбайнами (прим. - vi, но не vim).

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

187. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 02-Сен-19, 10:09 
>> что эти принципы требуют неукоснительного выполнения, а отклонения от них -- это отклонения от unix-way
> Понимаю, почему у тебя так бомбит даже не читая дальше. Конечно, пересказанное
> тобою - трэш.

Нет, не понимаешь. Пытаться на принципах созданных в популистских целях -- это абсолютно ущербный подход. Не принципы надо гнуть под реализацию, а реализацию под принципы. Если ты гнёшь принципы, то это называется беспринципность, или отсутствие принципов.

При этом, ты можешь сколько угодно демонстративно отрекаться от Эрика Раймонда, но ты сейчас делаешь ровно то же самое, что и он. _Ровно_ то же самое. И все эти отречения таким образом, яйца выеденного не стоят.

find можно делать как угодно, так как ты считаешь это удобным, но не надо считать что автоматические будет получаться так, что всё, что удобно тебе -- это unix-way. Тебе хочется всего и сразу, и иметь принципы, и делать всё что захочется, всё что ты считаешь удобным. Но так не бывает. Если твои принципы никак не ограничивают тебя, то это не принципы. Если всё, на что твои принципы способны -- это рационализировать статус кво, то это не принципы, а рационализация. Рационализация же совершенно бесполезна в инженерном смысле, она может быть полезна в психологическом/политическом смыслах, но в техническом она бесполезна и даже вредна.

Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

192. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Дон Ягон (ok), 02-Сен-19, 18:10 
>>> что эти принципы требуют неукоснительного выполнения, а отклонения от них -- это отклонения от unix-way
>> Понимаю, почему у тебя так бомбит даже не читая дальше. Конечно, пересказанное тобою - трэш.
> Нет, не понимаешь. Пытаться на принципах созданных в популистских целях -- это абсолютно ущербный подход. Не принципы надо гнуть под реализацию, а реализацию под принципы. Если ты гнёшь принципы, то это называется беспринципность, или отсутствие принципов.

Какие принципы? Где ты такое слово-то нашёл? Сам сказал - сам опроверг - очень удобно.
Речь о филососфии unix, о ПОДХОДЕ к проектированию, а не о заповедях, сколько раз это нужно повторить, чтобы ты меня услышал?
Вот например, философия archlinux - rolling релизы и стремление поддерживать всегда актуальные версии. Если в archlinux откладывается попадание какого-то обновления, например, из-за того, что там есть баг или уязвимость - это не значит, что они нарушают какие-то принципы или попирают философию. Это значит, что они не являются тупыми фанатиками.
Ты же выставляешь тупейшую форму фанатизма не то что за норму, а за идеальное положение вещей.
"Принципы" проектирования unix были написаны постфактум и отражали реальное положение вещей, а не наоборот - никто не писал юникс по заранее написаным канонам. Философия появилась после, как попытка понять, почему юникс так выстрелил.

tl;dr - все твои претенезии исключительно от извращённого понимания того, что есть unix-way.

> При этом, ты можешь сколько угодно демонстративно отрекаться от Эрика Раймонда, но ты сейчас делаешь ровно то же самое, что и он. _Ровно_ то же самое. И все эти отречения таким образом, яйца выеденного не стоят.

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

> find можно делать как угодно, так как ты считаешь это удобным, но не надо считать что автоматические будет получаться так, что всё, что удобно тебе -- это unix-way.

Я так и не считаю. Цитату, где я пишу так в студию.

> Тебе хочется всего и сразу, и иметь принципы, и делать всё что захочется, всё что ты считаешь удобным. Но так не бывает.

Нет. Во-первых, я уже написал, что принципы - это твоя выдумка и больше ничего. Далее я написал, что "принципы" - это не заповеди, а потому строгое следование им не требуется.
В третьих, я сразу ограничил область применения "юникс-подхода" - 1) он хорош там, для чего был создан и в аналогичном 2) он по-определению предполагает не программы-комбайны, а совмещение возможностей нескольких программ. Даже если одной программой-комбайном удобнее.
("Фильтратор" в твоей конструкции именно комбайн. А find и rm - бесполезные, неюзабельные обрубки.)
Так что врать не надо.

> Если твои принципы никак не ограничивают тебя, то это не принципы.

"Юникс-вей" - это и не принципы. И не заповеди. Сколько ещё раз я должен это повторить?

> Если всё, на что твои принципы способны -- это рационализировать статус кво, то это не принципы, а рационализация.

Нет, это философия, пытающаяся сформулировать подходы к написанию простых и универсальных решений.
Рационализация? Блин, АБСОЛЮТНО ВСЁ ПРОГРАММИРОВАНИЕ ЭТО РАЦИОНАЛИЗАЦИЯ!
Никто, кроме ПОЕХАВШИХ не пишет программы ради того, чтобы они соответствовали какой-то идеологии!
Юникс был написан чтобы РАБОТАТЬ, а не чтобы соответствовать unix-way!
Если проблему невозможно эффективно решить следуя каким-то "принципам", а проблему решать нужно, значит нужно накласть на все "принципы", "заповеди" и весь прочий сектантский бред и ДЕЛАТЬ.
Не знаю, замени слово "принципы" на "рекомендации", может так тебя отпустит.

> Рационализация же совершенно бесполезна в инженерном смысле, она может быть полезна в психологическом/политическом смыслах, но в техническом она бесполезна и даже вредна.

А я утверждаю противоположное. Программы должны решать проблемы пользователя, максимально удобным и универсальным способом. Таким был unix, поэтому подход, с которым его делали в той или иной мере стараются воспроизводить и по сей день.
При этом, ни одна идея-расширение "юниксвея", типа повершелла по-настоящему так и не выстрелила. Нишевый, мало кому нужный продукт.

Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

196. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 02-Сен-19, 23:00 
> Речь о филососфии unix, о ПОДХОДЕ к проектированию, а не о заповедях,
> сколько раз это нужно повторить, чтобы ты меня услышал?

Когда каждый использует свои собственные подходы -- это значит, что нет никаких единых подходов. Каждый городит кто во что горазд.


> Вот например, философия archlinux - rolling релизы и стремление поддерживать всегда актуальные
> версии.

Это не философия. Это способ реализовать миссию дистрибутива. Миссию с некоторой натяжкой можно назвать философией. Наверное можно. Я не знаю, что там думают разработчики ArchLinux о том, зачем их дистрибутив существует, то есть я могу лишь из самых общих соображений предполагать, в чём собственно их миссия.

>> При этом, ты можешь сколько угодно демонстративно отрекаться от Эрика Раймонда, но ты сейчас делаешь ровно то же самое, что и он. _Ровно_ то же самое. И все эти отречения таким образом, яйца выеденного не стоят.
> Мне очень смешно это читать.
> Вместо того, чтобы как-то по-существу возразить мне, ты обвинил меня в том,
> что я делаю что-то как чел в книге, которую я не
> читал.

То есть ты не только не можешь понять претензий к Раймонду, ты даже не замечаешь этих претензий? Любопытно.

Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

197. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Дон Ягон (ok), 03-Сен-19, 01:02 
>> Речь о филососфии unix, о ПОДХОДЕ к проектированию, а не о заповедях, сколько раз это нужно повторить, чтобы ты меня услышал?
> Когда каждый использует свои собственные подходы -- это значит, что нет никаких единых подходов. Каждый городит кто во что горазд.

Подходы, или рекомендации к написанию программ существуют, только они не являются религиозными.
Уровень абстракции должен выбираться осознанно - мы не оборачиваем все сисколы функциями обёртками - следовательно, помимо соответствия "юниксвейности" (в той или иной степени) есть ещё какие-то критерии, определяющие дизайн приложения. Не так ли?

>> Вот например, философия archlinux - rolling релизы и стремление поддерживать всегда актуальные версии.
> Это не философия. Это способ реализовать миссию дистрибутива. Миссию с некоторой натяжкой можно назвать философией. Наверное можно.

А это уже софистика.
Философия archlinux (которую я почерпнул из сегодняшней новости про Кроа-Хартмана) это того же рода "философия", как и "философия unix". При желании можно заменить "философия archlinux" на "принципы archlinux" - суть моего посыла от этого не меняется.
Если арчедевелоперы отошли от своих "принципов" во имя объективных причин, они не беспринципные, а просто не фанатики.
Их "философия", "принципы" - это ориентир, цель, к которой нужно, по-возможности, стремиться. Вектор движения.
C "юниксвеем" всё аналогично.

>>> При этом, ты можешь сколько угодно демонстративно отрекаться от Эрика Раймонда, но ты сейчас делаешь ровно то же самое, что и он. _Ровно_ то же самое. И все эти отречения таким образом, яйца выеденного не стоят.
>> Мне очень смешно это читать.
>> Вместо того, чтобы как-то по-существу возразить мне, ты обвинил меня в том, что я делаю что-то как чел в книге, которую я не читал.
> То есть ты не только не можешь понять претензий к Раймонду, ты даже не замечаешь этих претензий? Любопытно.

Как я могу понять претензии к Реймонду, если я не читал TAOUP?
Может оставим его уже в покое? Кто угодно может сформулировать свои личные "принципы" юниксвея, но свершенно не понятно, почему мы должны обращать на это внимание. Всё было сформулировано задолго до Раймонда и без его помощи.
Какой вообще вклад Раймонда в опенсорс? Писал код в fetchmail и emacs? Написал эссе в котором технично вылизывает жопу Торвальдсу? Блин, его принципы unix были сформулированы, судя по дате выхода книги, в 2002 году, когда никакого юникса (в изначальном виде) уже толком и не было.
Я правда не понимаю, почему нужно обсуждать его, что бы там он не писал.
Но если и нужно, то с тем, кто читал. Со мной можно собор и базар, например, обсудить, если так хочется про Реймонда.

Но я, кстати, действительно в одном месте неверно тебя понял, а именно:
> эти принципы требуют неукоснительного выполнения, а отклонения от них -- это отклонения от unix-way

Я думал, что ты обвиняешь Реймонда в том, что он определил где-то строгие принципы unix-way, а потом рассказывает, что нарушать их тоже unix-way.
Но нет, этого, судя по всему, хочешь ты. И конечно же, ты тотально неправ в своих желаниях, это какой-то предельно оторванный от жизни идеализм. Когда программы пишут не исходя из потребностей, а из идеологии получается прокрустово ложе.
Могу тут сослаться на нелюбимого мной Торвальдса: "Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.".
Именно поэтому круто, что "unix-way" - это культурные нормы и подходы к разработке ПО, а не жёстко  прописанные правила, нарушение которых карается расстрелом. Эти нормы и подходы сформировались естественным путём и постфактум, в ходе написания ПО. И они отражают то, как удобно делать на практике, по-настоящему, а не на бумаги.
Если Реймонд выступает за это же, то он прав, с какой бы насмешкой я бы не относился к нему за собор и базар и тысячи глаз, которые обязательно не пропустят ошибку в коде. Но судя по википедии, всё же нет, он не про это; он просто графоман. Но всё же - я не читал TAOUP.

Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

186. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Анонимный Алкоголик (??), 02-Сен-19, 05:35 
Транслятор с языка Ада кстати тоже не нарушает увэй...
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

188. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Ordu (ok), 02-Сен-19, 10:10 
> Транслятор с языка Ада кстати тоже не нарушает увэй...

Не нарушает. Но он не заточен под использование вместо шелла.

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

199. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Анонимный Алкоголик (??), 05-Сен-19, 05:44 
Ну и find вообще-то вместо shell будет как-то неостёр...
Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

99. "Представлена новая командная оболочка nushell"  +2 +/–
Сообщение от Аноним84701 (ok), 29-Авг-19, 21:33 
> Вообще это юнихвей, когда одна программа делает одно действие и делает это хорошо.

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

Возможность передачи и работы с структурированными данными - следущая ступень, IMHO.
К тому же, оно позволяет более  "юнихвейный юнихвей" - т.к. более универсально/генерализированно, да и не нужно долбиться со всякими особыми случаями из-за экранирования, пробелов/разделителей, неполных строк и прочего.

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

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

125. "Представлена новая командная оболочка nushell"  +/–
Сообщение от Аноним (125), 30-Авг-19, 10:34 
структурированные и типизированные данные - это круто, да.
но дотнет - говно, а раст.. не понятно.
Ответить | Правка | Наверх | Cообщить модератору

109. "Представлена новая командная оболочка nushell"  –1 +/–
Сообщение от Wilem (?), 29-Авг-19, 22:55 
Разница между nu-ls и find это не вопрос синтаксиса. К бешу это сравнение вообще не применимо, тк он не умеет инфу о файлах загружать. Find - это не беш.

Тут речь про общий подход - единый формат данных и один раз выученные операции работы с абсолютно любыми данными в этом формате. Это проще понять и запомнить. Меняться будут только источники данных.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру