Isso mesmo. >
trunca o arquivo antes que o comando seja iniciado, portanto, o comando vê um arquivo de entrada vazio. Na verdade, não importa que os redirecionamentos sejam executados da esquerda para a direita (exceto que você obterá um erro se o arquivo não existir, enquanto >file <file
criaria o arquivo primeiro).
Com somecommand <file >>file
, na maior parte do tempo, você obterá um loop infinito quando o comando ler sua própria entrada. No entanto, para um arquivo curto, é possível que o comando detecte o final da entrada antes de gravar qualquer coisa, nesse caso, isso se comportará como se a entrada e a saída fossem arquivos separados.
Com somecommand <file 1<>file
, é mais complicado. Dependendo se o comando expande ou encolhe o arquivo, ele pode ou não fazer um loop em sua própria entrada. Se o comando sempre encolher o arquivo (por exemplo, grep
sem coisas como numeração de linha ou coloração), ou seja, se o byte N da saída sempre depender apenas dos bytes 0..N-1 da entrada, então isso se comportará como se os dois os arquivos eram diferentes. Eu não recomendo confiar nisso: é frágil de várias maneiras e deixa uma bagunça se o comando for interrompido no meio.