Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Denis]

27.02.2018 16:53, Denis пишет:

26.02.2018 22:52, Dmitry Alexandrov пишет:

Конкретно в rec прямо запрещены нелатинские имена.
А вот это плохо. Поясните, пожалуйста подробнее: запрещены только 
имена или вообще всё нелатинское (в т.ч. значения записей)?


Например
"
name: Федор
surname: Емельяненко
"
будет работать?


Дочитал ман до recsel и проверил сам:работает!

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Denis]

26.02.2018 22:52, Dmitry Alexandrov пишет:

Конкретно в rec прямо запрещены нелатинские имена.
А вот это плохо. Поясните, пожалуйста подробнее: запрещены только имена 
или вообще всё нелатинское (в т.ч. значения записей)?


Например
"
name: Федор
surname: Емельяненко
"
будет работать?

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Artem Chuprina]

Dmitry Alexandrov -> debian-russian@lists.debian.org  @ Mon, 26 Feb 2018 
18:52:50 +0300:

 >>  >>>     4. Возможность сразу без допилов получать репорты по связанным
 >>  >>> данным. Т.е. груши любят: Петя, Вася, Таня ; Петя любит: яблоки, 
 >> груши, Таню.
 >>
 >>  >> Вроде бы нашел, что искал - GNU recutils.
 >>
 >>  > В каком смысле?  Там нет ничего, что можно было назвать «поддержкой
 >>  > структур многие-ко-многим».
 >>
 >> Я сильно подозреваю, что в том же смысле, что у обычных реляционных баз,
 >> которые тоже специальной поддержки для них не имеют. Джойны-то есть...
 >>
 >> Хотя если говорить о человеко-читаемом формате, то оно бы должно уметь
 >> из
 >>
 >> Имя: Петя
 >> Любит: яблоки, груши, Таню
 >>
 >> Название: груши
 >> Любят: Вася, Таня

 > Конкретно в rec прямо запрещены нелатинские имена.

В 2018 году? Сильны граждане...

 >> делать вывод, что груши любят Петя, Вася, и Таня.

 > Я же таки первым делом, как вопрос прочел, пошел проверять не научились ли в
 > такое GNU Recutils.  :-) Посмотрел — нет.  Плохо искал?  А допилить-то,
 > конечно, несложно, но товарищ просил готовое.

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

 > Дык я про то и говорю, что не предусмотрено в формате rec такой
 > метаинформации.  Соответсвенно и recsel(1)’у нельзя дать такого приказа.  Ему
 > вообще сейчас нельзя дать приказа типа:

 > $ recsel -e 'name = "Вася"' -P likes -e 'liked_by = "Вася"' -P name

 > Только в два прохода:

 > $ recsel -e 'name = "Вася"' -P likes
 > $ recsel -e 'liked_by = "Вася"' -P name

 > Что, конечно, безобразие.

Ну, тогда это негодный тул.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Dmitry Alexandrov]

>  >>>     4. Возможность сразу без допилов получать репорты по связанным
>  >>> данным. Т.е. груши любят: Петя, Вася, Таня ; Петя любит: яблоки, груши, 
> Таню.
>
>  >> Вроде бы нашел, что искал - GNU recutils.
>
>  > В каком смысле?  Там нет ничего, что можно было назвать «поддержкой
>  > структур многие-ко-многим».
>
> Я сильно подозреваю, что в том же смысле, что у обычных реляционных баз,
> которые тоже специальной поддержки для них не имеют. Джойны-то есть...
>
> Хотя если говорить о человеко-читаемом формате, то оно бы должно уметь
> из
>
> Имя: Петя
> Любит: яблоки, груши, Таню
>
> Название: груши
> Любят: Вася, Таня

Конкретно в rec прямо запрещены нелатинские имена.

> делать вывод, что груши любят Петя, Вася, и Таня.

Я же таки первым делом, как вопрос прочел, пошел проверять не научились ли в 
такое GNU Recutils.  :-)  Посмотрел — нет.  Плохо искал?  А допилить-то, 
конечно, несложно, но товарищ просил готовое.

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

Дык я про то и говорю, что не предусмотрено в формате rec такой метаинформации. 
 Соответсвенно и recsel(1)’у нельзя дать такого приказа.  Ему вообще сейчас 
нельзя дать приказа типа:

