Diferença entre 'call perl script.pl' vs 'call script.pl' no Windows

Question

Nos servidores Windows (testei 2008 R2 e 2012 R2), notamos um comportamento diferente na execução de scripts Perl que são chamados de lote.

Considere um arquivo em lote primitivo da seguinte forma:

:beginlbl
call path\script.pl
goto :beginlbl

Mais cedo ou mais tarde (às vezes depois de apenas algumas execuções de script em outras ocasiões após centenas de execuções), haverá uma mensagem de erro: "O Windows não pode acessar o dispositivo, caminho ou arquivo especificado. Você pode não ter as permissões apropriadas para acessar o item."

Se a segunda linha do código for modificada para aparecer da seguinte forma:

call perl path\script.pl

(Observe o nome do executável antes do script). O script será executado sem problemas.

O que o Windows está executando de maneira diferente nos dois casos descritos acima?

    

Answer 1

O uso da associação de arquivos passa por um processo shell para avaliar o tipo de arquivo (extensão) e iniciar o processo apropriado. Você provavelmente está sobrecarregando isso. Isso é semelhante a como você obtém seu editor registrado ao invocar um .txt. Veja também ShellExecute.

Invocar diretamente o executável corta o intermediário e sempre seria o preferido.

O comentário de Uslackr sobre sua pergunta original também está correto, e ele observa que o executável perl no caminho do sistema é invocado. É melhor especificar diretamente o executável que você deseja executar por um caminho completo para evitar que outro executável seja invocado acidentalmente. Isso é bom tanto para confiabilidade quanto segurança. A portabilidade é sacrificada, mas você pode escolher suas prioridades.

    

Answer 2

Eu marquei a resposta de Mateus tão correta quanto compartilho seu sentimento de como se deve implementá-la. Na realidade, herdamos sistemas que suportamos e, na melhor das hipóteses, a solução não é a que temos. Mudar / melhorar é outra história.

Hoje sabemos que nosso problema foi causado pelo mau sensor Crowdstrike. Basicamente, este spyware está causando estragos no Windows. O que é triste é que a) não há nenhum traço no log de eventos do Windows b) não há nenhum vestígio da interferência no console do próprio Crowdstrike.

Infelizmente, o fornecedor quer que resolvamos seus problemas de software e meus chefes não me pagam para fazer isso.