Caratteri jolly URI

Google Cloud CLI supporta l'utilizzo di caratteri jolly nell'URI per file, bucket e oggetti. I caratteri jolly consentono di lavorare in modo efficiente con gruppi di file che corrispondono a pattern di denominazione specificati. In questa pagina vengono descritti i caratteri jolly supportati e vengono note importanti considerazioni relative all'utilizzo di caratteri jolly nei comandi.

Caratteri jolly

gcloud CLI supporta i seguenti caratteri jolly:

Basato su caratteri	Descrizione
`*`	Trova la corrispondenza con zero o più caratteri nel livello della directory corrente. Ad esempio, `cp gs://my-bucket/abc/d` corrisponde all'oggetto `abc/def.txt` ma non all'oggetto `abc/def/g.txt`. Nel caso di elenchi di comandi come `ls`, se un `` finale corrisponde a una sottodirectory a livello di directory corrente, vengono elencati anche i contenuti di quest'ultima.
`**`	Trova la corrispondenza con zero o più caratteri oltre i limiti della directory. Se utilizzato come parte di un percorso file locale, il carattere jolly `` deve essere sempre preceduto immediatamente da un delimitatore di directory. Ad esempio, `my-directory/.txt` è valido, ma `my-directory/abc` non lo è. Nota: alcune shell dei comandi espandono le corrispondenze con caratteri jolly prima di eseguire il comando; tuttavia, la maggior parte delle shell non supporta i caratteri jolly ricorsivi (``). Puoi saltare l'espansione del carattere jolly della shell dei comandi e utilizzare invece il supporto del carattere jolly di gcloud CLI in queste shell con virgolette singole (su Linux) o doppie (su Windows). Ad esempio: `gcloud storage cp 'data/**' gs://bucket`
`?`	Abbina un singolo carattere. Ad esempio, `gs://bucket/??.txt` trova corrispondenze solo per gli oggetti con esattamente due caratteri seguiti da `.txt`.
`[CHARACTERS]`	Corrisponde a uno qualsiasi dei caratteri specificati. Ad esempio, `gs://bucket/[aeiou].txt` trova corrispondenze con gli oggetti che contengono un solo carattere vocale seguito da `.txt`.
`[CHARACTER_RANGE]`	Deve corrispondere a uno qualsiasi dell'intervallo di caratteri. Ad esempio, `gs://bucket/[a-e].txt` corrisponde agli oggetti che contengono le lettere a, b, c, d o e seguite da `.txt`.

Puoi combinare caratteri jolly per fornire corrispondenze più efficaci, ad esempio:

gs://*/[a-m]??.j*g

Tieni presente che, a meno che il tuo comando non includa un flag per restituire nei risultati versioni di oggetti non correnti, questi caratteri jolly corrispondono solo alle versioni degli oggetti live.

gcloud CLI supporta gli stessi caratteri jolly per i nomi degli oggetti e dei file. Ad esempio:

gcloud storage cp data/abc* gs://bucket

corrisponde a tutti i file che iniziano con abc nella directory data del file system locale.

Considerazioni sul comportamento

Esistono diversi casi in cui l'utilizzo dei caratteri jolly può generare comportamenti sorprendenti:

Quando utilizzi i caratteri jolly nei nomi dei bucket, le corrispondenze sono limitate ai bucket di un singolo progetto. Molti comandi consentono di specificare un progetto tramite un flag. Se un comando non include un flag di progetto o non supporta l'utilizzo di un flag di progetto, le corrispondenze sono limitate ai bucket nel progetto predefinito.
Le shell (come bash e zsh) possono tentare di espandere i caratteri jolly prima di passare gli argomenti a gcloud CLI. Se il carattere jolly doveva fare riferimento a un oggetto cloud, possono verificarsi errori sorprendenti di tipo "Non trovato". Ad esempio, la shell potrebbe provare a espandere il carattere jolly gs://my-bucket/* sulla macchina locale, cosa che non corrisponde a nessun file locale, causando la mancata riuscita del comando.

Inoltre, alcune shell includono altri caratteri nei loro set di caratteri jolly. Ad esempio, se utilizzi zsh con l'opzione externalglob abilitata, # viene considerato un carattere speciale, il che entra in conflitto con l'utilizzo di quel carattere nel fare riferimento a oggetti sottoposti al controllo delle versioni (per un esempio, consulta Ripristinare le versioni degli oggetti non correnti).

