Newsgroup: it.comp.lang.perl
Titolo: [niubbo] #!usr/bin su win?

Ciao,
sto lavorando su win, ma il manuale non fa esplicito riferimento a
modificare la prima linea.... 
devo mantenere #!usr/bin/perl ? (tanto è un commento?)
grazie assaj
m.

 devo mantenere #!usr/bin/perl ? (tanto è un commento?)
ciao,
la linea ha *molta* importanza su *nix, su Windows meno, ma se vuoi far
eseguire i tuoi script "come si deve" ti installi perl su c:\usr, così
avrai l'interprete su /usr/bin/perl e la linea avrà più senso.
In ogni caso ogni script perl per essere compatibile dovrebbe avere la
"shebang".
ciao
Salvo
-- 
#!/usr/bin/perl
print "miii! mio cuggino cèla mette sempre la scibbenga \n";

Ciao anch'io sto avendo un problemino sulla prima riga....
L'exe del perl si trova nella cartella c:\perl\bin\perl.exe
ma modificando la prima riga
#!c:\perl\bin\perl.exe  in questo modo ed eseguendo un semplice file .pl me
lo apre con notepad.
L'unica soluzione che ho trovato fino ad ora e andare nella cartella
c:\perl\bin\ e digitare perl 
nomefle.pl
Cosa sbaglio??
Grazie
P.S  anche se sono nella cartella dove si trova il file .pl ed eseguo perl
nomefile.pl
 non succede nulla

 c:\perl\bin\ e digitare perl 
nomefle.pl
ciao,
ora non sono su Windows e non ricordo, ma hai provato con 
#!/perl/bin/perl.exe?
In ogni caso metti c:\perl\bin sul path per provare.
saluti
Salvo
-- 
#!/usr/bin/perl
print "~吧lvomi居 \n";

ok adesso va
#!/perl/bin/perl.exe era quella giusta
il comando per eseguire il file rimane cmq perl 
nomefile.pl
 nella directory dove risiede il file.
Grazie tante!!

  nella directory dove risiede il file.
anche se metti il percorso nel path?
ciao
Salvo

 nella directory dove risiede il file.
Su Windows lo shebang è ignorato (a meno che non si usi qualche
incarnazione Windows di bash o sh).
Quello che devi fare è mettere la directory dove risiede l'eseguibile perl
nel path, ed eventualmente associare i file .pl a perl (ma non funziona un
granché bene neanche così).
Un sistema un po' migliore è pl2bat (che comunque dà qualche problema). O
eventualmente si possono usare le funzionalità di Windows Script Host (che
ne danno qualche altro).
La cosa che funziona meglio, alla fine, è comunque "perl 
nomefile.pl
" o
"perl <percorso>\
nomefile.pl
", o "<percorso_perl>\perl
<percorso_script>\
nomefile.pl
" se la directory di perl non è nel path.
Ciao.

granché bene neanche così).
Sul mio W98 funziona abbastanza bene :)
'bye

Sul mio W98 funziona abbastanza bene :)
Dipende da quello che si fa. I problemi sorgono con il passaggio di
parametri e le pipe. E` *quasi* come eseguire 'perl 
nomefile.pl
', ma con
alcune differenze (di cui uno può anche non accorgersi mai, se non ha
bisogno di fare determinate operazioni, ma pure esistono); in breve, non
funziona un granché bene.
Ciao.

 parametri e le pipe. E` *quasi* come eseguire 'perl 
nomefile.pl
', ma con
E` *esattamente* come eseguire 'perl 
nomefile.pl
'.
Windows ignora la riga con lo shebang, ma perl la legge
e si regola di conseguenza.
Quindi se nello schebang hai messo delle opzioni perl il compilatore
perl (-i,-a, -p, -n,...) esse funzionano senza problemi, anche se
non le scrivi sulla linea di comando. Questo e` vero sia in unix/linux
che in windows.
--
 Ugo
 perl -e 'print scalar reverse 10.101.100.46.q<lennutnetnauq@ogu>'

