Google Cloud CLI permet d'utiliser des caractères génériques d'URI pour les fichiers, les buckets et les objets. Les caractères génériques vous permettent de travailler efficacement avec des groupes de fichiers correspondant à des modèles de dénomination spécifiés. Cette page décrit les caractères génériques compatibles et indique les points importants à prendre en compte lors de leur utilisation dans les commandes.
Caractères génériques
gcloud CLI est compatible avec les caractères génériques suivants :
Caractère | Description |
---|---|
* |
Correspond à zéro caractère ou plus au niveau du répertoire actuel. Par exemple, cp gs://my-bucket/abc/d* correspond à l'objet abc/def.txt , mais pas à l'objet abc/def/g.txt . Dans le cas des commandes de liste telles que ls , si un * final correspond à un sous-répertoire du niveau actuel du répertoire, le contenu du sous-répertoire est également listé. |
** |
Correspond à zéro caractère ou plus dans les limites de répertoires. Lorsqu'il est utilisé dans le cadre d'un chemin d'accès au fichier local, le caractère générique ** doit toujours être précédé d'un délimiteur de répertoire. Par exemple, my-directory/**.txt est valide, mais my-directory/abc** ne l'est pas. |
? |
Correspond à un seul caractère. Par exemple, gs://bucket/??.txt ne recherche que les objets avec exactement deux caractères suivis de .txt . |
[CHARACTERS] |
Correspond à l'un des caractères spécifiés. Par exemple, gs://bucket/[aeiou].txt recherche des objets contenant une seule voyelle suivie de .txt . |
[CHARACTER_RANGE] |
Correspond à n'importe quel caractère de la plage. Par exemple, gs://bucket/[a-e].txt recherche des objets contenant la lettre a, b, c, d ou e suivie de .txt . |
Vous pouvez combiner des caractères génériques pour obtenir des correspondances plus efficaces, par exemple :
gs://*/[a-m]??.j*g
Sachez que si votre commande n'inclut pas d'option permettant de renvoyer des versions d'objet archivées dans les résultats, ces caractères génériques ne correspondent qu'aux versions d'objets actives.
gcloud CLI est compatible avec les mêmes caractères génériques pour les noms d'objets et de fichiers. Par exemple :
gcloud storage cp data/abc* gs://bucket
correspond à tous les fichiers commençant par abc
dans le répertoire data
du système de fichiers local.
Considérations liées au comportement
L'utilisation de caractères génériques peut entraîner divers comportements inattendus :
Lorsque vous utilisez des caractères génériques dans les noms de buckets, les correspondances sont limitées aux buckets d'un même projet. De nombreuses commandes vous permettent de spécifier un projet à l'aide d'une option. Si une commande n'inclut pas d'option de projet ou ne prend pas en charge son utilisation, les correspondances sont limitées aux buckets du projet par défaut.
Les shells (tels que bash et zsh) peuvent tenter de développer les caractères génériques avant de transmettre les arguments à gcloud CLI. Si le caractère générique est censé faire référence à un objet cloud, cela peut entraîner des erreurs "Introuvable" inattendues. Par exemple, le shell peut essayer de développer le caractère générique
gs://my-bucket/*
sur la machine locale, qui ne correspond à aucun fichier local, entraînant ainsi l'échec de la commande.En outre, certains shells contiennent d'autres caractères dans leurs jeux de caractères génériques. Par exemple, si vous utilisez zsh avec l'option extendedglob,
#
est traité comme un caractère spécial qui entre en conflit avec son utilisation dans le référencement d'objets avec des versions gérées (voir Restaurer les versions d'objet obsolètes pour obtenir un exemple).Pour éviter ces problèmes, placez l'expression entre des guillemets simples (sous Linux) ou guillemets doubles (sous Windows).
Vous ne pouvez pas spécifier un nom de fichier contenant des caractères génériques, car les outils de ligne de commande tentent de développer les caractères génériques plutôt que de les utiliser en tant que caractères littéraux. Par exemple, en exécutant la commande :
gcloud storage cp './file[1]' gs://my-bucket
La commande ne copie jamais les fichiers locaux nommés
file[1]
. Au lieu de cela, gcloud CLI traite toujours[1]
comme un caractère générique.La gcloud CLI ne prend pas en charge le mode "brut" qui lui permet d'utiliser des noms de fichiers contenant des caractères génériques. Pour ces fichiers, vous devez utiliser un outil différent tel que la console Google Cloud ou utiliser un caractère générique pour capturer les fichiers. Par exemple, pour capturer un fichier nommé
file[1]
, vous pouvez utiliser la commande suivante :gcloud storage cp './file*1*' gs://my-bucket
Conformément au comportement Unix standard, le caractère générique
*
ne correspond qu'aux fichiers qui ne commencent pas par un caractère.
(pour éviter toute confusion avec les répertoires.
et..
présents dans tous les répertoires Unix. gcloud CLI applique le même comportement lorsque vous utilisez des caractères génériques sur un URI de système de fichiers, mais pas sur des URI cloud. Par exemple, la commande suivante copie tous les objets depuisgs://bucket1
versgs://bucket2
:gcloud storage cp gs://bucket1/* gs://bucket2
Toutefois, la commande suivante ne copie que les fichiers qui ne commencent pas par
.
du répertoiredir
versgs://bucket1
:gcloud storage cp dir/* gs://bucket1
Considérations liées à l'efficacité
L'utilisation de caractères génériques comportant un préfixe de nom d'objet sans caractère générique est plus efficace, plus rapide et moins consommatrice de trafic réseau, par exemple :
gs://bucket/abc*.txt
que l'utilisation de caractères génériques comme première partie du nom d'objet. Exemple :
gs://bucket/*abc.txt
En effet, la requête pour
gs://bucket/abc*.txt
demande au serveur de renvoyer le sous-ensemble de résultats dont le nom d'objet commence parabc
à la racine du bucket, puis elle filtre la liste des résultats pour les objets dont le nom se termine par.txt
. En revanche,gs://bucket/*abc.txt
demande au serveur la liste complète des objets à la racine du bucket, puis filtre les objets dont le nom se termine parabc.txt
. Ce facteur d'efficacité est encore plus visible lorsque vous utilisez des buckets contenant des milliers d'objets ou plus. Il est parfois possible de configurer les noms de vos objets pour qu'ils correspondent aux modèles de correspondance de caractères génériques attendus, afin de profiter de l'efficacité des requêtes de préfixe côté serveur.Supposons que vous disposiez d'un bucket avec les objets suivants :
gs://bucket/obj1 gs://bucket/obj2 gs://bucket/obj3 gs://bucket/obj4 gs://bucket/dir1/obj5 gs://bucket/dir2/obj6
Si vous exécutez la commande ci-dessous :
gcloud storage ls gs://bucket/*/obj5
gcloud storage
renvoie une liste des buckets de premier niveau délimités par/
puis une liste de buckets pour chaque sous-répertoire, soit un total de trois listes de buckets :GET /bucket/?delimiter=/ GET /bucket/?prefix=dir1/obj5&delimiter=/ GET /bucket/?prefix=dir2/obj5&delimiter=/
Plus le bucket contient de nombreuses listes de caractères génériques, plus l'opération est lente et onéreuse. Le nombre de listes de buckets requises augmente avec :
le nombre de composants génériques (par exemple,
gs://bucket/a??b/c*/*/d
comporte trois composants génériques) ;le nombre de sous-répertoires correspondant à chaque composant ; et
le nombre de résultats (la pagination est effectuée lorsque le nombre de résultats est trop élevé, en spécifiant des marqueurs pour chaque requête).
Si vous souhaitez utiliser un caractère générique au milieu d'un chemin d'accès, essayez plutôt d'utiliser un caractère générique récursif, par exemple :
gcloud storage ls gs://bucket/**/obj5
Cela correspond à plus d'objets que
gs://bucket/*/obj5
(puisqu'il couvre plusieurs répertoires) mais est mis en œuvre à l'aide d'une requête de liste de buckets sans délimiteur (ce qui réduit le nombre de requêtes de bucket, bien que l'ensemble du bucket soit répertorié et filtré localement, ce qui peut nécessiter une quantité non négligeable de trafic réseau).