2x @ an sub?

[perl_neuling($frage);]

Hallo Forum,

kann man an eine Subroutine 2 Arrays übergeben??

Ich kenne vorher die Anzahl der Listeneinträge nicht!

Die Subroutine ermittelt Ergebnisse in Dateien (@dateien) die in Verzeichnissen (@verzeichnisse) liegen. An die Sub wird IMMER @verzeichnisse übergeben. In einigen Fällen sollen jedoch die Dateien, die eingelesen werden sollen eingegrenzt werden. Daher soll noch in diesen speziellen Fällen @dateien übergeben werden. Rückgabe der Sub ist ein Auszug aus dem Inhalt der Dateien.

my @ergebnis = findeDetail((@verzeichnisse);
findeDetail {
my @alleDirs = @_;
....
return @details;
}

Danke für Hilfe ist gewiß.
perl_neuling($frage);

[Cheatah]

Hi,

kann man an eine Subroutine 2 Arrays übergeben??

ja, mittels Referenzen. Siehe

perldoc perlref
perldoc perlreftut

my @alleDirs = @_;

perldoc -f shift

Großes Lob für die Verwendung von 'my'!

Cheatah

[Alexander Foken]

Hi,

kann man an eine Subroutine 2 Arrays übergeben??

ja, mittels Referenzen. Siehe

perldoc perlref
perldoc perlreftut

my @alleDirs = @_;

perldoc -f shift

Großes Lob für die Verwendung von 'my'!

Cheatah

Moin Moin!

Kleines stupides Demo dazu:

#!/usr/bin/perl -w

use strict;

sub meine_sub($$)
{
  my ($aref1,$aref2)=@_;
  print "Alles aus array 1: ",join(", ",@$aref1),"\n";
  print "Alles aus array 2: ",join(", ",@$aref2),"\n";
  print "Erstes Element aus array 1: ",$aref1->[0],"\n";
}

my @demo1=(1,2,3);
my @demo2=(4,5,6);

meine_sub(@demo1,@demo2);

__END__

Alexander

[perl_neuling($danke);]

Vielen Dank.
Habe den Quellcode begonnen umzuschreiben. Allein diese Referenzen haben ihn von 403 auf 224 Zeilen gekürzt - und v.a. von Redundanzen befreit!
die perl_neue.

[Cheatah]

Hi,

Habe den Quellcode begonnen umzuschreiben. Allein diese Referenzen haben ihn von 403 auf 224 Zeilen gekürzt - und v.a. von Redundanzen befreit!

hoho, da wird sich garantiert noch einiges mehr machen lassen! *g*

200 Zeilen sind immer noch 'ne ganze Menge. Wenn Du mal ein kürzeres Script hast (so im Bereich einiger Dutzend Zeilen), dann poste es doch einfach mal, auf dass wir es "zerhackstückeln". Es stecken sicher viele Möglichkeiten der Optimierung drin, wenn nicht sogar ungeahnte Fehler.

A propos: Deine Scripts beginnen hoffentlich mit:

#!/usr/bin/perl -w
use strict;

Cheatah

[perl_neuling($Cheatah);]

Hi,

A propos: Deine Scripts beginnen hoffentlich mit:

... meine Scripts beginnen sogar mit
use strict;
use warnings;
use CGI::Carp qw(fatalsToBrowser);

... und sie sind wegen (oder eher auch) der Tatsache lang, dass ich (noch) versuche Module zu vermeiden. Also nutze ich zum "enthttp'n" der Query-Strings auch kein use CGI qw(:standard);, sonder zerbrösel das Ganze brav in foreach-Schleifen...

... vor dem Zerpflücken der Scripte durch Dich,  muss ich noch etwas an meinem Grundverständnis für my-Variablen arbeiten... dann wäre das mal ein sehr sehr spannendes Unterfangen: Cheatah -w

die perl_neue.

[xNeTworKx]

Hallo,

... meine Scripts beginnen sogar mit
use strict;
use warnings;
use CGI::Carp qw(fatalsToBrowser);

... und sie sind wegen (oder eher auch) der Tatsache lang, dass ich (noch) versuche Module zu vermeiden. Also nutze ich zum "enthttp'n" der Query-Strings auch kein use CGI qw(:standard);, sonder zerbrösel das Ganze brav in foreach-Schleifen...

wieso denn das ? ich sehe in der Vermeidung von Modulen nur Nachteile.

[perl_neuling($xNeTworKx);,]

wieso denn das ? ich sehe in der Vermeidung von Modulen nur Nachteile.

manche Module "lohnen" das Einbinden nicht. Lade ich das cgi-Modul in den Speicher, ist dies im Kontrast zu
foreach (@htmldaten) {
  $_ =~ s/%([\da-f]{2})/chr( hex($1) )/egi;
  $_ =~ tr/+/ /;
 }
kein wirklicher Gewinn.

Diese Einstellung mag sich im Laufe der Zeit wandeln... ich glaube für mich Perl besser erlernen zu können, wenn ich dies so basisbasiert wie möglich tue....

[Klaus Mock]

Hallo,

manche Module "lohnen" das Einbinden nicht. Lade ich das cgi-Modul in den Speicher, ist dies im Kontrast zu
foreach (@htmldaten) {
  $_ =~ s/%([\da-f]{2})/chr( hex($1) )/egi;
  $_ =~ tr/+/ /;
}
kein wirklicher Gewinn.

Für sich betrachtet scheint das wirklich unsinnig...

Diese Einstellung mag sich im Laufe der Zeit wandeln... ich glaube für mich Perl besser erlernen zu können, wenn ich dies so basisbasiert wie möglich tue....

... allerdings dolltest Du soetwas IMHO nur tun, wenn Du verstehen willst wie CGI im Allgemeinen, un dunter Perl im Speziellen gehandhabt werden kann. Es gibt für die Parameterübergabe durch CGI sehr viel mehr Konstellationen, die Du beachten mußt, um einen möglichst robusten Code zu erzeugen. Diesen solltest Du dann so oft es geht wiederverwenden, um mögliche Fehler durhc intesive Benutzung zu eliminieren. Am besten erledigst Du das in dem Du es in ein Modul auslagerst. Und genau das ist irgendwann imt CGI.pm passiert. Und dabei gibt es den Vorteil, daß es mehrere tausend Mal bereits im Einsatz ist, viele Fehler also bereits gefunden wurden.

Gerade wenn Du neu im Umgang mit einem unbekannten System (in Deinem Falle also Perl) bist, solltest Du so viel wie möglich auf gut getesteten Code zurückgreifen, um die Quellen der potenziellen Fehler zu minimieren.

Aber ansonsten wünsche ich Dir noch viel Spaß (den Du auch sicher haben wirst)

Grüße
  Klaus

[Michael Schröpl]

Hi Du,

manche Module "lohnen" das Einbinden nicht.
Lade ich das cgi-Modul in den Speicher, ist dies
im Kontrast zu
foreach (@htmldaten) {
  $_ =~ s/%([\da-f]{2})/chr( hex($1) )/egi;
  $_ =~ tr/+/ /;
}
kein wirklicher Gewinn.

kommt darauf an, auf welcher Ebene.
Deine Idee, Ladezeit zu sparen, mag in gewisser Weise
Sinn machen. Aber das, was es Dich in Deiner aktuellen
Lernphase kostet, bringt es Dir nicht wieder ein.

Diese Einstellung mag sich im Laufe der Zeit
wandeln... ich glaube für mich Perl besser erlernen
zu können, wenn ich dies so basisbasiert wie möglich
tue....

Ich würde es genau anders herum tun: Konzentriere Dich
auf diejenigen Teile Deiner Programme, welche die
Semantik Deiner Aufgabenstellung umsetzen (also wo Du
Dich mit der Materie am besten auskennst), und laß
Standardaufgaben wie die Behandlung der CGI-Schnitt-
stelle erst mal Standardmodule erledigen.

Wenn Du am Lernen bist, dann sind kurze, übersichtliche
Quelltexte viel wert (weil sie schnelle Lern-Erfolge
bringen, gut wartbar sind und Deine Motivation hoch
halten) - mehr als die paar CPU-Takte, die das Ver-
meiden von "use CGI;" vielleicht bringen mag.

Viele Grüße
      Michael

[Cheatah]

Hi,

manche Module "lohnen" das Einbinden nicht.

oh, das wirst Du anders sehen, wenn sich mal die Bedingungen ändern, und Du statt nur einem Modul hundert Scripts aktualisieren musst.

Lade ich das cgi-Modul in den Speicher, ist dies im Kontrast zu
foreach (@htmldaten) {
  $_ =~ s/%([\da-f]{2})/chr( hex($1) )/egi;
  $_ =~ tr/+/ /;
}
kein wirklicher Gewinn.

Ich weiß nicht. Ich halte es schon für einen großen Vorteil, wenn "%2B" nicht zu " " umgewandelt wird. Außerdem kannst Du mit CGI.pm nicht nur GET und POST auswerten - den entsprechenden Teil hast Du in Deinem wunderbar reduzierten Code schon unterschlagen - sondern kommst auch problemlos mit <select multiple> u.ä. zurecht.

Diese Einstellung mag sich im Laufe der Zeit wandeln...

Davon bin ich überzeugt - bisher schienst Du mir jedenfalls ziemlich vernünftig zu sein ;-)

ich glaube für mich Perl besser erlernen zu können, wenn ich dies so basisbasiert wie möglich tue....

Für experimentelle Zwecke ist das sicher nicht schlecht. Allerdings wirst Du später Deine Sportlichkeit auf eine harte Probe stellen, wenn Du Dich nämlich in den Hintern beißt. Es macht mehr Mühe, _mit_ Modulen zu programmieren - solange man es noch nicht kann. Hast Du Dich einmal an sie gewöhnt, wirst Du in fast allen Situationen wie selbstverständlich zu einem Modul greifen.

"Sind Perl-Scripts ohne Module stärker?"
"Nein! Nein. Nein - schneller, leichter, verführerischer."

(Frei nach Luke & Yoda :-)

Cheatah