$ recsel -e 'name = "Вася"' -P likes -e 'liked_by = "Вася"' -P name

Только в два прохода:

$ recsel -e 'name = "Вася"' -P likes
$ recsel -e 'liked_by = "Вася"' -P name

Что, конечно, безобразие.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Artem Chuprina]

Dmitry Alexandrov -> Denis  @ Mon, 26 Feb 2018 15:03:13 +0300:

 >>> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
 >>> стесняйтесь (общение в рамках решения этой задачи является частью fun'а)
 >>>
 >>> Требования:
 >>>
 >>>     1. Хранение данных в текстовом виде
 >>>
 >>>     2. Интерфейс командной строки (с прицелом на дальнейший запил
 >>> bash-скриптов для автоматизации)
 >>>
 >>>     3. Как можно минималистичнее во всем. Принцип "suck less" превыше 
 >>> всего.
 >>>
 >>>     4. Возможность сразу без допилов получать репорты по связанным
 >>> данным. Т.е. груши любят: Петя, Вася, Таня ; Петя любит: яблоки, груши, 
 >>> Таню.

 >> Вроде бы нашел, что искал - GNU recutils.

 > В каком смысле?  Там нет ничего, что можно было назвать «поддержкой
 > структур многие-ко-многим».

Я сильно подозреваю, что в том же смысле, что у обычных реляционных баз,
которые тоже специальной поддержки для них не имеют. Джойны-то есть...

Хотя если говорить о человеко-читаемом формате, то оно бы должно уметь
из

Имя: Петя
Любит: яблоки, груши, Таню

Название: груши
Любят: Вася, Таня

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

 > Не, ну если вы хотите дописать, это надо думать, никакой сложности не
 > составит, но в вопросе-то было ровно обратное.

 >> кто-то пользовался? Стоит начинать процесс штудирования мануала?

 > Да, конечно, весьма полезная штучка.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Artem Chuprina]

Denis -> debian-russian@lists.debian.org  @ Mon, 26 Feb 2018 16:30:52 +0700:

 >>> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
 >>> стесняйтесь (общение в рамках решения этой задачи является частью
 >>> fun'а)
 >> Используйте обычные coreutils. Их возможности (если вместе с awk)
 >> вполне достаточны для решения поставленной задачи.
 >> Храните данные в формате Tab separated  по одной таблице в файле и
 >> впред.
 >>
 >> Если же хочется использовать sql, то рекомендую sqlite. У него формат,
 >> конечно, не текстовый, но зато оно нет требует никаких постоянно
 >> работающих процессов, как рекомендованный в соседнем письме mysql.
 >>
 >> Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
 >> поддержка sqlite в стандартной библиотеке.
 >>
 >> Я вообще считаю, что писать "на баше" не следует никогда. Если ты
 >> пишешь шелловский скрипт, он должен быть совместимым со
 >> стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
 >> /bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
 >> юниксовым Bourne Shell (из ближайшего соляриса).
 >>
 >> Если же возможностей bourne shell не хватает, стоит сразу
 >> переориентироваться на perl, python, ruby или lua.
 >>
 > Вроде бы нашел, что искал - GNU recutils.
 > www.gnu.org/software/recutils

 > кто-то пользовался? Стоит начинать процесс штудирования мануала? В описании
 > инструмента есть аргументы, почему не Mysql и не Sqlite.

Не пользовался. Но выглядит интересно. Человеко-читаемое содержимое плюс
ссылочная система явно, судя по терминологии, из баз данных - это очень
хорошая идея. Если на этом достаточно удобно выражаться, то понятно,
почему не sqlite, не говоря уже про mysql.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Dmitry Alexandrov]

>> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
>> стесняйтесь (общение в рамках решения этой задачи является частью fun'а)
>>
>> Требования:
>>
>>     1. Хранение данных в текстовом виде
>>
>>     2. Интерфейс командной строки (с прицелом на дальнейший запил
>> bash-скриптов для автоматизации)
>>
>>     3. Как можно минималистичнее во всем. Принцип "suck less" превыше всего.
>>
>>     4. Возможность сразу без допилов получать репорты по связанным
>> данным. Т.е. груши любят: Петя, Вася, Таня ; Петя любит: яблоки, груши, Таню.

> Вроде бы нашел, что искал - GNU recutils.

В каком смысле?  Там нет ничего, что можно было назвать «поддержкой структур 
многие-ко-многим».

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

> кто-то пользовался? Стоит начинать процесс штудирования мануала?

Да, конечно, весьма полезная штучка.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Denis]

