Esempio 1
Nell' applicazione seguente, supponiamo siano PARAM1 e PARAM2 le variabili da passare runtime all' applicazione IDL; chiaramente, queste possono essere di qualsiasi tipo (qualsiasi tipo previsto in IDL), nella fattispecie, sia PARAM1 un numero, PARAM2 un' immagine.

Pro my_application

; gestisco e utilizzo normalmente le variabili all'interno dell'applicazione
print, 'var_in : ', var_in
image_in = (image_in)
tv, image_in

; Per confermare il done delle operazioni di read sopra
res=dialog_message('Done')

End

A questo punto, si puo' procedere scrivendo un semplice script unix che setti i due parametri come variabili d'ambiente, lanci il setup di IDL e quindi l'applicazione runtime .

Appl.csh :
#! /usr/local/bin/tcsh -f
source /rsi/support/distrib/unix/idl54/idl_5.4/bin/idl_setup
setenv PARAM1 $1
setenv PARAM2 $2
idl -rt = 'my_application.sav'

NOTA : Tramite "appl.csh" , si possono ora richiamare i due parametri dal prompt unix :
/app var1 imageA

  Esempio 2 (Enea FTU)
L'esempio mostra l'utilizzo di setenv e getenv all' interno di una concreta applicazione IDL; la variabile da "passare" è in questo caso il numero identificativo dello shot da analizzare; lo script riceve la variabile ( $1 ) da linea di comando, crea una directory di output con il nome dello shot elaborato, lancia il setup di IDL e, all' interno di questo, setta tramite setenv $1 come variabile d'ambiente; la routine IDL "prende" $1 tramite getenv.

  Esempio 3 (Quando è possibile aggirare....)
L'esempio suggerisce un modo alternativo (quando applicabile) per risolvere il passaggio di parametri all' interno del batch file visto sopra: anzichè utilizzare setenv e getenv , in questo caso lo script e legge il paramentro da linea di comando mentre la procedura IDL lo legge in modo indipendente da file --> non c'è passaggio di valoridiretto tra lo script e il programma IDL.