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

    • [deleted]
      Ответить
    • bormand, тоже про пользователя keydispatcher подумал?
      Ответить
    • > а с ним - нет

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

        ps ax | grep [f]irefox


        и не надо grep -v :) однако красиво
        Ответить
        • "ps ax | grep [f]irefox"

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

          а если делать для новых систем, то pgrep/pkill работают просто на ура - pgrep '^firefox$'. даже это мудачество хп-сукс в 11.31 завел pgrep/pkill.
          Ответить
          • насчет pgrep и прочего - однако, на ембеддед системе не все команды есть, и даже в тех что есть не весь функционал есть. например у find нету предиката -iname - только -name ... обходимся чем есть...
            Ответить
    • Ехал грепа через грепу
      Видит в грепе грепа грепу
      Взял за грепы грепа грепу
      Грепа грепу, грепе — грепа

      А постящий таки неосилил конвееры и параметры grep, никакой магии тут нет.
      Ответить
      • смотрим - вывод команды ps ax пропускается на вход первого grep
        потом вывод первого grep пропускается через второй grep
        разобрался, почему оно "работает", но это сугубо зависящий от текущей реализации bash-а побочный эффект. именно - баш начинает запускать программы которые он на конвеер ставит начиная с последней. поэтому когда уже вызывается execve для 'ps ax' - у нас в списке запущенных процессов оба грепа есть, соответственно первый grep их отфильтрует...
        Ответить
        • Запускает он в прямом порядке, убедится в этом можно по 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 прогрузится, все грепы уже будут в процессах отражаться.
          Ответить
          • pid однозначно указывает только в каком порядке fork() произошел )))) exec-и замещают процесс (в нашем случае копию после fork()), при этом pid и еще всякое разное (в т.ч. дескрипторы файлов с неустановленным close-on-exec флагом) остаются в новом процессе...
            Ответить
            • Кстати
              date +1~%T.%N >&2 | date +2~%T.%N >&2 | date +3~%T.%N >&2 | date +4~%T.%N >&2

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

                    P.S. ОМГ. У zsh еще и записи в выхлопе пропадают. Пару раз из 10 она выдала мне только 2 строчки из 4. Вот это поведение куда более веселое...
                    Ответить
                    • (большие круглые глаза) фигасе!
                      Ответить
                    • Так почему бесполезное? Оно как раз и доказывает, что поведение непредсказуемое.
                      Ответить

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