21.02.2018 19:51, Victor Wagner пишет:

В Wed, 21 Feb 2018 18:45:12 +0700
Denis  пишет:


Привет!

Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
стесняйтесь (общение в рамках решения этой задачи является частью
fun'а)

Используйте обычные coreutils. Их возможности (если вместе с awk)
вполне достаточны для решения поставленной задачи.
Храните данные в формате Tab separated  по одной таблице в файле и
впред.

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

Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
поддержка sqlite в стандартной библиотеке.

Я вообще считаю, что писать "на баше" не следует никогда. Если ты
пишешь шелловский скрипт, он должен быть совместимым со
стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
/bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
юниксовым Bourne Shell (из ближайшего соляриса).

Если же возможностей bourne shell не хватает, стоит сразу
переориентироваться на perl, python, ruby или lua.


Вроде бы нашел, что искал - GNU recutils.
www.gnu.org/software/recutils

кто-то пользовался? Стоит начинать процесс штудирования мануала? В 
описании инструмента есть аргументы, почему не Mysql и не Sqlite.


--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Artem Chuprina]

Denis -> debian-russian@lists.debian.org  @ Mon, 26 Feb 2018 10:17:12 +0700:

 >>   >> Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
 >>   >> поддержка sqlite в стандартной библиотеке.
 >>   >>
 >>   >> Я вообще считаю, что писать "на баше" не следует никогда. Если ты
 >>   >> пишешь шелловский скрипт, он должен быть совместимым со
 >>   >> стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
 >>   >> /bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
 >>   >> юниксовым Bourne Shell (из ближайшего соляриса).
 >>
 >>   >> Если же возможностей bourne shell не хватает, стоит сразу
 >>   >> переориентироваться на perl, python, ruby или lua.
 >>   >>
 >>   > Об этом спорить не буду, уверен, что ваша позиция при рассмотрении в
 >>   > более крупном масштабе правильнее моей, но т.к. в качестве шелла мне
 >>   > приходится использовать только bash, то и писать буду на нем. А
 >>   > укрупняться в этом смысле мне в ближайшие годы вряд ли придется
 >>   > , т.к. хватает возможностей Bourne Again Shell.
 >>
 >> Пользоваться башем интерактивно можно. А вот писать на нем нельзя.
 >>
 > Ну как же нельзя?

 > #!/bin/bash — и вот я пишу на баше. Ну ладно, если хотите, то — для баша.

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

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[yuri . nefedov]

On Mon, 26 Feb 2018, Denis wrote:


22.02.2018 15:03, Artem Chuprina пишет:


Пользоваться башем интерактивно можно. А вот писать на нем нельзя.


Ну как же нельзя?

#!/bin/bash — и вот я пишу на баше. Ну ладно, если хотите, то — для баша.



 Это было философское замечание )
Ю.

p.s. Да и «Наше Всё» почти что об этом написал

Движенья нет, сказал мудрец брадатый.
Другой смолчал и стал пред ним ходить.
Сильнее бы не мог он возразить;
Хвалили все ответ замысловатый.

Но, господа, забавный случай сей
Другой пример на память мне приводит:
Ведь каждый день пред нами солнце ходит,
Однако ж прав упрямый Галилей.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Denis]

22.02.2018 15:03, Artem Chuprina пишет:

  >> Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
  >> поддержка sqlite в стандартной библиотеке.
  >>
  >> Я вообще считаю, что писать "на баше" не следует никогда. Если ты
  >> пишешь шелловский скрипт, он должен быть совместимым со
  >> стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
  >> /bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
  >> юниксовым Bourne Shell (из ближайшего соляриса).

  >> Если же возможностей bourne shell не хватает, стоит сразу
  >> переориентироваться на perl, python, ruby или lua.
  >>
  > Об этом спорить не буду, уверен, что ваша позиция при рассмотрении в
  > более крупном масштабе правильнее моей, но т.к. в качестве шелла мне
  > приходится использовать только bash, то и писать буду на нем. А
  > укрупняться в этом смысле мне в ближайшие годы вряд ли придется
  > , т.к. хватает возможностей Bourne Again Shell.

Пользоваться башем интерактивно можно. А вот писать на нем нельзя.


