1. bash / Говнокод #12767

    −123

    1. 1
    if ps ax | grep -v grep | grep keydispatcher > /dev/null

    no comments. но блин, даже "работает". т.е. без этого grep -v grep лажает, а с ним - нет (видимо потому что второй греп не успевает запуститься пока ps ax отрабатывает). однако...

    Запостил: Pencioner, 18 Марта 2013

    Комментарии (18) RSS

    • ava bormand 18.03.2013 20:57 # 0

      [deleted]
      Ответить

    • ava myaut 18.03.2013 22:27 # 0

      bormand, тоже про пользователя keydispatcher подумал?
      Ответить

    • ava Dummy00001 18.03.2013 23:51 # +1

      > а с ним - нет

      на линухе тестируешь? на солярке без `grep -v grep` на конце ни как. "ps | grep cmd" стабильно в выводе показывает сам grep. с другой стороны там есть (как и в современных линухах) pgrep.
      Ответить

      • ava guest 19.03.2013 00:57 # 0

        да на Линухе тоже без него никак. тут вот товарищи кстати подсказали классную фишку, например

        ps ax | grep [f]irefox


        и не надо grep -v :) однако красиво
        Ответить

        • ava Dummy00001 19.03.2013 01:14 # 0

          "ps ax | grep [f]irefox"

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

          а если делать для новых систем, то pgrep/pkill работают просто на ура - pgrep '^firefox$'. даже это мудачество хп-сукс в 11.31 завел pgrep/pkill.
          Ответить

          • ava Pencioner 19.03.2013 12:14 # 0

            насчет pgrep и прочего - однако, на ембеддед системе не все команды есть, и даже в тех что есть не весь функционал есть. например у find нету предиката -iname - только -name ... обходимся чем есть...
            Ответить

    • ava VseGovnoOdinYaKrut 19.03.2013 12:18 # +4

      Ехал грепа через грепу
      Видит в грепе грепа грепу
      Взял за грепы грепа грепу
      Грепа грепу, грепе — грепа

      А постящий таки неосилил конвееры и параметры grep, никакой магии тут нет.
      Ответить

      • ava Pencioner 19.03.2013 12:35 # 0

        смотрим - вывод команды ps ax пропускается на вход первого grep
        потом вывод первого grep пропускается через второй grep
        разобрался, почему оно "работает", но это сугубо зависящий от текущей реализации bash-а побочный эффект. именно - баш начинает запускать программы которые он на конвеер ставит начиная с последней. поэтому когда уже вызывается execve для 'ps ax' - у нас в списке запущенных процессов оба грепа есть, соответственно первый grep их отфильтрует...
        Ответить

        • ava VseGovnoOdinYaKrut 19.03.2013 13:32 # 0

          Запускает он в прямом порядке, убедится в этом можно по pid:
          % ps ax | grep 'ps ' | grep 'ps '
 5022 pts/0    R+     0:00 ps ax
 5023 pts/0    S+     0:00 grep ps 
 5024 pts/0    S+     0:00 grep ps

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

          • ava Pencioner 19.03.2013 13:37 # 0

            pid однозначно указывает только в каком порядке fork() произошел )))) exec-и замещают процесс (в нашем случае копию после fork()), при этом pid и еще всякое разное (в т.ч. дескрипторы файлов с неустановленным close-on-exec флагом) остаются в новом процессе...
            Ответить

            • ava VseGovnoOdinYaKrut 19.03.2013 14:16 # 0

              Кстати
              date +1~%T.%N >&2 | date +2~%T.%N >&2 | date +3~%T.%N >&2 | date +4~%T.%N >&2

              на баше рандомный результат, а на zsh всё по-порядку.
              Ответить

              • ava bormand 19.03.2013 15:39 # +1

                > а на zsh всё по-порядку
                Но это, тем не менее, совсем не повод пользоваться подобным поведением. Это ведь классический race condition.
                Ответить

                • ava Pencioner 19.03.2013 15:55 # 0

                  если какое-то поведение детерминированно для конкретного шелла но стандартом не гарантируется - то ну его в пень, использовать, без супер-веских на то оснований. хотя знать про такие штуки полезно всегда
                  Ответить

                  • ava bormand 19.03.2013 16:24 # +1

                    У меня кстати и в zsh рандомит. Поэтому наблюдение совершенно бесполезное.

                    P.S. ОМГ. У zsh еще и записи в выхлопе пропадают. Пару раз из 10 она выдала мне только 2 строчки из 4. Вот это поведение куда более веселое...
                    Ответить

                    • ava Pencioner 19.03.2013 19:10 # 0

                      (большие круглые глаза) фигасе!
                      Ответить

                    • ava VseGovnoOdinYaKrut 19.03.2013 20:09 # 0

                      Так почему бесполезное? Оно как раз и доказывает, что поведение непредсказуемое.
                      Ответить

    Добавить комментарий