Error de lista de argumentos demasiado larga para los comandos rm, cp, mv


629

Tengo varios cientos de archivos PDF en un directorio en UNIX. Los nombres de los archivos PDF son realmente largos (aprox. 60 caracteres).

Cuando intento eliminar todos los archivos PDF juntos usando el siguiente comando:

rm -f *.pdf

Obtuve el siguiente error:

/bin/rm: cannot execute [Argument list too long]

¿Cuál es la solución a este error? ¿Ocurre este error para mvy cpcomandos también? En caso afirmativo, ¿cómo resolver estos comandos?


21
Es posible que encuentre útil este enlace
another.anon.coward


1
También esto puede ser relevante http://mywiki.wooledge.org/BashFAQ/095
Lorenzo Belli

44
@jww: Y seguí pensando durante tantos años que bash cae en "herramientas de software comúnmente utilizadas por los programadores", ¡una categoría cuyas preguntas se pueden hacer aquí!
Vicky

@Nik - Agregar "... en un script" no es convincente. Cuando el problema se reduce a un ejemplo Mínimo, Completo y Verificable , es solo una pregunta sobre cómo ejecutar un comando. Mis disculpas si me falta algo obvio.
jww

Respuestas:


876

La razón por la que esto ocurre es porque bash en realidad expande el asterisco a cada archivo coincidente, produciendo una línea de comando muy larga.

Prueba esto:

find . -name "*.pdf" -print0 | xargs -0 rm

Advertencia: esta es una búsqueda recursiva y también encontrará (y eliminará) archivos en subdirectorios. Agregue el -fcomando rm solo si está seguro de que no desea confirmación.

Puede hacer lo siguiente para que el comando no sea recursivo:

find . -maxdepth 1 -name "*.pdf" -print0 | xargs -0 rm

Otra opción es usar la -deletebandera de find :

find . -name "*.pdf" -delete

77
No, xargsdivide específicamente la lista y emite varios comandos si es necesario.
tripleee

77
@Dennis: -maxdepth 1debe ser el primer argumento después del camino.
Barton Chittenden

54
Find tiene una -deletebandera para eliminar los archivos que encuentra, e incluso si no fuera así, se consideraría una mejor práctica usar -execpara ejecutar rm, en lugar de invocar xargs (que ahora son 3 procesos y una tubería en lugar de un solo proceso con -deleteo 2 procesos con -exec).
scragar

3
@ ÉdouardLopez ... Pero esto está leyendo una entrada delimitada por NULL. Y en general dangerous (broken, exploitable, etc.), es bastante ridículo. Sin duda, debe tener cuidado al usarlo xargs, pero no lo es del todo eval/evil.
Restablecer Monica Please

44
@scragar Con la -execllamada rm, el número de procesos será 1 + número de archivos, aunque el número de procesos concurrentes a partir de esto puede ser 2 (quizás find ejecutaría procesos rm simultáneamente). El número de procesos xargsque se usarían se reduciría drásticamente a 2 + n, donde n es un número de procesos menor que el número de archivos (digamos número de archivos / 10, aunque probablemente más dependiendo de la longitud de las rutas). Suponiendo que find realiza la eliminación directamente, usar -deletedebería ser el único proceso que se invocaría.
neuralmer

397

tl; dr

Es una limitación del núcleo en el tamaño del argumento de la línea de comando. Use un forbucle en su lugar.

Origen del problema