Ну как же нельзя?

#!/bin/bash — и вот я пишу на баше. Ну ладно, если хотите, то — для баша.

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Artem Chuprina]

Victor Wagner -> debian-russian@lists.debian.org  @ Thu, 22 Feb 2018 12:11:35 
+0300:

 >> Если говорить о tab separated и однострочниках, то однозначный выбор
 >> языка - perl.
 > А еще у perl DBD::CSV есть.

Интерфейс DBD в перле плохо сочетается с однострочниками.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Victor Wagner]

On Thu, 22 Feb 2018 11:03:22 +0300
Artem Chuprina  wrote:


> 
> Если говорить о tab separated и однострочниках, то однозначный выбор
> языка - perl.
А еще у perl DBD::CSV есть.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Artem Chuprina]

Denis -> Victor Wagner  @ Thu, 22 Feb 2018 00:15:43 +0700:

 >>> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
 >>> стесняйтесь (общение в рамках решения этой задачи является частью
 >>> fun'а)
 >> Используйте обычные coreutils. Их возможности (если вместе с awk)
 >> вполне достаточны для решения поставленной задачи.
 >> Храните данные в формате Tab separated  по одной таблице в файле и
 >> впред.
 > awk и Tab separated — почти то, что нужно.

 > Но учитывая, что awk пользуюсь не часто, а очень редко, то решение задачи по
 > организации простейших репортов в моем случае подходит под определение 
 > "допил"
 > (см. 4-й пункт). Буду признателен если подскажите ссылку на однострочники или
 > кратчайший туториал по использованию инструмента в контексте моей
 > задачи. Кратчайший означает, что его содержимое сводится к формуле "хочешь 
 > так
 > — пиши вот эту строчку" и не потребует от меня умственных усилий по синтезу
 > нужных команд для малознакомого инструмента.

Если говорить о tab separated и однострочниках, то однозначный выбор
языка - perl.

 >> Если же хочется использовать sql, то рекомендую sqlite. У него формат,
 >> конечно, не текстовый, но зато оно нет требует никаких постоянно
 >> работающих процессов, как рекомендованный в соседнем письме mysql.
 > sqlite - на самый крайний случай, если не найдется ничего более
 > удовлетворительного по 3-му пункту (awk, например, больше "suck less" чем
 > питон и sqlite).

Я бы, пожалуй, взял все-таки sqlite. А в качестве языка - SQL, ага. У
sqlite есть одноименная команднострочная утилита.

 >> Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
 >> поддержка sqlite в стандартной библиотеке.
 >>
 >> Я вообще считаю, что писать "на баше" не следует никогда. Если ты
 >> пишешь шелловский скрипт, он должен быть совместимым со
 >> стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
 >> /bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
 >> юниксовым Bourne Shell (из ближайшего соляриса).

 >> Если же возможностей bourne shell не хватает, стоит сразу
 >> переориентироваться на perl, python, ruby или lua.
 >>
 > Об этом спорить не буду, уверен, что ваша позиция при рассмотрении в
 > более крупном масштабе правильнее моей, но т.к. в качестве шелла мне
 > приходится использовать только bash, то и писать буду на нем. А
 > укрупняться в этом смысле мне в ближайшие годы вряд ли придется
 > , т.к. хватает возможностей Bourne Again Shell.

Пользоваться башем интерактивно можно. А вот писать на нем нельзя.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Denis]

21.02.2018 19:51, Victor Wagner пишет:

В Wed, 21 Feb 2018 18:45:12 +0700
Denis  пишет:


