Ls sempre listará os arquivos que a rm removerá?

Algo que sinto que devo ter certeza: se remover ls <something>, rm <something>removerei exatamente os mesmos arquivos lsexibidos? Existe alguma circunstância em que você rmpossa remover arquivos que lsnão foram exibidos? (Isso é no bash 18.04)

Edit: obrigado a todos que responderam. Penso que a resposta completa é uma combinação de todas as respostas, pelo que aceitei a resposta mais votada como "a resposta".

Coisas inesperadas que aprendi ao longo do caminho:

• ls não é tão simples quanto você imagina ao lidar com seus argumentos
• Em uma instalação simples e sem complicações do Ubuntu, aliases .bashrc ls
• Não nomeie seus arquivos começando com um hífen, pois podem parecer argumentos de comando, e nomear um -r é pedir!

Bem, ambos lse rmoperam com os argumentos que lhes são passados.

Estes argumentos podem ser um arquivo simples, tão ls file.exte rm file.extoperar o mesmo arquivo e o resultado é claro (lista o arquivo / excluir o arquivo).

Se, ao invés argumento é um diretório, ls directorylista o conteúdo do diretório enquanto rm directorynão funcionará como está (ou seja, rmsem bandeiras não pode remover diretórios, enquanto que se você fizer rm -r directory, ele recursivamente apaga todos os arquivos sob directory eo próprio diretório ).

Mas lembre-se de que os argumentos da linha de comando podem estar sujeitos à expansão do shell , portanto, nem sempre é garantido que os mesmos argumentos sejam transmitidos aos dois comandos se eles contiverem caracteres curinga, variáveis, saída de outros comandos etc.

Como exemplo extremo, pense ls $(rand).txte rm $(rand).txt, os argumentos são "os mesmos", mas os resultados são bem diferentes!

Se você estiver pensando em algo como ls foo*.txtvs. rm foo*.txt, sim, eles mostrarão e removerão os mesmos arquivos. O shell expande a glob e a passa para o comando em questão, e os comandos funcionam nos arquivos listados. Um listando-os, um removendo-os.

A diferença óbvia é que, se algum desses arquivos fosse um diretório, lsele listaria seu conteúdo, mas rmfalharia em removê-lo. Isso geralmente não é um problema, pois rmremoveria menos do que o mostrado por ls.

O grande problema aqui vem da execução ls *ou rm *em um diretório que contém nomes de arquivos começando com um traço . Eles iriam se expandir para as linhas dos dois programas de comando como se você escreveu-los você mesmo, e lslevaria -rpara significar "ordem de classificação inversa", enquanto que rmlevaria -ra significar uma remoção recursiva. A diferença importa se você tiver subdiretórios com pelo menos dois níveis de profundidade. ( ls *mostrará o conteúdo dos diretórios de primeiro nível, mas também rm -r *passará tudo além do primeiro subnível.)