Este es un problema del sistema, relacionado execvey ARG_MAXconstante. Hay mucha documentación al respecto (ver man execve , debian's wiki ).

Básicamente, la expansión produce un comando (con sus parámetros) que excede el ARG_MAXlímite. En kernel 2.6.23, el límite se estableció en 128 kB. Esta constante se ha incrementado y puede obtener su valor ejecutando:

getconf ARG_MAX
# 2097152 # on 3.5.0-40-generic

Solución: Usando forLoop

Use un forbucle como se recomienda en BashFAQ / 095 y no hay límite, excepto para RAM / espacio de memoria:

La ejecución en seco para determinarlo eliminará lo que espera:

for f in *.pdf; do echo rm "$f"; done

Y ejecutarlo:

for f in *.pdf; do rm "$f"; done

Además, este es un enfoque portátil, ya que Glob tiene un comportamiento fuerte y consistente entre los depósitos ( parte de la especificación POSIX ).

Nota: Como se ha señalado en varios comentarios, esto es más lento pero más fácil de mantener, ya que puede adaptar escenarios más complejos, por ejemplo , donde uno quiere hacer más de una sola acción.

Solución: usar find

Si insiste, puede usar findpero realmente no usar xargs ya que "es peligroso (roto, explotable, etc.) al leer entradas no delimitadas por NUL" :

find . -maxdepth 1 -name '*.pdf' -delete 

Usar en -maxdepth 1 ... -deletelugar de -exec rm {} +permite findsimplemente ejecutar las llamadas del sistema requeridas sin usar un proceso externo, por lo tanto, más rápido (gracias al comentario de @chepner ).

Referencias


31
Gran respuesta, así es como todas las preguntas SO deben ser respondidas. ¡Gracias!
Tommed

1
+1 por mencionar el forbucle. Lo he usado findantes, pero siempre estoy buscando cómo hacerlo, ya que olvido las opciones, etc. todo el tiempo. forparece más fácil de recordar en mi humilde opinión
Robert Dundon

3
for f in *; do rm "$f"; done
Lo usé

3
La find -execsolución parece ser MUCHO más rápida que el forciclo.
tres

2
Cinco años más tarde a las 4.15.0 ( 4.15.0-1019-gcppara ser exactos) y el límite todavía está en 2097152. Curiosamente, la búsqueda de ARG_MAX en el repositorio de Linux git da un resultado que muestra que ARG_MAX está en 131702.
Matt M.

181

findtiene una -deleteacción:

find . -maxdepth 1 -name '*.pdf' -delete

44
Esto todavía devolvería "Lista de argumentos demasiado larga". Al menos para mí lo hace. El uso xargs, según la respuesta de Dennis, funciona según lo previsto.
Sergio

77
Eso suena como un error en encontrar.
ThiefMaster

3
@ Sergio tuvo el mismo problema, fue causado por las comillas faltantes alrededor del patrón de nombre.
Luxian

argh, ¿por qué una herramienta para encontrar cosas tiene incluso un interruptor para eliminar? ¿Soy realmente yo quien considera innecesario decir lo menos y también peligroso?
mathreadler

2
@mathreadler Aborda el hecho de que un caso de uso común -execes eliminar un montón de archivos. -exec rm {} +haría lo mismo, pero aún requiere iniciar al menos un proceso externo. -deletepermite findejecutar simplemente el sistema requerido se llama a sí mismo sin usar un contenedor externo.
chepner

21

Otra respuesta es forzar xargs procesamiento de los comandos en lotes. Por ejemplo a deletelos archivos 100a la vez, cden el directorio y ejecute esto:

echo *.pdf | xargs -n 100 rm


44
Para eliminar el comando en Linux, que puede ser un desastre si eres ingeniero y escribiste un error, creo que es el "más seguro y sé lo que está pasando" es el mejor. No es algo sofisticado que si no escribe un punto, su empresa se colapsará en un minuto.
Inteligencia artificial

1
¿Cómo podemos hacer que esta sea la expansión predeterminada para ciertos comandos? Hay muchos comandos linux "estándar" en los que se sabe si los necesitan todos a la vez o no (como "rm")
user1212212

1
Tenga en cuenta que esto solo funciona donde echohay un shell incorporado. Si termina usando el comando echo, aún se encontrará con el límite de argumentos del programa.
Toby Speight

14

O puedes probar:

find . -name '*.pdf' -exec rm -f {} \;

Esto elimina archivos de subdirectorios también. ¿Cómo prevenir eso?
Vicky

@NikunjChauhan Agregue la opción -maxdepth:find . -maxdepth 1 -name '*.pdf' -exec rm -f {} \;
Jon Lin

No puedo insertar la opción maxdepth
Vicky

Esa opción puede ser una opción solo para Linux, según la respuesta de @ Dennis, arriba (la respuesta seleccionada).
jvriesem

12

Si está tratando de eliminar una gran cantidad de archivos a la vez (eliminé un directorio con más de 485,000 hoy), probablemente se encontrará con este error:

/bin/rm: Argument list too long.

El problema es que cuando escribes algo como rm -rf *, el* se reemplaza con una lista de todos los archivos coincidentes, como "rm -rf file1 file2 file3 file4" y así sucesivamente. Hay un búfer de memoria relativamente pequeño asignado para almacenar esta lista de argumentos y si se llena, el shell no ejecutará el programa.

Para solucionar este problema, mucha gente usará el comando find para encontrar cada archivo y pasarlos uno por uno al comando "rm" de esta manera:

find . -type f -exec rm -v {} \;

Mi problema es que necesitaba eliminar 500,000 archivos y estaba tardando demasiado.

Me topé con una forma mucho más rápida de eliminar archivos: el comando "buscar" tiene un indicador "-delete" incorporado. Esto es lo que terminé usando:

find . -type f -delete

Usando este método, estaba eliminando archivos a una velocidad de aproximadamente 2000 archivos / segundo, ¡mucho más rápido!

También puede mostrar los nombres de los archivos a medida que los elimina:

find . -type f -print -delete

... o incluso mostrar cuántos archivos se eliminarán, y luego el tiempo que lleva eliminarlos:

root@devel# ls -1 | wc -l && time find . -type f -delete
100000
real    0m3.660s
user    0m0.036s
sys     0m0.552s

Gracias. Hice sudo find . -type f -deleteeliminar alrededor de 485 mil archivos y funcionó para mí. Tomó unos 20 segundos.
Nigel Alderton

11

puedes probar esto:

for f in *.pdf
do
  rm $f
done

EDITAR: el comentario de ThiefMaster me sugiere que no revele esa práctica peligrosa a los jedis de shell jóvenes, así que agregaré una versión más "más segura" (en aras de preservar las cosas cuando alguien tiene un archivo "-rf. ..Pdf")

echo "# Whooooo" > /tmp/dummy.sh
for f in '*.pdf'
do
   echo "rm -i $f" >> /tmp/dummy.sh
done

Después de ejecutar lo anterior, simplemente abra el archivo /tmp/dummy.sh en su favorito. editor y verifique en cada línea los nombres de archivos peligrosos, coméntelos si los encuentra.

Luego copie el script dummy.sh en su directorio de trabajo y ejecútelo.

Todo esto por razones de seguridad.


55
Creo que esto haría cosas realmente agradables con un archivo llamado por ejemplo-rf .. .pdf
ThiefMaster

sí, pero generalmente cuando se usa en shell, el emisor del comando "debería" echar un vistazo a lo que está haciendo :). En realidad, prefiero redirigir a un archivo y luego inspeccionar cada fila.
BigMike