Per evitare questi problemi, racchiudi l'espressione con caratteri jolly tra virgolette singole (su Linux) o doppie (su Windows).
Il tentativo di specificare un nome file che contiene caratteri jolly non funziona, perché gli strumenti a riga di comando cercano di espandere i caratteri jolly anziché utilizzarli come caratteri letterali. Ad esempio, eseguendo il comando:
```
gcloud storage cp './file[1]' gs://my-bucket
```
non copia mai un file locale denominato file[1]. Invece, l'gcloud CLI considera sempre [1] come un carattere jolly.

gcloud CLI non supporta una modalità "raw" che consente di lavorare con nomi di file che contengono caratteri jolly. Per questi file, devi utilizzare uno strumento diverso, come la console Google Cloud, o un carattere jolly per acquisire i file. Ad esempio, per acquisire un file denominato file[1], puoi utilizzare il seguente comando:
```
gcloud storage cp './file*1*' gs://my-bucket
```
In base al comportamento Unix standard, il carattere jolly * trova corrispondenze solo per i file che non iniziano con un carattere . (per evitare confusione con le directory . e .. presenti in tutte le directory Unix). Gcloud CLI offre lo stesso comportamento quando utilizzi caratteri jolly su un URI di file system, ma non fornisce questo comportamento sugli URI cloud. Ad esempio, il seguente comando copia tutti gli oggetti da gs://bucket1 a gs://bucket2:
```
gcloud storage cp gs://bucket1/* gs://bucket2
```
Tuttavia, il seguente comando copia solo i file che non iniziano con . dalla directory dir a gs://bucket1:
```
gcloud storage cp dir/* gs://bucket1
```

Considerazioni sull'efficienza

Utilizzare i caratteri jolly con un prefisso di nome oggetto senza caratteri jolly è più efficiente, veloce e richiede meno traffico di rete, ad esempio:
```
gs://bucket/abc*.txt
```
utilizza i caratteri jolly come prima parte del nome dell'oggetto, ad esempio:
```
gs://bucket/*abc.txt
```
Il motivo è che la richiesta per gs://bucket/abc*.txt chiede al server di inviare nuovamente il sottoinsieme di risultati il cui nome oggetto inizia con abc nella radice del bucket, quindi filtra l'elenco dei risultati in base agli oggetti il cui nome termina con .txt. Al contrario, gs://bucket/*abc.txt chiede al server l'elenco completo degli oggetti nella directory radice del bucket, quindi filtra gli oggetti il cui nome termina con abc.txt. Questa considerazione dell'efficienza diventa sempre più evidente quando utilizzi bucket contenenti migliaia o più oggetti. A volte è possibile configurare i nomi degli oggetti in modo che corrispondano ai pattern di corrispondenza con caratteri jolly previsti per sfruttare l'efficienza delle richieste di prefisso lato server.
Supponi di avere un bucket con i seguenti oggetti:
```
gs://bucket/obj1
gs://bucket/obj2
gs://bucket/obj3
gs://bucket/obj4
gs://bucket/dir1/obj5
gs://bucket/dir2/obj6
```
Se esegui il comando:
```
gcloud storage ls gs://bucket/*/obj5
```
gcloud storage esegue un elenco di bucket di primo livello delimitato da /, quindi un elenco di bucket per ogni sottodirectory, per un totale di 3 schede di bucket:
```
GET /bucket/?delimiter=/
GET /bucket/?prefix=dir1/obj5&delimiter=/
GET /bucket/?prefix=dir2/obj5&delimiter=/
```
Più bucket elenca il tuo carattere jolly, più lento e più costoso diventa. Il numero di schede dei bucket richieste aumenta man mano che:
- il numero di componenti con caratteri jolly (ad es. gs://bucket/a??b/c*/*/d ha 3 componenti con caratteri jolly);
- il numero di sottodirectory corrispondenti a ogni componente; e
- il numero di risultati (la paginazione viene implementata quando il numero di risultati è troppo grande e specifica gli indicatori per ciascuno).
Se vuoi utilizzare un carattere jolly nel percorso intermedio, puoi provare a usare un carattere jolly ricorsivo, ad esempio:
```
gcloud storage ls gs://bucket/**/obj5
```
Questo corrisponde a più oggetti di gs://bucket/*/obj5 (poiché copre le directory), ma viene implementato utilizzando una richiesta di elenco dei bucket senza delimitatore (il che significa meno richieste di bucket, sebbene elenca l'intero bucket e filtri localmente, il che potrebbe richiedere una quantità non banale di traffico di rete).