Google Cloud CLI admite el uso de comodines de URI para archivos, buckets y objetos. Los comodines te permiten trabajar de manera eficiente con grupos de archivos que coinciden con patrones de denominación especificados. En esta página, se describen los comodines compatibles y se mencionan consideraciones importantes cuando se usan comodines en los comandos.
Caracteres comodín
gcloud CLI admite los siguientes comodines:
Carácter | Descripción |
---|---|
* |
Coincide con cero o más caracteres dentro del nivel del directorio actual. Por ejemplo, cp gs://my-bucket/abc/d* coincide con el objeto abc/def.txt , pero no con el objeto abc/def/g.txt . En el caso de enumerar comandos como ls , si un * al final coincide con un subdirectorio en el nivel del directorio actual, el contenido del subdirectorio también se enumera. |
** |
Coincide con cero o más caracteres en los límites del directorio. Cuando se usa como parte de la ruta de acceso de un archivo local, el comodín ** siempre debe ir precedido de inmediato por un delimitador de directorio. Por ejemplo, my-directory/**.txt es válido, pero my-directory/abc** no lo es. |
? |
Coincide con un solo carácter. Por ejemplo, gs://bucket/??.txt solo coincide con objetos con dos caracteres seguidos de .txt . |
[CHARACTERS] |
Coincide con cualquiera de los caracteres especificados. Por ejemplo, gs://bucket/[aeiou].txt coincide con los objetos que contienen un solo carácter de vocal seguido de .txt . |
[CHARACTER_RANGE] |
Coincide con cualquiera de los rangos de caracteres. Por ejemplo, gs://bucket/[a-e].txt coincide con los objetos que contienen la letra a, b, c, d o e seguida de .txt . |
Puedes combinar comodines para proporcionar coincidencias más eficaces, por ejemplo:
gs://*/[a-m]??.j*g
Ten en cuenta que, a menos que tu comando incluya una marca para mostrar versiones de objetos no actuales en los resultados, estos comodines solo coinciden con las versiones de objetos activas.
gcloud CLI admite los mismos comodines para nombres de objetos y archivos. Por ejemplo:
gcloud storage cp data/abc* gs://bucket
coincide con todos los archivos que comienzan con abc
en el directorio data
del sistema de archivos local.
Consideraciones de comportamiento
Existen varios casos en los que el uso de comodines puede dar como resultado comportamientos inesperados:
Cuando se usan comodines en los nombres de los buckets, las coincidencias se limitan a los buckets en un solo proyecto. Muchos comandos te permiten especificar un proyecto mediante una marca. Si en un comando no se incluye una marca del proyecto o no se admite el uso de una marca del proyecto, las coincidencias se limitan a los buckets en el proyecto predeterminado.
Las shells (como bash y zsh) pueden intentar expandir los comodines antes de pasar los argumentos a gcloud CLI. Si el comodín se refería a un objeto en la nube, esto puede generar errores inesperados de “No se encontró”. Por ejemplo, la shell podría intentar expandir el comodín
gs://my-bucket/*
en la máquina local, lo que no coincidiría con ningún archivo local, lo que provocaría que el comando falle.Además, algunas shells incluyen otros caracteres en sus grupos de caracteres comodín. Por ejemplo, si usas zsh con la opción extendedglob habilitada, se tratará a
#
como un carácter especial, lo que entra en conflicto con el uso de ese carácter para hacer referencia a los objetos con versión (consulta Restaura las versiones de objetos no actuales para obtener un ejemplo).Para evitar estos problemas, encierra la expresión de comodín con comillas simples (en Linux) o comillas dobles (en Windows).
Intentar especificar un nombre de archivo que contenga caracteres comodín no funcionará, ya que las herramientas de línea de comandos intentan expandir los caracteres comodín en lugar de usarlos como caracteres literales. Por ejemplo:
gcloud storage cp './file[1]' gs://my-bucket
nunca copia un archivo local llamado
file[1]
. En cambio, gcloud CLI siempre trata a[1]
como un comodín.gcloud CLI no admite un modo “sin procesar” que le permita trabajar con nombres de archivos que contienen caracteres comodín. Para esos archivos, debes usar una herramienta diferente, como la consola de Google Cloud, o usar un comodín a fin de capturar los archivos. Por ejemplo, para capturar un archivo llamado
file[1]
, puedes usar el comando siguiente:gcloud storage cp './file*1*' gs://my-bucket
Por comportamiento estándar de Unix, el comodín
*
solo coincide con los archivos que no comienzan con un carácter.
(para evitar confusiones con los directorios.
y..
presentes en todos los directorios de Unix). gcloud CLI proporciona este mismo comportamiento cuando se usan comodines en un URI del sistema de archivos, pero no proporciona este comportamiento en URI de la nube. Por ejemplo, el siguiente comando copia todos los objetos degs://bucket1
ags://bucket2
:gcloud storage cp gs://bucket1/* gs://bucket2
Sin embargo, el siguiente comando solo copia los archivos que no comienzan con un
.
del directoriodir
ags://bucket1
:gcloud storage cp dir/* gs://bucket1
Consideraciones sobre la eficiencia
Es más eficiente, más rápido y requiere menos tráfico de red usar comodines que tengan un prefijo de nombre de objeto sin comodín, como los siguientes:
gs://bucket/abc*.txt
Esto se contrapone a usar comodines como la primera parte del nombre del objeto, por ejemplo:
gs://bucket/*abc.txt
Esto se debe a que la solicitud de
gs://bucket/abc*.txt
le pide al servidor que vuelva a enviar el subconjunto de resultados cuyo nombre de objeto comienza conabc
en la raíz del bucket y, luego, filtra la lista de resultados para objetos cuyos nombres terminan con.txt
. Por el contrario,gs://bucket/*abc.txt
solicita al servidor la lista completa de objetos en la raíz del bucket y, luego, filtra los objetos cuyos nombres terminan enabc.txt
. Esta consideración de eficiencia se vuelve cada vez más evidente cuando usas buckets que contienen miles de objetos o más. A veces, es posible configurar los nombres de los objetos para que se ajusten a los patrones de coincidencia de comodines esperados, a fin de aprovechar la eficiencia de realizar solicitudes de prefijos del servidor.Supongamos que tienes un bucket con estos objetos:
gs://bucket/obj1 gs://bucket/obj2 gs://bucket/obj3 gs://bucket/obj4 gs://bucket/dir1/obj5 gs://bucket/dir2/obj6
Si ejecutas el comando a continuación, ocurrirá lo siguiente:
gcloud storage ls gs://bucket/*/obj5
gcloud storage
genera una lista de buckets de nivel superior delimitada por/
y, luego, una lista de buckets para cada subdirectorio, lo que da como resultado un total de 3 listas de buckets:GET /bucket/?delimiter=/ GET /bucket/?prefix=dir1/obj5&delimiter=/ GET /bucket/?prefix=dir2/obj5&delimiter=/
Cuantas más listas de buckets requiera tu comodín, más lento y costoso será. La cantidad de listas de depósitos necesarias aumenta según lo siguiente:
La cantidad de componentes del comodín (p. ej.,
gs://bucket/a??b/c*/*/d
tiene 3 componentes comodín);La cantidad de subdirectorios que coinciden con cada componente
La cantidad de resultados (la paginación se implementa cuando la cantidad de resultados es demasiado grande y se especifican los marcadores para cada uno).
Si deseas usar un comodín de mitad de ruta de acceso, puedes intentar usar un comodín recurrente, por ejemplo:
gcloud storage ls gs://bucket/**/obj5
Esto coincidirá con más objetos que
gs://bucket/*/obj5
(ya que abarca directorios), pero se implementa mediante una solicitud de lista de buckets sin delimitador (lo que significa una menor cantidad de solicitudes de buckets, a pesar de que enumera todo el bucket y se filtra de forma local, por lo que podría requerir una cantidad no trivial de tráfico de red).