e si regola di conseguenza.
Sì, sì, non metto in dubbio (quando mai, del resto? ho parlato di
"passaggio di parametri" e "pipe", come viene trattato lo shebang da perl
non c'entra per nulla). Il fatto è che, in determinate circostanze, si
possono incontrare problemi. Io di fatto li ho incontrati, sicché non posso
andare in giro a dire che è *esattamente* uguale quello che ho constato
essere talvolta diverso.
Se poi invece mi dimostri che quello che è diverso è invece uguale, allora
vorrà dire che me ne tornerò in buon ordine in bottega a vendere il pane.
Ciao.

Guarda... no, credimi. Non *esattamente*.
Per chiarire, sia 
prv152.pl
:
    #file: 
prv152.pl#
    while (<>) {
        print;
    }
    #eof: 
prv152.pl
e sia prv152.txt:
    #file: prv152.txt
    It was in the spring of the year 1894 that all London was
    interested, and the fashionable world dismayed, by the murder
    of the Honourable Ronald Adair under most unusual and
    inexplicable circumstances.
    The public has already learned those particulars of the crime
    which came out in the police investigation, but a good deal
    was suppressed upon that occasion, since the case for the
    prosecution was so overwhelmingly strong that it was not
    necessary to bring forward all the facts.
    #eof: prv152.txt
E sia perl -v:
  This is perl, v5.8.1 built for MSWin32-x86-multi-thread
  (with 1 registered patch, see perl -V for more detail)
  Copyright 1987-2003, Larry Wall
  Binary build 807 provided by ActiveState Corp. 
http://www.ActiveState.com
  ActiveState is a division of Sophos.
  Built 18:19:11 Nov  3 2003
su un'installazione standard di Windows 2000 Professional.
Sia inoltre:
  assoc .pl   -> .pl=Perl
  ftype Perl  -> Perl="C:\Programmi\Perl\bin\perl.exe" "%1" %*
Ora si eseguano:
    perl 
prv152.pl
 < prv152.txt
e
 
prv152.pl
 < prv152.txt
e si osservino i rispettivi comportamenti. Se sono *esattamente* gli
stessi, mi si dica che cosa devo cambiare nel mio sistema per ottenere il
medesimo risultato.
Ciao.

 medesimo risultato.
E` un esempio interessante.
Purtroppo non ho windows sotto mano. Questa sera, a casa,
provo con Win98 (non ho XP).
Ad ogni modo se il programma in perl perl riceve i due parametri
'<' e 'prv152.txt', allora si comporta in un certo modo
(tenta di aprire il file '<', etc...).
In unix l'interprete di comandi *NON* passa alcun parametro al
programma perl, ma associa lo standard input del processo con il
contenuto del file prv152.txt.
Quindi l'operatore <> in questo caso legge da standard input,
in quanto perl non ha ricevuto nessun parametro; pero` lo
standard input e` stato associato al file prv152.txt dal
sistema operativo, non dal Perl.
Per quel poco che ne so, il Dos e Windows non hanno un operatore
di ridirezione dell'input. Io proverei a usare questo programma
in perl, per vedere cosa fa il sistema operativo nei due casi:
#!perl
print qq("$_"\n) for @ARGV;  # Scrive la lista dei parametri
__END__
Sono convinto che se ci sono differenze e` perche` il sistema
operativo passa al Perl dei parametri differenti.
Ma alla fine hai ragione tu! Se si usano le pipe, ci possono
essere dei problemi. Grazie per l'informazione.


operativo passa al Perl dei parametri differenti.
Ah, be', se ci sono differenze è perché *qualcuno* fa *qualcosa* di
differente, certamente. Ed è molto probabile (leggi certo) che il
*qualcuno* sia la shell o il sistema operativo, non perl.
Il *qualcosa*, francamente, non ho idea di che cosa possa essere.
Ciao.

 Il *qualcosa*, francamente, non ho idea di che cosa possa essere.
Se è come nel mio caso (ma non ho win XP per verificare) si tratta di una
caratteristica del sistema operativo: quando in DOS scrivo un comando:
 testo.txt
non viene aperto il file testo.txt con la corrispondente applicazione, ad
es. notepad. E` semplicemente una scelta di chi ha progettato il sistema
operativo, l'interfaccia grafica usa un criterio diverso per
aprire/eseguire i file.
Ad ogni modo sono abbastanza ignorante di windows. Alla fine mi fido solo
di ciò che fa il Perl. :-)

aprire/eseguire i file.
No, no, a questo sono quasi sicuro che ci si arriva anche in Windows 98.
Forse hai lanciato 
command.com
 invece che cmd.exe (se c'è in Windows 98), o
c'è qualche altro problema di impostazione. Così a distanza non saprei
dire, anche perché ricordo poco di Windows 98, ma le associazioni ricordo
che funzionavano anche da linea di comando. In ogni caso non è il problema
di Windows 2000.
Su ActivePerl-Winfaq4.html ("What's the equivalent of the shebang ("#!")
syntax for Win32?" e "How do I associate Perl scripts with perl?") trovi
comunque spiegata tutta la procedura e gli avvertimenti (anche se la pagina
andrebbe probabilmente un po' aggiornata).
Ciao.

vengono eseguito con perl tramite il doppio click.
Da shell DOS per fare in modo che riconosca il programma da usare con
l'estensione devi usare il comando start:
start numedeltuofile.estensione
nel caso di uno script perl:
start 
iltuoscript.pl
Se usi un programma tipo Windows Commander (che mette a disposizione
anche una command line) al posto della shell DOS normale basta il nome
dello script.
'bye

__END__
perl 
script.pl
 a b c d
output:
"a"
"b"
"c"
"d"
start perl 
script.pl
 a b c d
output:
"a"
"b"
"c"
"d"
perl 
script.pl
 a b c d
(usando la command line di windows commander)
output:
"a"
"b"
"c"
"d"
'bye

start perl 
script.pl
 a b c d
*varie maledizioni inviate al copy&paste senza modificare la linea*
Questo e' il comando giusto:
start 
script.pl
 a b c d
L'output e' sempre quello:


E` vero! E non lo avevo mai saputo...
BTW, riguardo il pipe:
===begin script===
open OUTFILE, ">", "temp.tmp" || die "cannot open temp.tmp\n";
while(<STDIN>){
	print OUTFILE $_;
}
===end script===
comando da shell dos:
dir | start 
test00.pl
contenuto del file temp.tmp:
====
 Il volume nell'unita' E e' DS9_D      
 Numero di serie del volume: 3546-1E09
 Directory di E:\phpdev\perl\my\test
.              <DIR>        19/05/04  13.21 .
..             <DIR>        19/05/04  13.21 ..
TEST00   PL            104  19/05/04  13.22 
test00.pl
         1 file            104 byte
         2 dir         8.724.480 byte disponibili
====
Funziona anche il pipe.
'bye

Funziona anche il pipe.
Quand'anche, tanto vale scrivere 'perl 
test00.pl
', che si risparmia un
tasto (a meno che non si abbia qualche motivo per aprire una nuova istanza
della shell); e comunque non funziona in Windows 2000.
Ciao.