O que :>filename.txt está fazendo?

Como você descobriu, isso apenas esvazia o conteúdo do arquivo (trunca o arquivo); que é diferente de rmcomo rmremoveria o arquivo completamente. Além disso, :>file.txtrealmente criará o arquivo se ele ainda não existir.

:é um "comando não fazer nada" que sairá com sucesso e não produzirá saída, portanto, é simplesmente um método curto para esvaziar um arquivo. Na maioria dos shells, você pode simplesmente fazer >file.txtpara obter o mesmo resultado. Também pode ser um pouco mais rápido do que outros métodos, como echo >file.txtpotencialmente echoum comando externo.

Além disso, echo >file.txtcolocaria uma linha em branco file.txtonde :>file.txtfaria com que o arquivo não tivesse conteúdo algum.

Sim, é diferente de rm.

rmremoveria o arquivo.

:>filename.txtesvazia o arquivo, deixando-o ainda lá, mas com zero bytes de tamanho.

A invocação de shell >filename.txtredireciona alguma saída para o arquivo "filename.txt" para substituí-lo completamente. Portanto, o shell precisa limpar todo o conteúdo do arquivo fornecido antes de gravar a saída nele.

A saída a ser redirecionada é a saída do comando executado. Curti:

$ echo Hello >filename.txt

Fará com que o arquivo de nome filename.txt contenha exatamente (e somente) a string Hello.

Executando:

$ echo "New Value" >filename.txt
$ cat filename.txt
New Value

apagará tudo dentro do arquivo e depois gravará New Valuenele.

Se o comando não tiver saída, como o comando true, o arquivo permanecerá vazio (truncado).

$ true >filename.txt
$ cat filename.txt

Um comando que também é um shell embutido é :(apenas um ponto duplo (dois pontos)) e que não tem saída. Ser um builtin torna mais rápido do que um comando externo como true(que também não tem saída). Então, ou:

$ :  >  filename.txt
$ :  >filename.txt
$ :>filename.txt

removerá todo o conteúdo do arquivo nomeado filename.txtou o criará como um arquivo vazio se não existir.

Isso é diferente de um rm?

Isso é diferente de um rm, pois um rm fará o arquivo desaparecer de ls, não fará com que o arquivo contenha 0 bytes.

Ele opera mais rápido ou mais lento do que outros meios semelhantes de zerar um arquivo ou excluí-lo?

Novamente, o arquivo não está sendo deletado (desaparece da lista dada por ls) ele se transforma em um arquivo vazio (contém 0 bytes).

Deve ser mais rápido do que chamar um comando externo para esvaziar um arquivo. Ter que criar um shell filho para carregar o executável e execo comando torna os comandos externos mais lentos que o interno :.

Soluções semelhantes são (algumas definidas $?como 1):

[ ]         > filename.txt
builtin     > filename.txt
command     > filename.txt
printf ''   > filename.txt

re: desempenho: isso é o mais eficiente possível no shell; apenas pedir ao kernel para truncar um arquivo existente deve ser mais eficiente do que desvincular o arquivo e recriar um novo inode com o mesmo nome. A menos que você queira que o arquivo seja excluído, nesse caso rmou unlinkele.

:é um shell embutido, portanto, evita fork/exec. Assim é o equivalente trueem conchas modernas normais.

>fooou true > foofaz com que o shell trunque o arquivo fazendo uma
open(path, O_WRONLY|O_TRUNC|O_CREAT, 0666)chamada de sistema.

Ou na prática com DASH no Linux, a partir da strace shsaída:
openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 que é equivalente.

Então tem close()que voltar a esse FD. Na verdade, o DASH não é um caso especial quando você usa :>, ele salta pelos seguintes aros:

openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fcntl(1, F_GETFD)                       = 0
fcntl(1, F_DUPFD, 10)                   = 10          # save original stdout
fcntl(1, F_GETFD)                       = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
dup2(3, 1)                              = 1           # redirect stdout to foo
close(3)                                = 0           # then close 3
dup2(10, 1)                             = 1           # then restore original stdout
fcntl(10, F_GETFD)                      = 0x1 (flags FD_CLOEXEC)
close(10)                               = 0

O uso > foono DASH leva à mesma sequência de chamadas do sistema, redirecionando o fd1 e restaurando-o. Eu não verifiquei bashou outras conchas.

Mas isso ainda é significativamente mais barato do que criar um novo processo para executar truncate -s 0 fooque (espero) faria uma única truncate("foo", 0)chamada de sistema que presumivelmente seria ainda mais eficiente que um open+ close.

De uma linguagem como C (ou qualquer coisa com ligações de chamada do sistema), truncar um arquivo que você não deseja abrir pode ser feito de maneira mais eficiente com uma truncatesyscall direta.

No Dash, 3>fooleva a esta sequência de chamadas do sistema:

openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
close(3)                                = 0

Abrir um novo fd resulta em já ser fd 3, evitando qualquer duping. Esta é a maneira mais eficiente no dash, provavelmente economizando vários microssegundos vs. >foo. Se isso importa, shell script é a linguagem errada para sua tarefa!! Mas você perguntou.

Com a mitigação Spectre+Meltdown habilitada, mesmo uma -ENOSYSchamada de sistema ruim leva pelo menos milhares de ciclos de clock, ou seja, microssegundos, no moderno Intel x86-64. Acima de algumas centenas para a viagem de ida e volta usuário->kernel->usuário com apenas uma syscallinstrução. É claro que as pesquisas de caminho e assim por diante levam um tempo significativo, assim como o código do sistema de arquivos. E ir para o modo kernel e voltar muitas vezes despeja algum cache, tornando o espaço do usuário mais lento no retorno.

O custo real de E/S uma vez que os metadados fazem write-back no disco depende do sistema de arquivos. Um FS como XFS ou ext4 moderno usando apenas 1 ou algumas extensões grandes para o arquivo inteiro pode liberar facilmente grandes quantidades de espaço em tempo O(1). Ou O(n) onde né o número de extensões (fragmentação) e não o tamanho em bytes.

Dependendo do FS, se as informações de extensão foram armazenadas diretamente no inode, em vez de um bloco indireto, isso é uma coisa a menos para adicionar à lista gratuita.

O custo de E/S é semelhante a desvincular o arquivo, mas você não precisa liberar o inode ou modificar a entrada do diretório. Você ainda precisa atualizar o mtime e o ctime no inode após o truncamento, mas você teve que escrevê-lo de qualquer maneira se o tamanho mudasse.