Questo è il comando bashdb che può essere eseguito nel provider di hosting gratuito OnWorks utilizzando una delle nostre molteplici workstation online gratuite come Ubuntu Online, Fedora Online, emulatore online Windows o emulatore online MAC OS
PROGRAMMA:
NOME
bashdb - script del debugger bash
SINOSSI
bashdb [Opzioni] [--] nome-script [copione Opzioni]
bashdb [Opzioni] -C stringa di esecuzione
bash --debugger [bash-opzioni...] nome-script [copione Opzioni]
DESCRIZIONE
"bashdb" è uno script bash in cui è possibile eseguire il debug di un altro script bash. Il
debugger ha un'interfaccia di comando simile a quella di gdb(1).
Il modo in cui questo script organizza il debug è includendo (o effettivamente "fonte"-ing)
del codice di supporto per il debug e quindi reperire lo script o la stringa di comando specificati.
Un problema con il reperimento di uno script di cui è stato eseguito il debug è che il nome del programma memorizzato in $ 0 sarà
"bashdb" anziché il nome dello script di cui eseguire il debug. Lo script di cui è stato eseguito il debug
appaiono in uno stack di chiamate non come l'elemento in alto ma come l'elemento sotto "bashdb". Se questo è di
preoccupazione, usa l'ultima forma data sopra, "bash --debugger" nome-script [opzioni-script].
Se hai utilizzato lo script bashdb e devi passare le opzioni allo script per il debug, aggiungi "--"
prima del nome dello script. Ciò dirà a bashdb di non provare a elaborare ulteriori opzioni.
Vedere il manuale di riferimentohttp://bashdb.sourceforge.net/bashdb.html> per come chiamare
il debugger dall'interno del tuo programma o fai in modo che il debugger venga chiamato quando il tuo
programma viene inviato un segnale.
VERSIONI
-h | --aiuto
Stampa un messaggio di utilizzo sull'errore standard ed esci con un codice di ritorno di 100.
-A | --annotazione livello
Imposta per l'output di informazioni aggiuntive sullo stack e sullo stato che consentono front-end come
emacs per monitorare cosa sta succedendo senza polling.
Questo è necessario per i test di regressione. L'utilizzo di questa opzione equivale a emettere:
imposta l'annotazione LEVEL
all'interno del debugger.
-B | --nomebase
Nei punti in cui viene visualizzato un nome di file nell'output del debugger, fornire solo il nome di base.
Questo è necessario per i test di regressione. L'utilizzo di questa opzione equivale a emettere:
imposta il nome di base su
all'interno del debugger.
-n | nx
Normalmente il debugger leggerà i comandi del debugger in "~/.bashdbinit"se quel file
esiste prima di accettare l'interazione dell'utente. ".bashdbinit" è analogo a quello di Perl
".perldb" o ".gdbinit" di GNU gdb: un utente potrebbe voler creare un profilo di debug di questo tipo
per aggiungere varie personalizzazioni specifiche dell'utente.
Utilizzando l'opzione "-n" questo file di inizializzazione non verrà letto. Questo è utile in
test di regressione o nel rintracciare un problema con il proprio profilo ".bashdbinit".
-c stringa di comando
Invece di specificare il nome di un file di script, si può dare una stringa di esecuzione che
è da eseguire il debug. Usa questa opzione per farlo.
Se invochi il debugger tramite "bash --debugger", il nome del file che apparirà in
l'elenco di origine o in una traccia dello stack di chiamate sarà il nome artificiale *BOGUS*.
-q | --calmatevi
Non stampare la versione introduttiva e le informazioni sul copyright. Questo è di nuovo utile in
test di regressione in cui non vogliamo includere una data di copyright modificabile nel
corrispondenza test di regressione.
-x debugger-cmdfile
Esegui i comandi del debugger debugger-cmdfile prima di accettare l'input dell'utente. Queste
i comandi vengono comunque letti dopo qualsiasi comando ".bashdbinit". Di nuovo questo è utile
esecuzione di script di debug per i test di regressione.
-L | --biblioteca libreria-debug
Il debugger deve generare o includere un numero di funzioni e queste risiedono in a
biblioteca. Se questa opzione non viene data, la posizione predefinita della libreria è relativa a
lo script bashdb installato: "../lib/bashdb".
-T | --tempdir directory-file-temporanea
Il debugger deve fare uso di una memoria temporanea del filesystem per salvare persistenti
informazioni attraverso una subshell restituita o per valutare un'espressione. Il
la directory predefinita è "/ Tmp" ma puoi usare questa opzione per impostare la directory dove
verranno creati i file temporanei del debugger.
-t | --tty tty-nome
L'output del debugger di solito va a un terminale piuttosto che a STDOUT su cui è stato eseguito il debug
programma può utilizzare. La determinazione del tty o pseudo-tty viene normalmente eseguita
automaticamente. Tuttavia, se vuoi controllare dove va l'output del debugger, usa questo
opzione.
Se vuoi che l'output vada a STDOUT usa &1. Nota: potrebbe essere necessario sfuggire alla '&' oppure
citato per evitare l'interpretazione della shell con fork.
-V | --versione
Mostra il numero di versione e l'assenza di garanzia ed esci con il codice di ritorno 1.
-X | --traccia
Simile al tracciamento di linea ""set -x"" tranne che per impostazione predefinita la posizione di ogni linea,
vengono stampati il livello bash e il livello subshell. Potresti essere in grado di ottenere qualcosa
più o meno simile se imposti "PS4" come segue
export PS4='(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]}\n'
Tuttavia, contrariamente alla traccia ""set -x"", il rientro del programma originale è anche
conservato nell'output di origine. E se interrompi il programma con una pausa (a
segnale "SIGINT"), entrerai nel debugger (supponendo che il tuo programma non intrappoli)
"SIGENTE").
Usa bashdb online utilizzando i servizi onworks.net