Tela GNU -ls sempre retorna diferente de zero?

Question

Estou fazendo alguns scripts envolvendo a tela, e parece que screen -ls sempre retorna 1. Isso é normal?

As páginas man do screen dizem que ele faz coisas interessantes se passar screen -ls -q , mas eu não estou fazendo isso (provavelmente também vale a pena notar que -q parece não funcionar).

Ok, agora estou realmente confuso. Estou procurando na fonte da tela do gnu:

if (lsflag) {
    int i, fo, oth;

    if (multi)
        real_uid = multi_uid;
    SET_GUID();
    i = FindSocket((int *)NULL, &fo, &oth, SocketMatch);
    if (quietflag) {
        if (rflag)
            exit(10 + i);
        else
            exit(9 + (fo || oth ? 1 : 0) + fo);
    }
    if (fo == 0)
        Panic(0, "No Sockets found in %s.\n", SocketPath);
    Msg(0, "%d Socket%s in %s.", fo, fo > 1 ? "s" : "", SocketPath);
    eexit(0);
}

lsflag é definido se você emitir um comando -l ou -ls , eexit is:

void eexit(int e)
{
    if (ServerSocket != -1) {
        if (setgid(real_gid))
            AddStr("Failed to set gid\r\n");
        if (setuid(real_uid))
            AddStr("Failed to set uid\r\n");
        if (unlink(SocketPath))
            AddStr("Failed to remove socket\r\n");
    }
    exit(e);
}

Nem deveria ser possível que screen -ls retornasse 1.

    

Answer 1

Mais escavações na fonte geraram a resposta. Como de costume, isso ocorre porque o debian está enviando versões antigas de componentes principais.

 if (lsflag)
    {
      int i, fo, oth;

#ifdef MULTIUSER
      if (multi)
        real_uid = multi_uid;
#endif
      SET_GUID();
      i = FindSocket((int *)NULL, &fo, &oth, SockMatch);
      if (quietflag) {
        if (rflag)
          exit(10 + i);
        else
          exit(9 + (fo || oth ? 1 : 0) + fo);
      }
      if (fo == 0)
        Panic(0, "No Sockets found in %s.\n", SockPath);
      Panic(0, "%d Socket%s in %s.\n", fo, fo > 1 ? "s" : "", SockPath);
      /* NOTREACHED */
    }

Onde o Panic é o seguinte

void Panic (int err, const char *fmt, VA_DOTS)
{
  char buf[MAXPATHLEN*2];
  PROCESS_MESSAGE(buf);

  debug3("Panic('%s'); display=%x displays=%x\n", buf, display, displays);
  if (displays == 0 && display == 0)
    {
      printf("%s\r\n", buf);
      if (PanicPid)
        Kill(PanicPid, SIG_BYE);
    }
  else if (displays == 0)
    {
      /* no displays but a display - must have forked.
       * send message to backend!
       */
      char *tty = D_usertty;
      display = 0;
      SendErrorMsg(tty, buf);
      sleep(2);
      _exit(1);
    }
  else
    for (display = displays; display; display = display->d_next)
      {
        if (D_status)
      RemoveStatus();
        FinitTerm();
        Flush(3);
#ifdef UTMPOK
        RestoreLoginSlot();
#endif
        SetTTY(D_userfd, &D_OldMode);
        fcntl(D_userfd, F_SETFL, 0);
        write(D_userfd, buf, strlen(buf));
        write(D_userfd, "\n", 1);
        freetty();
    if (D_userpid)
      Kill(D_userpid, SIG_BYE);
      }
#ifdef MULTIUSER
  if (tty_oldmode >= 0)
    {
# ifdef USE_SETEUID
      if (setuid(own_uid))
        xseteuid(own_uid);  /* may be a loop. sigh. */
# else
      setuid(own_uid);
# endif
      debug1("Panic: changing back modes from %s\n", attach_tty);
      chmod(attach_tty, tty_oldmode);
    }
#endif
  eexit(1);
}

Quanto a por que Panic() não retorna o código de erro passado para ele via err member, sua suposição é tão boa quanto a minha. Parece que o argumento -Q também está quebrado, apesar de estar presente.

Basicamente, a versão em apt está quebrada.