n>&p e n<&p são o mesmo operador e são para duplicar o descritor de arquivo (fd) p no descritor de arquivo n . Ou dito de outra forma, eles redirecionam o descritor de arquivo n para qualquer recurso para o qual o fd p é redirecionado.
Os < e > não são usados para determinar em qual direção (leitura ou gravação) o descritor de arquivo redirecionado será usado. n terá a mesma direção que p . Ou seja, se p estivesse aberto para gravação, também será n , mesmo se o operador n<&p for usado.
A única diferença entre os dois operadores é quando n não é especificado. >&p redireciona stdout (é como 1>&p ou 1<&p ) e <&p redireciona stdin (é como 0<&p ou 0>&p ).
Então, <&0 é como 0<&0 , então redireciona stdin para qualquer recurso para o qual stdin foi redirecionado, então não faz nada útil, é um não-operacional e não faz muito sentido.
>&0 duplica o fd 0 para o fd 1. Como o fd 1 (stdout) é, por convenção, usado apenas para escrita, esse >&0 só faz sentido se o fd 0 estiver aberto no modo de leitura + gravação. / p>
Esse seria o caso nos casos em que fd 0 aponta para o dispositivo terminal, porque emuladores de terminal ou getty geralmente abrem o dispositivo terminal no modo de leitura + gravação e atribuem fds 0, 1 e 2 a ele.
Então, quem quer que tenha escrito isso queria redirecionar o stdout para o terminal, assumindo que stdin estava apontando para ele.
O único local em que n>&n faz sentido é com zsh e seu recurso mult_IOs . Em zsh :
some-cmd >&1 > some-file
# that is: some-cmd 1>&1 1> some-file
Redireciona a saída padrão de some-cmd para qualquer uma das stdout anteriores (& 1) e some-file , como se você tivesse escrito:
some-cmd | tee some-file
Enquanto
some-cmd <&0 < some-file
# that is: some-cmd 0<&0 0< some-file
alimentaria primeiro o stdin original e, em seguida, some-file como entrada para some-cmd , como se você tivesse escrito:
cat - some-file | some-cmd
Mas em cmd <&0 >&0 , o fd 0 é redirecionado apenas uma vez, portanto isso não se aplica.