Adenda à resposta de Martin Bøgelund:
A pergunta por quê (que eu suponho que é "por que a tentativa original fez o que fez") é interessante, e simples quando você pensa da maneira certa: é a mesma sintaxe dir [remote-directory] [local-file]
, onde o diretório remoto por acaso é >
. O cliente ftp não é um shell. Comandos digitados não são comandos shell. Ele não tem operadores de redirecionamento e >
não é um caractere especial.
Sim, você pode ter um diretório chamado >
em seu servidor FTP, contanto que você não o esteja executando no Windows.
O ftp.exe
encontrado no Windows é uma cópia de um ftp inicial do BSD. Não sabe sobre as restrições de nome de arquivo do Windows. Se você informar a get remotefile >
, ele tentará salvar uma cópia do arquivo remoto como um arquivo local chamado >
e falhará devido às limitações do sistema de arquivos local.
Um dos principais contribuintes para a confusão aqui é que o servidor FTP, recebendo um comando LIST
com >
como argumento, respondeu com um código de sucesso e um corpo de resposta vazio em vez de dizer "Nenhum tal arquivo". / p>