Pergunta sobre a

Question

Eu tentei usar no para agendar um trabalho em execução em um horário específico. Eu tenho um computador Mac. Por exemplo, tentei testar isso para o seguinte no Terminal:

at now + 1 minute
echo 'Test at'
<EOD>

depois de mais de 1 minuto, não vi o eco. Depois de digitar o seguinte comando:

at -l

Eu não vi nenhum emprego, mas recebi uma mensagem dizendo que tenho um e-mail. Eu fui ao meu e-mail pelo comando de correio. Eu vi uma mensagem e digitei 1. Eu vi a saída do meu trabalho no correio.

Minha primeira pergunta é que não tenho certeza se esse é o comportamento padrão para um comando ou não. Existe alguma maneira de mudar este comportamento e como alterá-lo direcionar o resultado para onde, se possível.

Meu entendimento é que, se o meu trabalho agendado tiver alguma mensagem, a mensagem de saída será enviada de volta para o meu e-mail. Minha próxima pergunta relacionada é que não tenho certeza de onde o trabalho agendado é executado. Em um fundo? Eu não consegui encontrá-lo usando o comando fg ou bg.

    

Answer 1

Na verdade, é o comportamento padrão de em , conforme declarado em man at :

The user will be mailed standard error and standard output from his commands, if any. Mail will be sent using the command sendmail(8). If at is executed from a su(1) shell, the owner of the login shell will receive the mail.

Para um comportamento diferente, você pode invocar em assim:

$ at now + 1 minute 
$ echo "test at" > /dev/ttys000
$ <EOD>

Qual redirecionará o STDOUT para o terminal ttys000. Você precisa substituir / dev / ttys000 pelo arquivo de dispositivo correspondente do seu terminal, o que você pode determinar executando o seguinte comando:

$ tty

As tarefas agendadas são executadas em seu próprio shell (consulte man at para obter mais detalhes), de modo que bg não as liste. Para ver uma lista de tarefas agendadas, você pode tentar atq ou em -l

    

Answer 2

Sim, enviar o usuário que chamou o comando at é o comportamento padrão.

A partir da página man:

Since the commands run in a separate shell invocation, running in a separate process group with no controlling terminal, open file descriptors, traps, and priority inherited from the invoking environment are lost.

Como resultado do acima, não há maneira fácil de comunicar a saída dos comandos. É claro que você pode redirecionar a saída para um arquivo ou usar um mecanismo alternativo para comunicar a saída, como parte dos comandos.

Se você não vê o trabalho agendado, é porque há um daemon atd rodando no sistema que recebe e executa os jobs at. Em um Mac, eles podem ser manipulados pelo daemon launchd , que é o daemon de substituição tudo-em-um da Apple:

The launchd daemon is essentially a replacement for init, rc, the init.d and rc.d scripts, SystemStarter (Mac OS X), inetd and xinetd, atd, crond and watchdogd. Apple has stated that it intends to eliminate all of the aforementioned services in favour of launchd