Привет!

Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
стесняйтесь (общение в рамках решения этой задачи является частью
fun'а)

Используйте обычные coreutils. Их возможности (если вместе с awk)
вполне достаточны для решения поставленной задачи.
Храните данные в формате Tab separated  по одной таблице в файле и
впред.

awk и Tab separated — почти то, что нужно.

Но учитывая, что awk пользуюсь не часто, а очень редко, то решение 
задачи по организации простейших репортов в моем случае подходит под 
определение "допил" (см. 4-й пункт). Буду признателен если подскажите 
ссылку на однострочники или кратчайший туториал по использованию 
инструмента в контексте моей задачи. Кратчайший означает, что его 
содержимое сводится к формуле "хочешь так — пиши вот эту строчку" и не 
потребует от меня умственных усилий по синтезу нужных команд для 
малознакомого инструмента.





Если же хочется использовать sql, то рекомендую sqlite. У него формат,
конечно, не текстовый, но зато оно нет требует никаких постоянно
работающих процессов, как рекомендованный в соседнем письме mysql.
sqlite - на самый крайний случай, если не найдется ничего более 
удовлетворительного по 3-му пункту (awk, например, больше "suck less" 
чем питон и sqlite).

Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
поддержка sqlite в стандартной библиотеке.

Я вообще считаю, что писать "на баше" не следует никогда. Если ты
пишешь шелловский скрипт, он должен быть совместимым со
стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
/bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
юниксовым Bourne Shell (из ближайшего соляриса).



Если же возможностей bourne shell не хватает, стоит сразу
переориентироваться на perl, python, ruby или lua.


Об этом спорить не буду, уверен, что ваша позиция при рассмотрении в
более крупном масштабе правильнее моей, но т.к. в качестве шелла мне
приходится использовать только bash, то и писать буду на нем. А
укрупняться в этом смысле мне в ближайшие годы вряд ли придется
, т.к. хватает возможностей Bourne Again Shell.

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Denis]

mysql и прочее такое, что требует висящего процесса отпадает однозначно. 
Совершенно не удовлетворяет третьему условию.



21.02.2018 18:52, Alexei Iliin пишет:

$ mysql -u root -p
> create database superdb collate utf8_unicode_ci;
> use superdb;



21 февраля 2018 г., 14:45 пользователь Denis > написал:


Привет!

Предложите инструмент по сабжу. Решается задача для fun'a, поэтому
не стесняйтесь (общение в рамках решения этой задачи является
частью fun'а)

Требования:

1. Хранение данных в текстовом виде

2. Интерфейс командной строки (с прицелом на дальнейший запил
bash-скриптов для автоматизации)

3. Как можно минималистичнее во всем. Принцип "suck less"
превыше всего.

4. Возможность сразу без допилов получать репорты по связанным
данным. Т.е. груши любят: Петя, Вася, Таня ; Петя любит: яблоки,
груши, Таню.


-- 
⢀⣴⠾⠻⢶⣦

⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄




--
===
Сердюков Денис

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Victor Wagner]

В Wed, 21 Feb 2018 18:45:12 +0700
Denis  пишет:

> Привет!
> 
> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не 
> стесняйтесь (общение в рамках решения этой задачи является частью
> fun'а)

Используйте обычные coreutils. Их возможности (если вместе с awk)
вполне достаточны для решения поставленной задачи.
Храните данные в формате Tab separated  по одной таблице в файле и
впред.

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

Ну и скрипты лучше писать не на баше, а на питоне. Благо у него
поддержка sqlite в стандартной библиотеке.

Я вообще считаю, что писать "на баше" не следует никогда. Если ты
пишешь шелловский скрипт, он должен быть совместимым со
стандартным /bin/sh. Повторяю - не с ash, который у нас обычно заменяет
/bin/sh, не с фрибсдшным /bin/sh (хотя и с ними тоже), а с настоящим
юниксовым Bourne Shell (из ближайшего соляриса). 

Если же возможностей bourne shell не хватает, стоит сразу
переориентироваться на perl, python, ruby или lua.



-- 
   Victor Wagner 

Re: Минималистичный инструмент для организации хранения структуры данных "многие ко многим"

[Alexei Iliin]

$ mysql -u root -p
> create database superdb collate utf8_unicode_ci;
> use superdb;



21 февраля 2018 г., 14:45 пользователь Denis 
написал:

> Привет!
>
> Предложите инструмент по сабжу. Решается задача для fun'a, поэтому не
> стесняйтесь (общение в рамках решения этой задачи является частью fun'а)
>
> Требования:
>
> 1. Хранение данных в текстовом виде
>
> 2. Интерфейс командной строки (с прицелом на дальнейший запил
> bash-скриптов для автоматизации)
>
> 3. Как можно минималистичнее во всем. Принцип "suck less" превыше
> всего.
>
> 4. Возможность сразу без допилов получать репорты по связанным данным.
> Т.е. груши любят: Петя, Вася, Таня ; Петя любит: яблоки, груши, Таню.
>
>
> --
> ⢀⣴⠾⠻⢶⣦
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋
> ⠈⠳⣄
>
>