Ho pochissima esperienza con i vecchi batch file del dos ma mi rendo conto che sono spesso utilissimi per automatizzare piccoli (e grandi) task.
E’ possibile passare parametri a riga di comando ad un file batch come a qualsiasi altro eseguibile.
Il file batch può accedere ai parametri passati a riga di comando attraverso la sintassi:
%n
dove n è un numero che indica la posizione del parametro sulla riga di comando.
%0 si riferisce al comando batch stesso, da %1 in poi ci si riferisce ai suoi parametri.
E’ possibile applicare particolari “trasformazioni” ai parametri passati dette “sostituzioni”.
E’ possibile ottenere l’elenco delle sostituzioni con il comando:
call /?
Di seguito un riassunto delle sostituzioni possibili:
| %~1 |
sostituisce il parametro %1 rimuovendo le virgolette; |
| %~f1 |
sostituisce il parametro %1 con il percorso completo; |
| %~d1 |
sostituisce il parametro %1 con la lettera di unità; |
| %~p1 |
sostituisce il parametro %1 con il solo percorso; |
| %~n1 |
sostituisce il parametro %1 con il nome del file; |
| %~x1 |
sostituisce il parametro %1 con la sola estensione del file; |
| %~s1 |
sostituisce il parametro %1 con i nomi brevi; |
| %~a1 |
sostituisce il parametro %1 con gli attributi del file; |
| %~t1 |
sostituisce il parametro %1 con la data e ora del file; |
| %~z1 |
sostituisce il parametro %1 con la dimensione del file; |
E’ possibile combinare i modificatori per ottenere risultati composti, qualche esempio:
%~dp0 sostituisce il comando con la sua lettera di unità e il suo percorso;
%~dp1 sostituisce il primo parametro con la sua lettera di unità e il suo percorso;
%~nx0 estrae il nome del comando batch completo di estensione;
%~snx1 sostituisce il primo parametro con il nome nel formato breve;
Potete scaricare da qui un file batch di esempio che riassume le varie sostituzioni possibili.
Fonte: http://www.sgart.it/Page/default.asp?id=30&e=207
Technorati Tag:
msdos,
batchfiles
In questi giorni, per saziare la mia patologica curiosità, sto studiando i sorgenti di Castle, in particolar modo della parte di Ioc (Castle.Windsor e Castle.Microkernel).
Ho creato una piccola applicazione Web con ASP.NET MVC, ho preparato alcuni componenti di prova, ho preparato i file di configurazione, ecc… solite cose.
Poi ho scaricato una build di debug dell’intero stack di Castle e ho iniziato ad analizzarne i sorgenti e a colpi di debugger e Step into…
Tutto bene fino ad un certo punto del sorgente (sempre lo stesso), quando il debugger ha iniziato a dare di matto e il comando Step into e alcuni breakpoint hanno iniziato a non funzionare:
Metto il breakpoint, F5(Go), il debugger lo becca, F11(Step into) e niente… Step into mi salta a piè pari alcuni pezzi di sorgente e si ferma un po’ più avanti. Oltre a questo capita che alcuni breakpoint non vengano neanche considerati dal debugger.
Penso: “Non è che per caso i file binari non sono allineati con i file PDB o roba del genere?”. Riscarico tutto e riprovo. Stessa cosa.
Penso: “Non è che inavvertitamente (mmha…) ho cambiato qualche impostazione del debugger?”. Verifico e niente, tutto a posto.
Inizio a Googlare… e finalmente, dopo una mezzoretta trovo questo post nel forum di MSDN:
Visual Studio 2008 SP1 Stepping and Breakpoint Issues
che parla proprio di questo problema. In sostanza di tratterebbe di un bug che esce solo in situazioni molto particolari quando si lavora con codice multithread su macchine multi-core.
Prima di installare la patch indicata provo il workaround manuale. OK. Funziona.
Installo la patch indicata poco sotto tra i commenti:
http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796
Posso continuare a studiare Castle.