Não é possível executar uma função zsh incluindo less

Este é um bug que afeta o zsh 5.9 . Foi corrigido em novembro de 2022, mas não houve nenhum lançamento desde dezembro de 2024.

Se você fizer:

$ find . | less
^Z
zsh: suspended  find . | less
$ ps -Ho pid,ppid,pgid,tpgid,args
    PID    PPID    PGID   TPGID COMMAND
  11094    5260   11094   11150 /bin/zsh
  11128   11094   11128   11150   find .
  11129   11094   11128   11150   less
  11150   11094   11150   11150   ps -Ho pid,ppid,pgid,tpgid,args
$ jobs -p
[1]  + 11128 suspended  find . |
             suspended  less

11128 é de fato o PGID do trabalho que tem finde less, e a retomada funciona bem, mas:

$ f() {find . -type f | less}
$ f
zsh: suspended  find . -type f |
$ ps -Ho pid,ppid,pgid,tpgid,args
    PID    PPID    PGID   TPGID COMMAND
  11094    5260   11094   11520 /bin/zsh
  11492   11094   11492   11520   find . -type f
  11493   11094   11492   11520   less
  11501   11094   11501   11520   /bin/zsh
  11520   11094   11520   11520   ps -Ho pid,ppid,pgid,tpgid,args
$ jobs -p
[1]  + 11493 suspended  find . -type f |
             suspended

Desta vez, 11493 é o PID de less, não o PGID do trabalho que tem ambos finde lessque é 11492.

Então, quando fgtenta colocar o trabalho em primeiro plano, ele faz um tcsetpgrp(11493)que não consegue colocar esse trabalho em primeiro plano, então continua retomando todos os processos com SIGCONT, e acontece que lessao retomar faz um tcsetattr()(o que o sttycomando normalmente faz) que os processos em segundo plano não têm permissão para fazer, então todo o grupo de processos recebe um sinal SIGTTOU e é suspenso novamente.

Aqui, uma solução alternativa seria alterar a definição da função para:

f() (find . | less)

Ou seja, use um subshell em vez de um grupo de comando como o corpo da função, para que haja apenas um processo com o qual o processo pai precisa se preocupar e não haja espaço para confusão.

Usando:

f() {less < <(find .)}

Também parece funcionar (embora implique um processo adicional por algum motivo).

O controle de tarefas é um negócio bem complicado, especialmente quando, como o zsh ou o ksh fazem, você tenta executar o lado direito de um pipeline no shell atual e, como o zsh ou o AT&T ksh, você tenta ter um comportamento mais útil ao pressionar ^Z em um comando composto (como o corpo da sua ffunção aqui).

Observe o processo extra 11501 que apareceu acima quando ffoi suspenso. Ele está lá para que o resto da função possa continuar após o find, lessser retomado (com fgou bg) e eventualmente terminar.

Veja como no bash ou mksh, se você fizer isso:

f() { sleep 100; echo here; }
f

E aperte ^Z, sleepestá suspendendo mas echo hereé executado naquele ponto ! E então se você fg, sleepé retomado, mas o resto da função já foi executado!

Veja o comentário explicando isso no código:

/*
 * Job control in zsh
 * ==================
 *
 * A 'job' represents a pipeline; see the section JOBS in zshmisc(1)) for an
 * introduction.  The 'struct job's are allocated in the array 'jobtab' which
 * has 'jobtabsize' elements.  The job whose processes we are currently
 * preparing to execute is identified by the global variable 'thisjob'.
 *
 * A 'superjob' is a job that represents a complex shell construct that has been
 * backgrounded.  For example, if one runs '() { vi; echo }', a job is created
 * for the pipeline 'vi'.  If one then backgrounds vi (with ^Z / SIGTSTP),
 * the shell forks; the parent shell returns to the interactive prompt and
 * the child shell becomes a new job in the parent shell.  The job representing
 * the child shell to the parent shell is a superjob (STAT_SUPERJOB); the 'vi'
 * job is marked as a subjob (STAT_SUBJOB) in the parent shell.  When the child
 * shell is resumed (with fg / SIGCONT), it forwards the signal to vi and,
 * after vi exits, continues executing the remainder of the function.
 * (See workers/43565.)
 */

Um dos problemas (e não sei o quanto isso contribui para o problema discutido aqui; edite , provavelmente não estou olhando para a correção ) é que esse "superjob" não é o pai dos processos que foram suspensos, então, por exemplo, não pode obter seu status de saída:

$ { (sleep 4; exit 4); echo "$?"; }
^Zzsh: suspended  ( sleep 4; exit 4; )
$ fg
[1]  + continued  ( sleep 4; exit 4; )
148
$

echo "$?"foi de fato executado após (sleep...)ser encerrado e não quando foi suspenso como em bash, mas $?reflete um status suspenso, não o que 4você esperaria.

Conforme sugerido no comentário acima, você pode encontrar o comportamento descrito em zshmisc(1)ou info zsh jobs:

Note que se o trabalho em execução em primeiro plano for uma função de shell, então suspendê-lo terá o efeito de fazer com que o shell bifurque. Isso é necessário para separar o estado da função daquele do shell pai que executa o controle do trabalho, para que este último possa retornar ao prompt da linha de comando. Como resultado, mesmo se fg for usado para continuar o trabalho, a função não fará mais parte do shell pai, e quaisquer variáveis ​​definidas pela função não serão visíveis no shell pai. Portanto, o comportamento é diferente do caso em que a função nunca foi suspensa. O Zsh é diferente de muitos outros shells nesse aspecto.

Um efeito colateral adicional é que o uso de disown com um job criado pela suspensão do código shell dessa forma é atrasado: o job só pode ser rejeitado quando qualquer processo iniciado do shell pai tiver terminado. Nesse ponto, o job rejeitado desaparece silenciosamente da lista de jobs.

O mesmo comportamento é encontrado quando o shell está executando código como o lado direito de um pipeline ou qualquer construção de shell complexa, como if, for, etc., para que o bloco inteiro de código possa ser gerenciado como um único trabalho. Trabalhos em segundo plano normalmente têm permissão para produzir saída, mas isso pode ser desabilitado dando o comando 'stty tostop'. Se você definir esta opção tty, os trabalhos em segundo plano serão suspensos quando tentarem produzir saída, como fazem quando tentam ler a entrada.

Quando um comando é suspenso e continuado mais tarde com os builtins fg ou wait, o zsh restaura os modos tty que estavam em efeito quando ele foi suspenso. Isso (intencionalmente) não se aplica se o comando for continuado via 'kill -CONT', nem quando for continuado com bg.