¿Ls siempre listará los archivos que rm eliminará?

Algo que creo que debo saber con certeza: si lo hago ls <something>, ¿ rm <something>eliminaré exactamente los mismos archivos que se lsmuestran? ¿Hay alguna circunstancia en la que rmpueda eliminar archivos que lsno se muestran? (Esto es en la fiesta 18.04)

Editar: gracias a todos los que respondieron. Creo que la respuesta completa es una combinación de todas las respuestas, por lo que he aceptado la respuesta más votada como "la respuesta".

Cosas inesperadas que he aprendido en el camino:

• ls no es tan sencillo como podría pensar en el manejo de sus argumentos
• En una instalación simple y sin complicaciones de Ubuntu, los alias .bashrc ls
• ¡No asigne un nombre a sus archivos que comiencen con un guión, ya que pueden parecer argumentos de comando, y nombrar a uno -r lo solicita!

Bueno, ambos lsy rmoperar sobre los argumentos que se les pasan.

Estos argumentos pueden ser un simple archivo, de modo ls file.exty rm file.extoperan en el mismo archivo y el resultado es claro (lista el archivo / borrar el archivo).

Si por el contrario el argumento es un directorio, ls directoryse enumeran los contenidos del directorio, mientras que rm directoryno va a funcionar como está (es decir, rmsin banderas no pueden eliminar directorios, mientras que si lo hace rm -r directory, de forma recursiva borra todos los archivos bajo directory y el propio directorio ).

Pero tenga en cuenta que los argumentos de la línea de comandos pueden estar sujetos a la expansión del shell , por lo que no siempre se garantiza que se pasen los mismos argumentos a ambos comandos si contienen comodines, variables, salida de otros comandos, etc.

Como ejemplo extremo, piense ls $(rand).txty rm $(rand).txt, los argumentos son "iguales" pero los resultados son bastante diferentes.

Si está pensando en algo como ls foo*.txtvs. rm foo*.txt, entonces sí, mostrarán y eliminarán los mismos archivos. El shell expande el globo y lo pasa al comando en cuestión, y los comandos funcionan en los archivos enumerados. Uno los enumera, uno los elimina.

La diferencia obvia es que si alguno de esos archivos fuera un directorio, lsenumeraría su contenido, pero rmno lo eliminaría. Eso generalmente no es un problema, ya rmque eliminaría menos de lo que se mostró ls.

El gran problema aquí proviene de ejecutar ls *o rm *en un directorio que contiene nombres de archivos que comienzan con un guión . Ellos se expandirían a las líneas de comandos de los dos programas como si las escribió por su cuenta, y lsllevarían -ra significar "orden inverso", mientras que rmllevaría -ra significar una eliminación recursiva. La diferencia es importante si tiene subdirectorios de al menos dos niveles de profundidad. ( ls *mostrará el contenido de los directorios de primer nivel, pero rm -r *también todo pasará el primer subnivel).