2
Esto no cita "$ f". De eso estaba hablando ThiefMaster. -rftiene prioridad sobre -i, por lo que su segunda versión no es mejor (sin inspección manual). Y es básicamente inútil para la eliminación masiva, debido a la solicitud de cada archivo.
Peter Cordes

7

Podrías usar una matriz bash:

files=(*.pdf)
for((I=0;I<${#files[@]};I+=1000)); do
    rm -f "${files[@]:I:1000}"
done

De esta forma, se borrará en lotes de 1000 archivos por paso.


2
Para una gran cantidad de archivos, esto parece significativamente más rápido
James Tocknell,


4

El rm comando tiene una limitación de archivos que puede eliminar simultáneamente.

Una posibilidad es que pueda eliminarlos utilizando varias veces las bases del comando rm en sus patrones de archivo, como:

rm -f A*.pdf
rm -f B*.pdf
rm -f C*.pdf
...
rm -f *.pdf

También puede eliminarlos mediante el comando de búsqueda :

find . -name "*.pdf" -exec rm {} \;

3
No, rmno tiene dicho límite en la cantidad de archivos que procesará (aparte de eso argc, no puede ser mayor que INT_MAX). Es la limitación del núcleo en el tamaño máximo de toda la matriz de argumentos (es por eso que la longitud de los nombres de archivo es significativa).
Toby Speight

3

Si son nombres de archivo con espacios o caracteres especiales, use:

find -maxdepth 1 -name '*.pdf' -exec rm "{}" \;

Esta oración busca todos los archivos en el directorio actual (-maxdepth 1) con la extensión pdf (-name '* .pdf') y luego elimina cada uno (-exec rm "{}").

La expresión {} reemplaza el nombre del archivo y "{}" establece el nombre del archivo como cadena, incluidos espacios o caracteres especiales.


Si bien este fragmento de código puede resolver la pregunta, incluir una explicación de cómo y por qué esto resuelve el problema realmente ayudaría a mejorar la calidad de su publicación. Recuerde que está respondiendo la pregunta para los lectores en el futuro, ¡no solo la persona que pregunta ahora! Por favor, editar su respuesta para agregar explicación y dar una indicación de lo que se aplican limitaciones y supuestos.
Toby Speight

El punto -execes que no invocas un shell. Las citas aquí no hacen absolutamente nada útil. (Evitan cualquier expansión de comodines y la división de señal en la cadena en la concha donde se escribe este comando, pero la cadena {}no contiene ningún espacio en blanco o concha caracteres comodín.)
tripleee

2

Estaba enfrentando el mismo problema al copiar el directorio de origen del formulario al destino

el directorio fuente tenía archivos ~ 3 lakcs

i utilizado cp con la opción -r y ha funcionado para mí

cp -r abc / def /

copiará todos los archivos de abc a def sin avisar demasiado de la lista de argumentos


No sé por qué alguien rechazó esto, sin siquiera comentarlo (¡esa es la política, amigos!). Necesitaba eliminar todos los archivos dentro de una carpeta (la pregunta no es particular sobre los PDF, eso sí), y para eso, este truco está funcionando bien, todo lo que hay que hacer al final es recrear la carpeta que se eliminó cuando Usé `rm -R / ruta / a / carpeta".
Thomas Tempelmann

1
Funciona porque en el caso de OP, estaba usando *, que se expandió a una gran lista de .pdf, dando un directorio hará que esto sea tratado internamente, por lo tanto, no tendrá que lidiar con el problema de OP. Creo que fue rechazado por esa razón. Podría no ser utilizable para OP si tiene un directorio anidado u otros archivos (no pdf) en su directorio
Alvein

2

Pruebe esto también. Si desea eliminar archivos / carpetas superiores a 30/90 días (+) o inferiores a 30/90 (-) días, puede usar los siguientes comandos ex

Por ejemplo: para 90 días excluye lo anterior después de 90 días elimina archivos / carpetas, significa 91,92 .... 100 días

find <path> -type f -mtime +90 -exec rm -rf {} \;

Por ejemplo: para los últimos archivos de 30 días que desea eliminar, utilice el siguiente comando (-)

find <path> -type f -mtime -30 -exec rm -rf {} \;

Si quieres usar los archivos durante más de 2 días

find <path> -type f -mtime +2 -exec gzip {} \;

Si desea ver los archivos / carpetas solo del último mes. Ex:

find <path> -type f -mtime -30 -exec ls -lrt {} \;

Por encima de 30 días más, solo enumere los archivos / carpetas Ej:

find <path> -type f -mtime +30 -exec ls -lrt {} \;

find /opt/app/logs -type f -mtime +30 -exec ls -lrt {} \;

2

Me sorprende que no haya ulimitrespuestas aquí. Cada vez que tengo este problema termino aquí o aquí . Entiendo que esta solución tiene limitaciones, pero ulimit -s 65536parece que a menudo me sirve.


1

Tuve el mismo problema con una carpeta llena de imágenes temporales que crecía día a día y este comando me ayudó a borrar la carpeta

find . -name "*.png" -mtime +50 -exec rm {} \;

La diferencia con los otros comandos es el parámetro mtime que tomará solo los archivos anteriores a X días (en el ejemplo 50 días)

Utilizando eso varias veces, disminuyendo en cada ejecución el rango de días, pude eliminar todos los archivos innecesarios


1

Solo sé una forma de evitar esto. La idea es exportar esa lista de archivos pdf que tiene a un archivo. Luego divide ese archivo en varias partes. Luego, elimine los archivos pdf enumerados en cada parte.

ls | grep .pdf > list.txt
wc -l list.txt

wc -l es contar cuántas líneas contiene la lista.txt. Cuando tenga la idea de cuánto tiempo es, puede decidir dividirlo por la mitad, hacia adelante o algo así. Uso del comando split -l Por ejemplo, divídalo en 600 líneas cada uno.

split -l 600 list.txt

esto creará algunos archivos llamados xaa, xab, xac, etc., dependiendo de cómo lo divida. Ahora para "importar" cada lista de esos archivos en el comando rm, use esto:

rm $(<xaa)
rm $(<xab)
rm $(<xac)

Perdón por mi mal ingles.


55
Si tiene un archivo llamado, pdf_format_sucks.docxeste también se eliminará ... ;-) Debe usar una expresión regular adecuada y precisa al buscar los archivos pdf.
FooF

1
Mejor, pero still_pdf_format_sucks.docxserá eliminado. El punto .en ".pdf"la expresión regular coincide con cualquier carácter. Sugeriría en "[.]pdf$"lugar de .pdf.
FooF

1

Me encontré con este problema varias veces. Muchas de las soluciones ejecutarán el rmcomando para cada archivo individual que deba eliminarse. Esto es muy ineficiente:

find . -name "*.pdf" -print0 | xargs -0 rm -rf

Terminé escribiendo un script de Python para eliminar los archivos basados ​​en los primeros 4 caracteres del nombre del archivo:

import os
filedir = '/tmp/' #The directory you wish to run rm on 
filelist = (os.listdir(filedir)) #gets listing of all files in the specified dir
newlist = [] #Makes a blank list named newlist
for i in filelist: 
    if str((i)[:4]) not in newlist: #This makes sure that the elements are unique for newlist
        newlist.append((i)[:4]) #This takes only the first 4 charcters of the folder/filename and appends it to newlist
for i in newlist:
    if 'tmp' in i:  #If statment to look for tmp in the filename/dirname
        print ('Running command rm -rf '+str(filedir)+str(i)+'* : File Count: '+str(len(os.listdir(filedir)))) #Prints the command to be run and a total file count
        os.system('rm -rf '+str(filedir)+str(i)+'*') #Actual shell command
print ('DONE')

Esto funcionó muy bien para mí. Pude borrar más de 2 millones de archivos temporales en una carpeta en aproximadamente 15 minutos. Comenté el alquitrán del pequeño código para que cualquier persona con un conocimiento mínimo o nulo de Python pueda manipular este código.


1

Y otro:

cd  /path/to/pdf
printf "%s\0" *.[Pp][Dd][Ff] | xargs -0 rm

printfes un shell incorporado, y que yo sepa, siempre ha sido así. Ahora dado que printfno es un comando de shell (sino un incorporado), no está sujeto a "argument list too long ... " error fatal.

Por lo tanto, podemos usarlo de forma segura con patrones de globo de shell como *.[Pp][Dd][Ff], luego, canalizamos su salida para eliminar el rmcomando ( ), a través xargs, lo que asegura que se ajusta a suficientes nombres de archivo en la línea de comando para no fallar elrm comando, que es un shell mando.

El \0en printfsirve como un separador nulo para los nombres de archivo wich son luego procesadas por xargscomando, utilizando ( -0) como separador, por lo que rmno falla cuando hay espacios en blanco u otros caracteres especiales en los nombres de archivo.


1
Si bien este fragmento de código puede resolver la pregunta, incluir una explicación de cómo y por qué esto resuelve el problema realmente ayudaría a mejorar la calidad de su publicación. Recuerde que está respondiendo la pregunta para los lectores en el futuro, ¡no solo la persona que pregunta ahora! Por favor, editar su respuesta para agregar explicación y dar una indicación de lo que se aplican limitaciones y supuestos.
Toby Speight

En particular, si printfno se trata de un shell incorporado, estará sujeto a la misma limitación.
Toby Speight

0

Puede crear una carpeta temporal, mover todos los archivos y subcarpetas que desea mantener a la carpeta temporal, luego eliminar la carpeta anterior y cambiar el nombre de la carpeta temporal a la carpeta anterior. Pruebe este ejemplo hasta que esté seguro de hacerlo en vivo:

mkdir testit
cd testit
mkdir big_folder tmp_folder
touch big_folder/file1.pdf
touch big_folder/file2.pdf
mv big_folder/file1,pdf tmp_folder/
rm -r big_folder
mv tmp_folder big_folder

El rm -r big_foldereliminará todos los archivos en el big_folderno importa cuántos. Solo tienes que tener mucho cuidado, primero tienes todos los archivos / carpetas que deseas mantener, en este caso fuefile1.pdf


0

Para borrar todo *.pdfen un directorio/path/to/dir_with_pdf_files/

mkdir empty_dir        # Create temp empty dir

rsync -avh --delete --include '*.pdf' empty_dir/ /path/to/dir_with_pdf_files/

Eliminar archivos específicos mediante el rsyncuso de comodines es probablemente la solución más rápida en caso de que tenga millones de archivos. Y se encargará del error que esté recibiendo.


(Paso opcional): EJECUTAR EN SECO. Para verificar lo que se eliminará sin eliminar. ``

rsync -avhn --delete --include '*.pdf' empty_dir/ /path/to/dir_with_pdf_files/

. . .

Haz clic en consejos y trucos de rsync para obtener más trucos de rsync


0

Descubrí que para listas extremadamente grandes de archivos (> 1e6), estas respuestas eran demasiado lentas. Aquí hay una solución que usa procesamiento paralelo en python. Lo sé, lo sé, esto no es Linux ... pero nada más aquí funcionó.

(Esto me ahorró horas)

# delete files
import os as os
import glob
import multiprocessing as mp

directory = r'your/directory'
os.chdir(directory)


files_names = [i for i in glob.glob('*.{}'.format('pdf'))]

# report errors from pool

def callback_error(result):
    print('error', result)

# delete file using system command
def delete_files(file_name):
     os.system('rm -rf ' + file_name)

pool = mp.Pool(12)  
# or use pool = mp.Pool(mp.cpu_count())


if __name__ == '__main__':
    for file_name in files_names:
        print(file_name)
        pool.apply_async(delete_files,[file_name], error_callback=callback_error)

0

Me he enfrentado a un problema similar cuando había millones de archivos de registro inútiles creados por una aplicación que llenaba todos los inodos. Recurrí a "localizar", puse todos los archivos "ubicados" en un archivo de texto y luego los eliminé uno por uno. Tomó un tiempo pero hizo el trabajo!


Esto es bastante vago y requiere que lo haya instalado de locatenuevo cuando aún tenía espacio en su disco.
tripleee

-2

Una versión un poco más segura que usar xargs, también no recursiva: ls -p | grep -v '/$' | grep '\.pdf$' | while read file; do rm "$file"; done

Filtrar nuestros directorios aquí es un poco innecesario ya que 'rm' no lo eliminará de todos modos, y se puede eliminar por simplicidad, pero ¿por qué ejecutar algo que definitivamente devolverá un error?


3
Esto no es seguro en absoluto, y no funciona con nombres de archivo con nuevas líneas en ellos, para señalar un caso de esquina obvio. El análisisls es un antipatrón común que definitivamente debe evitarse, y agrega una serie de errores adicionales aquí. El grep | grepsimplemente no es muy elegante.
tripleee

De todos modos, no es que este sea un problema nuevo y exótico que requiere una solución compleja. Las respuestas con findson buenas y bien documentadas aquí y en otros lugares. Consulte, por ejemplo, mywiki.wooledge.org para obtener más información sobre este tema y otros relacionados.
tripleee

-2

Usar GNU parallel ( sudo apt install parallel) es súper fácil

Ejecuta los comandos multiproceso donde '{}' es el argumento pasado

P.ej

ls /tmp/myfiles* | parallel 'rm {}'


No lo sé, pero supongo que es porque pasar la salida lsdirectamente a otros comandos es un antipatrón peligroso; eso, y el hecho de que la expansión del comodín causará el mismo error al ejecutar lscomo se experimentó en el rmcomando original .
Toby Speight

Para el contexto sobre eso, vea ParsingLs . Y parallelhace que algunas personas que prefieren evitar la complejidad se sientan incómodas: si miras debajo del capó, es bastante opaco. Vea el hilo de la lista de correo en lists.gnu.org/archive/html/bug-parallel/2015-05/msg00005.html entre Stephane (uno de los galgos de Unix y Linux StackExchange ) y Ole Tange (autor de Parallel). xargs -Ptambién se paraleliza, pero lo hace de una manera más simple y tonta con menos partes móviles, lo que hace que su comportamiento sea mucho más fácil de predecir y razonar.
Charles Duffy

-2

Para eliminar los primeros 100 archivos:

rm -rf 'ls | cabeza -100 '


2
Peligroso (o lo sería si usara comillas inversas como evidentemente se pretendía): si cualquier nombre de archivo contiene metacaracteres de shell, incluidos espacios, los resultados no serán lo que pretendía.
Toby Speight

-5

La siguiente opción parece simple para este problema. Obtuve esta información de otro hilo pero me ayudó.

for file in /usr/op/data/Software/temp/application/openpages-storage/*; do
    cp "$file" /opt/sw/op-storage/
done

Simplemente ejecute el comando anterior y hará la tarea.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.