LINUX.ORG.RU

[bash][config] Разделяемы конфиги

 ,


0

1

Есть набор скриптов на bash (хотя это не принципиально - может быть что угодно - вопрос идиологический) и конфиг.

Одному скрипту нужны все переменные этого конфига, другому только 4, а третьему только одна. Ну это к примеру.

Как быть?

1. Разнести всё по 3 конфигам и пусть первый скрипт грузит все три, второй скрипт только второй, а третий - только третий.
2. Пусть все скрипты грузят только один конфиг и наплевать на лишние определённые в них переменные.
3. Во втором и третьем скрипте распарсить конфиг sed'ом и определить только нужные переменные.
4. Как в 2, но во втором и третьем скрипте сбросить лишние переменные unset'ом.
5. ???77

1. Пользователю такой гемор ненужен, да и непонятно что делать если в третьем скрипте потребуется переменная из тех 4 что нужны второму.
2. Самый простой и логичный путь. Но во-первых хочется поэкономить память, да и уютнее когда занешь что лишних определённых переменных нет - на душе спокойно. А во-вторых некрасиво это.
3. Вообще бред - дергать сед для освобождения памяти от двух десятков ненужных переменных.
4. Вообще костыль.

А вы как бы сделали? А как правильно?

★★★★★

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

Взять 1 конфиг. Выбросить баш и написать на нормальном языке с нормальным парсингом конфигов.

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

То есть твой вариант - парсить.

А какой язык «нормальный»? И зачем какую-нибудь примитивную приблуду писать на нормальном языке, если баша с головой?

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

Чем сложнее программа, тем меньше причин писать её на баше. «Нормальный язык» это, в принципе, любой, который знаешь, из тех, что имеют нормальную систему типов, нормальные языковые конструкции без вызова внешних костылей и т.д. Питон, руби, и др. Хоть C, но это уже если очень хочется.

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

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

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

На самом деле прога настолько простая, что даже не стал писать на Tcl, как раз из-за парсинга конфигов. А когда уже выяснилось, что нужен демон+несколько управляющих скриптов, то тут уже и переписывать лень.

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

А, задачу уже решил давно. Катафоты от нечего делать прикручиваю.

Suntechnic ★★★★★
() автор топика

>2. Пусть все скрипты грузят только один конфиг и наплевать на лишние определённые в них переменные.
Самый правильный вариант.

хочется поэкономить память

Посчитай, сколько сэкономишь в байтах. Округли до ближайшей страницы (4 килобайта).
Учти, что на код парсера тоже нужна память.

некрасиво это.

Э?

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

Некрасиво, потому, что определяются лишние сущности.

Да - я так и написал - самый логичный вариант. Вобщем-то вопрос был в том - нет ли какого-то ещё простого и изящного варика. Память кстати округлять до страниц не надо - переменные занимают столько сколько занимают.

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

А... В этих скриптах настолько часто юзается sed, что я уже всё на него валю ;)

Suntechnic ★★★★★
() автор топика

Только 2.
Экономить килобайты? Очень надуманный аргумент в наше время.
Для ясности - отделить переменные в блоки и комментариями, чтобы тому кто будет править - всё сразу стало ясно.

Если очень хочется работы - можно сделать префикс (какой модуль) и этот префикс вырезать скриптом а переменные с чужим префиксом - не грузить.

Например:

модуль1.цвет=ХХЫЫЗЗ
модуль1.размер=много

модуль2.что-то ещё=бла-бла-бла

модуль3.что-угодно=асдфасдфадфадф

siberean
()

Я обычно иду по второму пути. Но переменные в конфиге использую с префиксом.

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

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

ОК

На том и порешим. Действительно логично - парсинг может отжрать больше памяти чем переменные. На блоки конечно разбил и комментов добавил.

Кстати, а как расходуется память на хранение переменных в bash? (имя.символов+значение.символов)*utf8? не?

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

Динамически (т.е. нет ограничения, если не экспортируем): и количество переменных и имена, но я бы всё же делал короткие имена. Во-первых - для портабилити с другими шеллами (я вообще обычно пишу на Борн-шелле, работающем везде, можно считать это подмножеством Баша, неиспользующее Баш-специфические фичи, а там длина имени переменной на какой-нибудь системе может иметь предел и 256). Во-вторых, длинные имена переменных (как впрочем и значения) в конфиге скорее всего свидетельствуют о плохом дизайне.
И да, сегодня вроде везде UTF8 и я не уверен что нужно стараться убыстрить путём переопределения LANG на ASCII, если это конечно не очень специфический случай.

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