Para evitar eso, escriba globos permisivos con un signo ./que indique el directorio actual, y / o ponga un --para indicar el final del procesamiento de opciones antes del globo (es decir, rm ./*o rm -- *).

Con un glob como *.txt, en realidad no es un problema ya que el punto es un carácter de opción no válido y causará un error (hasta que alguien expanda las utilidades para inventar un significado para él), pero de todos modos es más seguro ponerlo ./allí.

Por supuesto, también podría obtener resultados diferentes para los dos comandos si cambia las opciones de bloqueo del shell, o crea / mueve / elimina archivos entre los comandos, pero dudo que haya querido decir alguno de esos casos. (Tratar con archivos nuevos / movidos sería extremadamente complicado de hacer de forma segura).

Dejando a un lado el comportamiento de shell, centrémonos solo en qué rmy lspodemos lidiar con ellos mismos. Al menos un caso donde lsse mostrará lo rmque no se puede eliminar involucra permisos de directorio, y el otro - directorios especiales .y ...

Permisos de carpeta

rmes una operación en un directorio, porque al eliminar un archivo, está cambiando el contenido del directorio (o, en otras palabras, una lista de entradas de directorio, ya que el directorio no es más que una lista de nombres de archivo e inodos ). Esto significa que necesita permisos de escritura en un directorio. Incluso si es el propietario del archivo , sin permisos de directorio no puede eliminar archivos. Lo contrario también es cierto : rmpuede eliminar archivos que pueden ser propiedad de otros, si usted es el propietario del directorio.

Por lo tanto, es muy posible que tenga permisos de lectura y ejecución en un directorio, lo que le permitirá atravesar el directorio y ver los contenidos muy bien, por ejemplo ls /bin/echo, pero no puede hacerlo a rm /bin/echomenos que sea el propietario /bin o eleve sus privilegios sudo.

Y verá casos como este en todas partes. Aquí hay uno de estos casos: https://superuser.com/a/331124/418028

Directorios especiales '.' y '..'

Otro caso especial es .y ..directorios. Si lo hace ls .o ls .., felizmente le mostrará el contenido, pero rmno está permitido:

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

Si escribe ls *y luego rm *, es posible que elimine más archivos de los lsmostrados; podrían haberse creado en el pequeño intervalo de tiempo entre el final lsy el inicio de rm.

ls *y rm *no son responsables de expandir el glob - eso lo hace el shell antes de pasarlo al comando.

Esto significa que puede usar cualquier comando con la lista de archivos expandida, por lo que usaría algo que haga lo menos posible.

Entonces, una mejor manera de hacer esto (o al menos, otra forma) es saltarse al intermediario.

echo *le mostrará exactamente lo que se pasaría a su rmcomando.

Qué tal si:

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

./-r:

Básicamente, los comodines que se expanden a cosas que comienzan con -(o cosas ingresadas manualmente que comienzan con -pero que se parece un poco más a una trampa) pueden interpretarse de manera diferente por lsy rm.

No son casos extremos donde lo que lsmuestra que no es lo rmelimina. Uno bastante extremo, pero afortunadamente benigno, es si el argumento que pasa es un enlace simbólico a un directorio: lsle mostrará todos los archivos en el directorio de enlaces simbólicos, mientras rmque eliminará el enlace simbólico, dejando intacto el directorio original y su contenido:

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

Si lo hace solamente lsen lugar de ls -a, sí rmse pueden eliminar los archivos ocultos que no han visto con lsy sin -a.

Ejemplo:

De acuerdo a :

dir_test
├── .test
└── test2

ls dir_test : solo mostrará test2

ls -A dir_test : mostrará test2 + .test

rm -r dir_test : eliminará todo (.test + test2)

Espero que eso te ayude.

Ya hay muchas buenas respuestas, pero quiero agregar una visión más profunda.

Hágase la pregunta: ¿A cuántos parámetros se pasan lssi escribe?

ls *

...? Tenga en cuenta que el lscomando no obtiene el *parámetro como si hay archivos a los que *se pueda expandir. En cambio, el shell primero realiza el bloqueo antes de invocar el comando, por lo que el lscomando realmente obtiene tantos parámetros como archivos que coinciden con el bloqueo. Para suprimir el globbing, cite el parámetro.

Esto es cierto para cualquier comando: echo *vs echo '*'.

Hay un script, llámalo countparams.shpara probar el efecto. Le indica cuántos parámetros pasó y los enumera.

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

Hazlo ejecutable y ejecútalo ./countparams.sh *. ¡Aprende de su salida!

El globo se expandirá de la misma manera las dos veces, si el contenido del directorio es el mismo en esos dos momentos diferentes.

Si realmente desea verificar qué se eliminará, úselo rm -i *.txt. Le indicará por separado para cada archivo antes de (intentar) eliminarlo.

Se garantiza que esto es seguro contra las condiciones de la carrera:
        ls *.txt/ se crea un nuevo archivo / rm *.txt
porque el mismo programa que realiza la eliminación le solicita cada archivo.

Esto es demasiado engorroso para un uso normal, y si alias rma rm -i, usted se encontrará usando \rmo rm -fcon bastante frecuencia. Pero vale la pena mencionar al menos que hay una solución para la condición de la carrera. (Incluso es portátil para sistemas que no son GNU: POSIX rm(1)especifica la -iopción ).

Otra opción sería una matriz bash:, to_remove=(*.txt)luego pídale al usuario que confirme (tal vez después de hacerlo ls -ld -- "${to_remove[@]}"), luego rm -- "${to_remove[@]}". Por lo tanto, la expansión global solo se realiza una vez, y la lista se pasa literalmente a rm.

Otra opción prácticamente utilizable es GNU rm -I( página de manual ), que indica si se eliminan más de 4 elementos. (Pero no muestra la lista, solo el total). Lo uso alias rm='rm -I'en mi escritorio.

Es una buena protección contra el regreso de los dedos gordos con un patrón medio tipado que coincide demasiado. Pero usar lsprimero es generalmente bueno en un directorio de su propiedad, o en un sistema de usuario único, y cuando no hay procesos en segundo plano que puedan crear asincrónicamente nuevos archivos allí. Para protegerse contra los dedos gordos, no escriba rm -rf /foo/bar/bazde izquierda a derecha. rm -rf /es especial, pero rm -rf /usrno lo es! Omita la -rfparte, o comience con ls, y solo agregue la rm -rfparte después de escribir la ruta.