Para evitar isso, escreva globs permissivos com uma ./indicação para indicar o diretório atual e / ou coloque a --para sinalizar o final do processamento da opção antes da glob (ie rm ./*ou rm -- *).

Com um glob como *.txt, na verdade, isso não é um problema, pois o ponto é um caractere de opção inválido e causará um erro (até que alguém expanda os utilitários para inventar um significado para ele), mas ainda é mais seguro colocar o ./local de qualquer maneira.

É claro que você também pode obter resultados diferentes para os dois comandos se alterar as opções de brilho do shell ou criar / mover / remover arquivos entre os comandos, mas duvido que você tenha se referido a algum desses casos. (Lidar com arquivos novos / movidos seria extremamente complicado de fazer com segurança.)

Deixando de lado o comportamento do shell, vamos nos concentrar apenas no que rme lspodemos lidar com eles mesmos. Pelo menos um caso em lsque o que rmnão pode ser removido envolve permissões de diretório e o outro - diretórios especiais .e ...

Permissões de pasta

rmé uma operação em um diretório, porque, ao remover um arquivo, você altera o conteúdo do diretório (ou, em outras palavras, a lista de entradas do diretório, pois o diretório não é mais do que uma lista de nomes de arquivos e inodes ). Isso significa que você precisa de permissões de gravação em um diretório. Mesmo se você for o proprietário do arquivo , sem permissões de diretório, você não poderá remover os arquivos. O inverso também é verdadeiro : rmpode remover arquivos que pertencem a outras pessoas, se você for o proprietário do diretório.

Portanto, você pode muito bem ter permissões de leitura e execução em um diretório, o que permitirá que você percorra o diretório e visualize o conteúdo muito bem, por exemplo ls /bin/echo, mas você não pode, a rm /bin/echomenos que seja o proprietário /bin ou aumente seus privilégios sudo.

E você verá casos como esse em todos os lugares. Aqui está um desses casos: https://superuser.com/a/331124/418028

Diretórios especiais '.' e '..'

Outro caso especial é .e ..diretórios. Se você faz ls .ou ls .., felizmente irá mostrar-lhe o conteúdo, mas rm'ing-los não é permitido:

$ rm -rf .
rm: refusing to remove '.' or '..' directory: skipping '.'

Se você digitar ls *e rm *, em seguida , é possível remover mais arquivos do que o lsmostrado - eles podem ter sido criados no pequeno intervalo de tempo entre o final lse o início de rm.

ls *e rm *não somos responsáveis ​​por expandir a glob - isso é feito pelo shell antes de passá-lo ao comando.

Isso significa que você pode usar qualquer comando com a lista de arquivos expandida - então eu usaria algo que faça o mínimo possível.

Portanto, uma maneira melhor de fazer isso (ou pelo menos de outra maneira) é pular o intermediário.

echo *mostrará exatamente o que seria passado ao seu rmcomando.

E se:

$ mkdir what
$ cd what
$ mkdir -p huh/uhm ./-r
$ ls *
uhm
$ rm *
$ ls
-r
$ ls -R
.:
-r

./-r:

Basicamente, os curingas que se expandem para itens iniciados por -(ou itens inseridos manualmente, iniciados com -mas que se parecem um pouco com trapaça) podem ser interpretados de forma diferente por lse rm.

Não são casos extremos onde o que lsmostra não é o que rmremove. Um argumento bastante extremo, mas felizmente benigno, é se o argumento que você passa é um link simbólico para um diretório: lsmostrará todos os arquivos no diretório com link simbólico, enquanto rmremoverá o link simbólico, deixando o diretório original e seu conteúdo intocado:

% ln -s $HOME some_link
% ls some_link    # Will display directory contents  
bin    lib    Desktop ...
% rm some_link
% ls $HOME
bin    lib    Desktop ...

Se você fizer isso apenas em lsvez de ls -a, sim, rmpoderá remover os arquivos ocultos que você não viu lssem -a.

Exemplo:

De acordo com :

dir_test
├── .test
└── test2

ls dir_test : exibirá apenas test2

ls -A dir_test : exibirá test2 + .test

rm -r dir_test : removerá tudo (.test + test2)

Espero que isso ajude você.

Já existem muitas respostas boas, mas quero acrescentar uma visão mais profunda.

Faça a si mesmo a pergunta: Quantos parâmetros são passados ​​para ls, se você escrever

ls *

...? Observe que o lscomando não obtém o *parâmetro as se houver algum arquivo que *possa ser expandido. Em vez disso, o shell primeiro executa um globbing antes de chamar o comando, de modo que o lscomando realmente obtém tantos parâmetros quanto os arquivos correspondentes ao globbing. Para suprimir globbing, cite o parâmetro

Isto é verdade para qualquer comando: echo *vs echo '*'.

Existe um script, chame-o countparams.shpara testar o efeito. Ele informa quantos parâmetros foram passados ​​e os lista.

#!/bin/bash
echo "This script was given $# parameters."
arr=( "$@" )
for ((i=0;i<$#;i++)); do
        echo "Parameter $((i+1)): ${arr[$i]}"
done

Torne executável e execute ./countparams.sh *. Aprenda com sua saída!

A glob se expandirá da mesma maneira nas duas vezes, se o conteúdo do diretório for o mesmo nesses dois momentos diferentes.

Se você realmente deseja verificar o que será removido, use rm -i *.txt. Ele solicitará separadamente cada arquivo antes (tentando) removê-lo.

Isso garante segurança contra as condições de corrida:
        ls *.txt/ um novo arquivo é criado / rm *.txt
porque você é solicitado a cada arquivo pelo mesmo programa que está fazendo a remoção.

Este é demasiado pesado para o uso normal, e se você apelido rmpara rm -i, você vai encontrar-se usando \rmou rm -fcom bastante frequência. Mas vale a pena mencionar pelo menos que existe uma solução para a condição de corrida. (É até portátil para sistemas não-GNU: POSIX rm(1)especifica a -iopção .)

Outra opção seria uma matriz bash:, to_remove=(*.txt)então peça ao usuário para confirmar (talvez depois de fazer ls -ld -- "${to_remove[@]}"), então rm -- "${to_remove[@]}". Portanto, a expansão glob é feita apenas uma vez e a lista é passada literalmente para rm.

Outra opção praticamente utilizável é o GNU rm -I( página de manual ), que solicita a remoção de mais de 4 itens. (Mas não mostra a lista, apenas o total.) Uso alias rm='rm -I'na minha área de trabalho.

É uma boa salvaguarda contra o retorno dos dedos gordos com um padrão meio digitado que combina demais. Mas usar lsprimeiro é geralmente bom em um diretório que você possui, ou em um sistema de usuário único, e quando não há processos em segundo plano que poderiam criar novos arquivos de forma assíncrona. Para se proteger contra dedilhado gordo, não digite rm -rf /foo/bar/bazda esquerda para a direita. rm -rf /é especial, mas rm -rf /usrnão é! Deixe de fora a -rfpeça ou comece com ela lse adicione-a somente rm -rfdepois de digitar o caminho.