tesh - Online na nuvem

PROGRAMA:

NOME

tesh - shell de teste

SINOPSE

teste [OPÇÃO] ... [ARQUIVO] ...

DESCRIÇÃO

Esta é a ferramenta TESH. Constitui um shell de teste, ou seja, uma espécie de shell especializado para
executar testes. A lista de ações a serem tomadas é analisada a partir de arquivos de arquivos chamados de testsuite.

OPÇÕES

--cd algum diretório /: peça ao tesh para mudar o diretório de trabalho antes
lançando os testes
--setenv var = value: define uma variável de ambiente específica
--cfg arg: adiciona o parâmetro --cfg = arg a cada linha de comando
--enable-cobertura: ignora as linhas de saída começando com "profiling:"

TESH ARQUIVO SINTAXE

Esta é a sintaxe desses arquivos:

O tipo de cada linha é dado pelo primeiro caractere (o segundo caractere deve estar em branco e é
ignorado):

Comando `$ 'para rodar em primeiro plano
Comando `& 'para rodar em segundo plano
`<'entrada para passar para o comando
`> 'saída esperada do comando
`! ' metacommand, que pode ser um dos seguintes:
`tempo limite ' não
`esperar sinal '
`esperar retorno '
`saída '
`setenv = '
`p 'uma string para imprimir
`P 'uma string para imprimir no nível CRÍTICO (facilidade de registro de grepping)

Se a saída esperada não corresponder ao que o comando exibe, o TESH produzirá um erro
mostrando o diff (veja OUTPUT abaixo).

IO ORDENS

As linhas <e> adicionam IO ao comando definido no bloco atual (os blocos são separados
por linhas em branco). É possível colocar essas linhas depois do comando ou antes.
A diferença entre os dois blocos a seguir é principalmente cosmética em suas suítes de teste,
TESH não se importa. (cf IO-orders.tesh)

$ gato
<TOTO
> TOTO

> TOTO
$ gato
<TOTO

No entanto, é possível ter vários comandos no mesmo bloco, mas nenhum deles
pode ter qualquer saída. Pode parecer um pouco restritivo, como se poderia dizer que um comando obtém
todo o IO até o próximo comando, mas tenho medo de erros como o seguinte:

$ cd totó
> TOTO
arquivo $ mkfile

TOTO será passado para o comando cd, onde o usuário claramente deseja passá-lo para o
Comando integrado mkfile (veja abaixo).

STREAM REDIRECÇÃO

Os redirecionamentos de fluxo (construções ">", "<" e "|" em sh) ainda não foram implementados em tesh.
Isso é um pouco restritivo, mas bem, patch bem-vindo ...

A situação em que é mais problemático é a criação de um arquivo temporário. o
solução é usar o comando interno "mkfile", como no exemplo a seguir: $ mkfile
meuArquivo> algum conteúdo> para o arquivo

Isso criará um arquivo chamado myFile (primeiro argumento do comando mkfile). Seu conteúdo
será toda a entrada fornecida para o comando.

RETORNO CÓDIGO

TESH cospe uma mensagem de erro apropriada quando a criança não retorna 0 como código de retorno (cf.
catch-return.tesh) e retorna o próprio código + 40.

Também é possível especificar que um determinado comando deve retornar outro valor. Por esta,
use o metacommand "esperar retorno", que leva um inteiro como argumento. A mudança apenas
aplicar ao próximo comando (cf. set-return.tesh).

SINAIS

O TESH detecta quando a criança é morta por um sinal (como em segfaults) e cospe um
mensagem de erro apropriada (cf. catch-signal.tesh).

Também é possível especificar que um determinado comando deve disparar um determinado sinal. Por esta,
use o metacommand "esperar sinal". Leva o nome do sinal como argumento. A mudança apenas
aplicar ao próximo comando (cf. set-signal.tesh).

PRAZOS

Por padrão, todos os comandos têm 5 segundos para serem executados (cf. catch-timeout.tesh). Você pode
mude isso com o "tempo limite", que leva um número inteiro como argumento. A mudança só se aplica
para o próximo comando (cf. set-timeout.tesh). Se você passar "não" como argumento, o comando
não pode expirar.

SAÍDA

Por padrão, a saída dos comandos é comparada com a esperada e um erro é
gerado em discrepância. Metacommandos para mudar isso:
"output ignore" -> output completamente descartado
"display de saída" -> saída exibida (mas não verificada)
"output sort" -> classifica a exibição antes de verificá-la (veja abaixo)

ORDENAÇÃO SAÍDA

Classificar a saída parece ser uma ideia estranha, mas é obrigatório no SimGrid já que o
os processos ficam fora de ordem em qualquer ponto de agendamento (ou seja, todos os processos prontos para serem executados em
tempo simulado t executado em paralelo). Para garantir que as saídas do simulador ainda correspondam, nós
tem que classificar a saída de volta antes de compará-la.

Esperamos que os simuladores sejam executados com esse argumento de formatação de log:
--log = root.fmt: [% 10.6r]% e (% i:% P @% h)% e% m% n Então, tesh classifica a string nos 19 primeiros caracteres
apenas, e é estável quando o início da linha é igual. Isso deve garantir que:
(1) tesh é eficaz (nenhum falso positivo, nenhum falso negativo)
(2) os pontos de programação são separados uns dos outros
(3) em cada ponto de agendamento, os processos são separados uns dos outros
(4) a ordem do que um determinado processo diz em uma determinada programação
ponto é preservado.

É claro que isso é muito voltado para SimGrid, quebrando a generalidade do tesh, mas quem se importa,
na realidade?

Se você quiser alterar o comprimento do prefixo usado para a classificação, basta especificá-lo após
a diretiva de classificação de saída, como esta:

! tipo de saída 22

MEIO AMBIENTE

Você pode adicionar algum conteúdo ao ambiente de processos testados com o metacommand setenv.
Funciona como esperado. Por exemplo:
"setenv PATH =/ bin"

Use tesh online usando serviços onworks.net