The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Framework bash, !*! obl, 21-Июл-14, 20:47  [смотреть все]
Добрый день! довно пишу на bash скрипты для автоматизации.
Сейчас ищу фреймворк позволяющий в псевдографике отрисовывать окошки, логировать в сислог, файл, читать конфигурационные файлы и принимать параметры.
Подскажите есть ли чтото подобное?

пока я нашел вот это:
http://www.bashinator.org/
http://xgu.ru/wiki/shell-framework

  • Framework bash, !*! pavlinux, 03:13 , 22-Июл-14 (1)
    > Добрый день! довно пишу на bash скрипты для автоматизации.
    > Сейчас ищу фреймворк позволяющий
    >в псевдографике отрисовывать окошки,

    $ dialog --pause "$(cat /proc/meminfo)" 50 70 5

    > логировать в сислог,

    echo ......... >> /var/log/log.log

    > файл,

    14

    > читать конфигурационные файлы

    source конфигурационные.файлы

    > и принимать параметры.

    echo $@

    ---
    http://ru.wikipedia.org/wiki/PyGTK

    • Framework bash, !*! obl, 10:07 , 22-Июл-14 (2) –1
      >[оверквотинг удален]
      > $ dialog --pause "$(cat /proc/meminfo)" 50 70 5
      >> логировать в сислог,
      > echo ......... >> /var/log/log.log
      >> файл,
      > 14
      >> читать конфигурационные файлы
      > source конфигурационные.файлы
      >> и принимать параметры.
      > echo $@
      > ---

      Это начальный уровень. А если я заходчу логировать в другой файл, или в сислог, или в консоль?
      Вот посмотрите как красиво эти вещи можно сделать посредством фреймфорка:
      http://www.bashinator.org/#documentation

      • Framework bash, !*! pavlinux, 13:41 , 22-Июл-14 (4)
        > А если я заходчу логировать в другой файл, или в сислог, или в консоль?

        Скрипты пишут для каких-то задач. У тебя задача - разрисовать экран. ... ну да, бери любой.

        tput, dialog, tcl, echo -ne "[\033" ...
          

    • Framework bash, !*! pavel_simple, 12:27 , 22-Июл-14 (3)

      >> логировать в сислог,
      > echo ......... >> /var/log/log.log

      павлин -- ты чему поросль воспитываиш?
      man logger

      • Framework bash, !*! obl, 13:46 , 22-Июл-14 (6)
        >>> логировать в сислог,
        >> echo ......... >> /var/log/log.log
        > павлин -- ты чему поросль воспитываиш?
        > man logger

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

        • Framework bash, !*! Andrey Mitrofanov, 19:39 , 22-Июл-14 (14)
          >>>> логировать в сислог,
          >>> echo ......... >> /var/log/log.log
          >> павлин -- ты чему поросль воспитываиш?
          >> man logger
          > Ну разумеется, для начала неплохо.. а если скрипт большой, в некоторых случаях
          > необходимо вывод выводить в файл, в некоторых в сислог, в некоторых

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

          Так вот, как шелл и в в качестве _скриптового языка он больше приспособлен и направлен на связывание вызовов других програм, нежели чем на написание всего-всего на нём _самом. Поэтому, когда скрипт превышает 100-200-300 строк, возникает необходимость выноса кусков кода в модули/функции. Так _могут появиться (а могут и не появиться) _библиотеки функций шела. В принципе, примеры таковых _библиотек находятся в поисковиках. Но! Все они, доросши(извините) до определённого размера (10-15К? 1000+ строк?) и/или решив текущие задачи автора, превращаются в _брошенные проекты (если вообще публикуются и пр.).

          Решение _не свойственных шеллу задач (разбор html, например; syslog-гирование и рисование окошек у Вас) естественным образом делается во вне шелла, вызовом внешних процессов/програм. _Поэтому до этих задач или тем более всеобъемлющих "фреймворков" те библиотеки шелл-функций _не _дорастают.

          Но даже если бы и можно было всё-всё это написать на [чистом] шелле, на таких объёмах выразительные средства языка становятся препятствием для поддержания кода. Тяжело, сложно, утомительно становится.

          > более-менее детальным делать, дебаг включать? Для этого существуют фреймворки. о которых
          > я и спрашиваю :)

          Я, если это кому интересно, не решил [поленился, наверное] выписывать многоуровневое/многомодульное тонко-гранулированное включение-выключение дебага. Т.о. есть один -d/--debug и все функции скрипта (а их много=) просто валят подробный лог на stderr.

          PS: Я уверен, коллегам, не сумевшим донести эту простую мысль до Вас, стыдно за свои выпады, у них горят уши и сжимается со свистом карма. Но и Вам следовало прислушаться к их ответам, и не вставать в позу и требовать, чтобы все немедленно посоответствовали Вашим хотелкам. Выглядит это, мягко говоря, странно.

          --Успехов

          • Framework bash, !*! obl, 20:00 , 22-Июл-14 (15)
            > bash является шеллом прежде всего, а уж языком программирования уже во вторую
            > очередь.

            Разве ктото с этим спорит?

            > Так вот, как шелл и в в качестве _скриптового языка он больше
            > приспособлен и направлен на связывание вызовов других програм, нежели чем на
            > написание всего-всего на нём _самом. Поэтому, когда скрипт превышает 100-200-300 строк,
            > возникает необходимость выноса кусков кода в модули/функции. Так _могут появиться (а
            > могут и не появиться) _библиотеки функций шела. В принципе, примеры таковых
            > _библиотек находятся в поисковиках. Но! Все они, доросши(извините) до определённого размера
            > (10-15К? 1000+ строк?) и/или решив текущие задачи автора, превращаются в _брошенные
            > проекты (если вообще публикуются и пр.).

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


            > Решение _не свойственных шеллу задач (разбор html, например; syslog-гирование и рисование
            > окошек у Вас) естественным образом делается во вне шелла, вызовом внешних
            > процессов/програм. _Поэтому до этих задач или тем более всеобъемлющих "фреймворков" те
            > библиотеки шелл-функций _не _дорастают.

            Позвольте обратить ваш взор на OCF... к примеру.

            > Но даже если бы и можно было всё-всё это написать на [чистом]
            > шелле, на таких объёмах выразительные средства языка становятся препятствием для поддержания
            > кода. Тяжело, сложно, утомительно становится.
            >> более-менее детальным делать, дебаг включать? Для этого существуют фреймворки. о которых
            >> я и спрашиваю :)
            > Я, если это кому интересно, не решил [поленился, наверное] выписывать многоуровневое/многомодульное
            > тонко-гранулированное включение-выключение дебага. Т.о. есть один -d/--debug и все функции
            > скрипта (а их много=) просто валят подробный лог на stderr.

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

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

            Коллеги как я понял не владеют вопросом.. и советуют что попало. К сожалению.

            > --Успехов

            • Framework bash, !*! Andrey Mitrofanov, 20:32 , 22-Июл-14 (16)
              >> Я, если это кому интересно, не решил [поленился, наверное] выписывать многоуровневое/многомодульное
              >> тонко-гранулированное включение-выключение дебага. Т.о. есть один -d/--debug и все функции
              >> скрипта (а их много=) просто валят подробный лог на stderr.
              > Поленились взять готовое, согласен. Я тоже ленился очень долго, теперь обратился к
              > сообществу, и вижу что все ленятся и считают это нормой. Более
              > того, вспоминается анекдот.. сидят все в дерьме один шевельнулся, и остальные
              > на него - не гони волну!

              Все считают, что инструмент должен соответствовать задаче.

              Многие видели shell-инсталяторы от "кровавых" ентерпрайзов и _не считают такое приемлемым для своих проектов.

              Многие видели ./configure.sh и понимают разницу.

              Многие "сидят в дерьме" и считают, что все остальные такие же.

              Ждём немедленного и окончательного решения Вами этих проблем, прекратите уже нападки и отговорки!

              >> --Успехов

  • Framework bash, !*! Led, 14:16 , 22-Июл-14 (7)
    > довно пишу на bash

    Судя по вопросу, очень давно. Наверное, уже третий день.

  • Framework bash, !*! universite, 17:17 , 22-Июл-14 (9)
    > Добрый день! довно пишу на bash скрипты для автоматизации.

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

      • Framework bash, !*! pavlinux, 19:18 , 22-Июл-14 (11)
        > ответы на незаданные вопросы зовутся флудом.

        Панимаешь в чём вся хня...

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

        2. Скрипт запускается один раз и ты его не видишь! На работу скриптов смотрят только идиоты.

        3. Логи от скриптов так же интересны как и стихи Дарьи Донцовой.

        4. Всё уже изобрели. (colordiff, ccze, grep --color, ls --color, mutt, centericq,...)

        5. Болезнь разукрашивания скриптов проходит прим. через месяц.

        Так что, 1 сентября заходи, расскажешь. :)

          • Framework bash, !*! pavlinux, 19:28 , 22-Июл-14 (13)
            > Вы вообще понимаете что такое фреймворк?

            Да, - это куча ненужного говна, потом и пишу только на bash и С.

            > приступая к написанию нового скрипта изобретаете те пункты которые сами описали.

            Не, я их копипастю из предыдущих.

            > 2. Судя по такому тону вы не писали сложных скриптов.

            Да, я этого не умею. У меня все скрипты простые, читаемые и легопонимаемые.

            > ... никогда не занимались расследованием инцидентов, падений.

            Не, сразу пишу рабочее.
            ---

            В общем, как уже написал "Болезнь разукрашивания скриптов проходит прим. через месяц."  
            Но все должны пройти через это!!! :)




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

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