assegnare e ispezionare i metadati della funzione bash


10

Genero spesso e registro molte funzioni bash che automatizzano molte delle attività che di solito svolgo nei miei progetti di sviluppo. Quella generazione dipende dai metadati del progetto a cui sto lavorando.

Voglio annotare le funzioni con le informazioni del progetto che sono state generate, in questo modo:

func1() {
# This function was generated for project: PROJECT1
echo "do my automation"
}

Idealmente, sarei in grado di vedere il commento quando ispeziono la definizione:

$ type func1

func1 is a function
func1 () 
{
    # This function was generated for project: PROJECT1
    echo "do my automation"
}

Ma in qualche modo bash sembra ignorare i commenti al momento del caricamento della funzione, non durante l'esecuzione. Quindi i commenti vengono persi e ottengo questo risultato:

func1 is a function
func1 () 
{
    echo "do my automation"
}

Esiste un modo per assegnare metadati alle funzioni e controllarli in seguito? È possibile recuperarlo durante l'ispezione della definizione con il tipo?


1
Non una soluzione (da qui il commento), ma la soluzione che utilizzo è di verificare se lo $1è -h, quindi printf/ echoun aiuto / utilizzo / qualunque riga.
John N,

Risposte:


13
function func_name()
{
  : '
  Invocation:   func_name $1 $2 ... $n
  Function:     Display the values of the supplied arguments, in double quotes.
  Exit status:  func_name always returns with exit status 0.
  ' :
  local i
  echo "func_name: $# arguments"
  for ((i = 1; i <= $#; ++i)); do
    echo "func_name [$i] \"$1\""
    shift
  done
  return 0
}

2
hmmm, dotstrings in bash. Chi lo sapeva?
Brian Minton,

C'è un modo per interrogare quel commento? Sto pensando a una funzione di aiuto genery per tutti i comandi.
yucer

7

Sì, typesembra stampare solo le parti di una funzione che verrà eseguita. Questo mi sembra ragionevole, davvero, dal momento che di solito è tutto ciò a cui sei interessato durante le query type.

Per ovviare al problema, invece di utilizzare i commenti, aggiungi i tuoi metadati in questo modo:

func1() {
    meta="This function was generated for project: PROJECT1"
    echo "do my automation"
}

Non è necessario mai effettivamente utilizzare quella variabile, ma verrà visualizzato quando si esegue una query sulla funzione con type:

$ type func1
func1 is a function
func1 () 
{ 
    meta="This function was generated for project: PROJECT1";
    echo "do my automation"
}

2
Se si desidera evitare di memorizzare una variabile, è possibile utilizzare l'operatore nop ":" in questo modo: function func () {: "metadata" # do your}}
Luchostein

1
Penso che le virgolette singole siano meglio delle doppie virgolette qui, nel caso in cui ci siano espansioni indesiderate che si nascondono nella docstring
Digital Trauma,

6

Puoi usare il nop builtin :. Inoltre, non è necessario memorizzarlo come variabile:

function f() {
  : your metadata here
  : "or here"
  # do yours
}

EDIT : fai attenzione ai caratteri speciali nei tuoi metadati. Per il testo puro, puoi utilizzare:

: <<EOT
Your metadata text here.
EOT

EDIT : è possibile utilizzare invece un array associativo globale per memorizzare tutti i metadati della funzione:

declare -A METADATA=()
METADATA[fun1]='foo bar'
function fun1() {
  echo I have some metadata: "${METADATA[$FUNCNAME]}"
}
METADATA[fun2]='baz you'
function fun2() {
  echo I have some other metadata: "${METADATA[$FUNCNAME]}"
}

In questo modo, non è necessario analizzare declareo type's uscita, ma solo query per la chiave di un array.


1
Fai attenzione: your metadata herepotrebbe contenere espansioni che hanno effetti collaterali. Meglio usare virgolette singole come la risposta di @ AlexP.
Digital Trauma,

Sì, ma dovresti anche stare attento tra virgolette.
Luchostein,

3

Puoi farlo.

$ f() { This function does nothing. 2> /dev/null; }
$ f
$ type f
f is a function
f () 
{ 
    This function does nothing. 2> /dev/null
}

ma la funzione dovrebbe ancora fare le sue cose dopo essere stata annotata. Nell'esempio che avevo incluso l'eco dovrebbe ancora funzionare quando chiamo normalmente la funzione.
yucer

@yucer Sarebbe. Questa è solo un'illustrazione. Provalo. Ha i suoi limiti però. Non è (possibile utilizzare caratteri speciali come e la prima parola non deve essere un comando valido.

Ok. Pensa che sia una risposta valida, anche se richiede più tempo per l'esecuzione. Inoltre potrebbe essere meglio includere l'eco e i metadati che avevo usato nel mio esempio.
yucer
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.