Comandos shell do Serialise

5

Estou procurando uma maneira de "empilhar" comandos a partir do prompt do terminal, para que apenas um no momento seja executado:

  • Primeiro insira um comando, pressione enter, a execução será iniciada, retorne ao shell (como & )
  • Eu posso inserir um segundo comando. Eu pressiono enter, o primeiro comando ainda não está completo, então é empilhado (diferente de & ). Mas, novamente, o aviso está de volta.

Tipo de mistura entre:

  • & para lançar em segundo plano, mas o segundo comando seria executado ao mesmo tempo que o primeiro, e eu não quero isso;
  • && ou ; para iniciar um comando após o outro, mas você deve escrevê-los todos de uma vez. Eu quero recuperar o prompt depois que o comando é executado ou empilhado.

O mais próximo que encontrei seria:

$ cmd1 &
$ wait; cmd2 &

Mas estou procurando algo um pouco mais potente, permitindo-me visualizar comandos pendentes, com falha e concluídos. Talvez algo como:

$ stackit cmd1
cmd1 started
$ stack it cmd2
cmd2 queued
$ stack it cmd3
cmd3 queued
$ stack it --
[1] running
[2] queued
[3] queued

Talvez até para permitir algum paralelismo, como 2 comandos no momento.

Isso parece bastante genérico, então não sinto vontade de reinventar a roda.

Casos de uso:

  • Copiando arquivos de e para um NAS antigo que sofre quando várias operações são executadas ao mesmo tempo
  • especifique um grande número de arquivos em que um número limitado de conexões seria preferido
por youri 28.01.2016 / 15:58

2 respostas

2

Você está pesquisando o comando spooler de tarefas . Nos repositórios do Debian / Ubuntu, o pacakage a ser instalado é task-spooler e o binário a ser chamado é tsp .

No seu caso ( && style) você pode usar

tsp -d cmd1
tsp -d cmd2
tsp -d cmd3

use então

tsp -l

para inspecionar o status da fila.

Existem formas ( -S ) de aumentar o número de trabalhos simultâneos máximos também.

    
por MaxChinni 01.05.2016 / 23:37
0

Embora bash em si não tenha o tipo "fila" ou "pilha" de controle de trabalho, mas eles têm controle de tarefa (que existe há anos, atrás de korn shell do Unix Sistema V) em que você pode colocar os processos em segundo plano, e controlá-los com o comando kill

DIR:/coreutils
skolodya@ubuntu:$ gedit &> /dev/null &
[1] 26742

DIR:/coreutils
skolodya@ubuntu:$ gnome-terminal &> /dev/null &                                
[2] 26767

DIR:/coreutils
skolodya@ubuntu:$ jobs                                                         
[2] + Running              gnome-terminal >/dev/null 2>&1 
[1] - Running              gedit >/dev/null 2>&1 

DIR:/coreutils
skolodya@ubuntu:$ kill -SIGSTOP %1                                             

DIR:/coreutils
skolodya@ubuntu:$ jobs
[1] + Stopped (signal)     gedit >/dev/null 2>&1 
[2] - Running              gnome-terminal >/dev/null 2>&1 

DIR:/coreutils
skolodya@ubuntu:$ kill -SIGCONT %1                                             

DIR:/coreutils
skolodya@ubuntu:$ jobs                                                         
[1] + Stopped (signal)     gedit >/dev/null 2>&1 
[2] - Running              gnome-terminal >/dev/null 2>&1

A saída desses comandos no exemplo acima vai para /dev/null , mas é claro que se for um aplicativo de linha de comando, você deseja redirecionar a saída para algum lugar em que possa visualizá-lo mais tarde. Por exemplo, um named pipe .

DIR:/coreutils
skolodya@ubuntu:$ mkfifo test.fifo                                             

DIR:/coreutils
skolodya@ubuntu:$ apt-cache search 1> test.fifo &
[1] 27775

DIR:/coreutils
skolodya@ubuntu:$ cat test.fifo | head -n 3                                    
screen - terminal multiplexer with VT100/ANSI terminal emulation
screen-dbg - Debugging symbols for GNU Screen
asic0x-dkms - iBurst USB modem driver in DKMS format

Aqui estou redirecionando stdout (descritor de arquivo 1) para um canal que criei e revise-o mais tarde. Isso pode ser feito com vários comandos, criando vários pipes nomeados.

Nota lateral : pode-se escrever algo com essas opções, pelo menos IMHO, é mais fácil usar apenas esses métodos de controle de trabalho sozinhos.

    
por Sergiy Kolodyazhnyy 31.01.2016 / 09:11