Saluti.
erlug-admin@xxxxxxxxxxxxxx wrote:
> On Wed, Jan 28, 2004 at 12:37:06PM +0100, Maurizio Lemmo -
> Tannoiser wrote:
[...]
>> Ci sono poi diversi issue dovuti pero` alle differenze architetturali
>> delle due piattaforme: file system, quindi nomi di file, di path, e
>> quant'altro. Gestione del tempo. E altro ancora.
[...]
>
> Anche per questo problema ci sono opportuni moduli che mascherano le
> differenze. Non so in che modo usa i pathname, ma potrebbero tornare
> utile ad esempio File::PathConvert, File::VirtualPath o Path::Class
> (prova a guardare prima quest'ultimo).
Allora.
Perl (in versione reagionevolmente moderna) su win32 capisce sia
"C:\\foo\\bar" sia "C:/foo/bar" e perfino "C:\\foo/bar".Se poi si vuole
essere eccezionalmente portabili, ci sono i vari File::Spec, File::Parse e
File::Basename (non conosco quelli citati da Nando). Generalmente parlando,
per quello che ho visto e' assai piu' difficile passare da Win a *x che
viceversa (per via della presenza dello specificatore di volume, e di \ come
separatore ).
Una differenza inconciliabile sta nella case sensitivity - ma tendo a
considerare qualunque feature faccia conto sulle differenze di
capitalizzazione nei nomi una cagata pazzesca(tm) (si', anche il build di
perl -col suo distinguere Makefile e makefile, e lo stesso make).
[caveat: il numero di '\' o '/' all'inizio di un file e' significativo su
Win - path UNC, perl li
capisce - ma *non* su linux, quindi attenzione alle aperture di file che
improvvisamente falliscono
dopo due minuti di ricerca della macchina di nome 'usr' <== da
//usr/share/doc]
Un grosso pericolo (e una stronzata gigante) sono i nomi riservati di
windows: com, aux, lpt, tty... e caratteri !isalnum(c) come ad esempio ":"
(che su NT indica uno stream alternativo di un file).
Terminatori di riga per il file processing: se si vuole che \n => chr(10)
anziche' chr(13)chr(10) (<cr><nl>) bisogna specificare "b" in apertura e
scrittura (ma di questi tempi spesso non frega a nessuno)
L'ambiente user e' abbastanza diverso; ad esempio, non c'e' /tmp e bisogna
sempre fare riferimento
a $ENV{TMPDIR} e anche questo non funziona per roba di tipo server. Poi
manca $ENV{HOME} - etc.
Gestione del tempo: non me ne sono accorto, francamente, visto che uso quasi
solo time, localtime e gmtime - quelli vanno come ci si attende.
Gestione dei processi: assai diversa. I programmi che fork(2)ano avranno
problemi. AS e anche il build da me citato (che dovrebbe essere compatbile
con AS) cercano di emulare fork tramite i thread, ma i risultati sono
abbastanza sconsolanti. Chi ha bisogno del multiprocesso fa meglio a
ifdeffare e usare Win32::Process ("require", non "use", per portabilita').
"system" puo' dare sorprese, viste le assurde regole (??) di quoting di
command.exe, cmd e compagnia
(e poi system "de che?" system('bash -i') di sicuro non va...).
Altro non mi viene in mente.
Io ho scritto e sviluppo un'app scritta in mod_perl+apache su Win32 e
l'unica roba veramente Win-specific sta dopo
use Win32::OLE;
(e ci mancherebbe).
Esistono alcuni moduli di CPAN che non funzionano neanche a morire su Win ma
sono o estremamente specifici,o sono scritti a cazzo, tipo:
#get file list
@fl=split(/\n/,`ls -1`); # gulp yuk barf gasp choke
Il build che ho consigliato io ha molti piu' moduli webbosi (incluso
mod_perl) che non AS. Se non t'interessano, AS va piu' che bene direi, e ha
un grazioso installer.
Cheers,
alf
|