Moin,

entweder bin ich blind oder stehe im Wald.
Ich möchte Leerzeichen am Anfang eines Strings löschen.
Da ich mich mit den Regulärenausdrücken noch etwas schwer tue,
habe ich google befragt und bekomme das als Antwort.

$valve =~ s/^[\s\t]+//; # Leerzeichen am Anfang löschen

Aber bei mir beleiben die Leerzeichen drin - warum?

MfG
Heiko

Hallo,

Heiko Rompel wrote:
> entweder bin ich blind oder stehe im Wald.
> Ich möchte Leerzeichen am Anfang eines Strings löschen.
> Da ich mich mit den Regulärenausdrücken noch etwas schwer tue,
> habe ich google befragt und bekomme das als Antwort.
>
> $valve =3D~ s/^[\s\t]+//; # Leerzeichen am Anfang löschen
>
> Aber bei mir beleiben die Leerzeichen drin - warum?

Kann ich nicht nachvollziehen.
$ perl -wle 'my $a=3D" abc"; $a=3D~s/^[\s\t]+//;print $a'
abc
$

Jetzt wäre es interessant zu wissen, _was_ da für Leerzeichen am Anfa=
ng
stehen. Im Zweifelsfall per ord() herausfinden:

print join(", ", map {ord} split //, $valve), "\n";

gibt dir die ASCII-(bzw. Unicode-)-Werte für $valve aus.

Grüße,
Moritz

--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Hallo,

"Moritz Lenz" schrieb:

> Kann ich nicht nachvollziehen.

Schade :)

> Jetzt wäre es interessant zu wissen, _was_ da für Leerzeichen am Anfang
> stehen.

Spacetaste im INPUT-Feld eines HTML-Formulares gedrückt.


> print join(", ", map {ord} split //, $valve), "\n";
> gibt dir die ASCII-(bzw. Unicode-)-Werte für $valve aus.

Aber nur, wenn man das Script in der Konsole laufen läßt.
Da weiß ich aber nicht, wir ich es simuliere, das Daten von einem Formular
übergeben wurden.

MfG
Heiko

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig24F29FFBCDFF9395772063F3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hallo,

Heiko Rompel wrote:
>> Jetzt wäre es interessant zu wissen, _was_ da für Leerzeichen am A=
nfang
>> stehen.
>
> Spacetaste im INPUT-Feld eines HTML-Formulares gedrückt.

Wie holst du dir denn die Daten? per CGI und param()?

>> print join(", ", map {ord} split //, $valve), "\n";
>> gibt dir die ASCII-(bzw. Unicode-)-Werte für $valve aus.
>
> Aber nur, wenn man das Script in der Konsole laufen läßt.

du kannst mit
print STDERR join(", ", map {ord} split //, $valve), "\n";
nach STDERR schreiben, was du dann in der error.log deines Webservers
nachlesen kannst.

Alternativ kannst du auch Log::Handler nehmen und in eine Datei schreiben=
=2E

HTH,
Moritz
--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/


--------------enig24F29FFBCDFF9395772063F3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGe8YuAAkekJBI0yIRAuQwAKDmzACTQ5lLT/oOB0dt+o+Z/Ls0fQCb BZE2
DFQEiho4LCU+v/0WR+eFXpk=
=O3+6
-----END PGP SIGNATURE-----

--------------enig24F29FFBCDFF9395772063F3--

Post removed (X-No-Archive: yes)

Heiko Rompel schrieb:
> Hallo,
>
> "Moritz Lenz" schrieb:
>
>> Jetzt wäre es interessant zu wissen, _was_ da für Leerzeichen am Anfang
>> stehen.
>
> Spacetaste im INPUT-Feld eines HTML-Formulares gedrückt.
>
>
>> print join(", ", map {ord} split //, $valve), "\n";
>> gibt dir die ASCII-(bzw. Unicode-)-Werte für $valve aus.
>
> Aber nur, wenn man das Script in der Konsole laufen läßt.

Wieso? Das gibt dir in jedem Fall die Werte aus!

Du setzt einfach vorher noch ein "print 'Finde-mich'" und dann guckst du
einfach in der erzeugen html-Seite, wo das Finde-mich steht und was für
Zahlen dahinter sind. Sozusagen ein "Debugging für arme" ;-)

> Da weiß ich aber nicht, wir ich es simuliere, das Daten von einem Formular
> übergeben wurden.

Wieso simulieren?

Aber bitte (lange Zeile):

d:\>perl -e "use CGI qw(:standard);$_=param('x');print
qq(alt:>$_<\n);s/^\s+//; print qq(neu:>$_<)" "x= test "

Ausgabe:
alt:> test <
neu:>test <

Wolf

Hallo Moritz,

auch wennich Deinen letzten Beitrag nur umständlich lesen konnt,
so muss ich Dir schreiben, das das hier:

print STDERR "Hier die Auswertung\n";
print STDERR join(", ", map {ord} split //, $valve), "\n";

zu keinem Eintrag in Log führte.

Gleich sehe ich vor lauter ? nichts mehr. :-)

MfG
Heiko

Hallo,

Heiko Rompel wrote:
> auch wennich Deinen letzten Beitrag nur umständlich lesen konnt,

Ich vergaß, dass PGP/MIME zu fortschrittlich für Microsoft-Programme =
ist.

> so muss ich Dir schreiben, das das hier:
>
> print STDERR "Hier die Auswertung\n";
> print STDERR join(", ", map {ord} split //, $valve), "\n";
>
> zu keinem Eintrag in Log führte.

Was verwendest du denn für einen Server?

Wie gesagt, du kannst auch Log::Handler benutzen und in eine Datei loggen=
=2E

Grüße,
Moritz

--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Hallo,

"Moritz Lenz" schrieb:

>49 print STDERR "Hier die Auswertung\n";
>50 print STDERR join(", ", map {ord} split //, $valve), "\n";

Erzeugt im Log diese Meldung:
Hier die Auswertung
Use of uninitialized value in split at
E:/projekte/homepages/www.altwulsdorfer-schule.de/cgibin/spe nde.pl line 50.

Warum?

MfG
Heiko

Hallo,

Heiko Rompel wrote:
>>49 print STDERR "Hier die Auswertung\n";
>>50 print STDERR join(", ", map {ord} split //, $valve), "\n";
>
> Erzeugt im Log diese Meldung:
> Hier die Auswertung
> Use of uninitialized value in split at
> E:/projekte/homepages/www.altwulsdorfer-schule.de/cgibin/spe nde.pl line=
50.

Anscheinend enthält $valve den Wert undef.

Aber warum?
Das kann man dir wohl nicht beantworten, ohne den Code zu kennen.

Grüße,
Moritz

--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Hallo,

"Moritz Lenz" schrieb:

> Anscheinend enthält $valve den Wert undef.
Aber ist doch ein Leerzeichen drin.

> Das kann man dir wohl nicht beantworten, ohne den Code zu kennen.

=== Codeschnippsel =====

read(STDIN, $input, $ENV{'CONTENT_LENGTH'});
[at] pairs = split(/&/, $input);
foreach $pair ( [at] pairs) {
($name, $value) = split(/=/, $pair);
$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$name =~ s/\<.*?\>//g; # Alle Tags löschen
$name =~ s/\<!--//g; # Alle kommentag Anfänge löschen

$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s/\<.*?\>//g; # Alle Tags löschen
$value =~ s/\<!--//g; # Alle kommentag Anfänge löschen
$valve =~s/^[\s\t]+//; # Leerzeichen am Anfang löschen


print STDERR "Hier die Auswertung\n";
print STDERR join(", ", map {ord} split //, $valve), "\n";


$FORM{$name} = $value;
}
=====================

MfG
Heiko

Post removed (X-No-Archive: yes)

Martin Trautmann wrote:

> On Fri, 22 Jun 2007 16:08:39 +0200, Heiko Rompel wrote:
>> $value =~ tr/+/ /;
>> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
>> $value =~ s/\<.*?\>//g; # Alle Tags löschen
>> $value =~ s/\<!--//g; # Alle kommentag Anfänge löschen
> ^
>> $valve =~s/^[\s\t]+//; # Leerzeichen am Anfang löschen
> ^
>
>> print STDERR "Hier die Auswertung\n";
>> print STDERR join(", ", map {ord} split //, $valve), "\n";
> ^
>> $FORM{$name} = $value;
> ^
>
> Hallo Heiko,
>
> vielleicht solltest du einen Editor besorgen, der einen brauchbaren
> Zeichensatz bietet?

Und use strict; verwenden und die Variablen explizit deklarieren.

Gruss

Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/

Heiko Rompel schrieb:
> Hallo,
>
> "Moritz Lenz" schrieb:
>
>> Anscheinend enthält $valve den Wert undef.
> Aber ist doch ein Leerzeichen drin.
>
>> Das kann man dir wohl nicht beantworten, ohne den Code zu kennen.
>
> === Codeschnippsel =====
>
> read(STDIN, $input, $ENV{'CONTENT_LENGTH'});
> [at] pairs = split(/&/, $input);

Meine Güte!
WIE LANGE LIST DU HIER SCHON MIT?!

Sorry für das Rumgeschreie, aber wirklich! Warum verwendest du weder das
CGI-Modul noch strict/warnings, sodass dann $value und $valve nicht
auffällt?

Wolf

Asche auf mein Haupt.

> Meine Güte!
> WIE LANGE LIST DU HIER SCHON MIT?!

Nicht lange genug.

>
> Sorry für das Rumgeschreie, aber wirklich! Warum verwendest du weder das
> CGI-Modul

Weil ich damit nochweniger klar komme.

> noch strict/

Faulheit? Zu geringe Zeit mit Perl?

> warnings,

-w ist gesetzt, aber eventuell unter Windows wirkungslos.

> sodass dann $value und $valve nicht
> auffällt?

Und wiedereinmal saß der Fehler vor dem Schirm.

DANKE Euch allen für Eure Hilfe.

Gelobe Besserung.

MfG
Heiko

Hallo,

Heiko Rompel wrote:
>> Sorry für das Rumgeschreie, aber wirklich! Warum verwendest du weder=
das
>> CGI-Modul
>
> Weil ich damit nochweniger klar komme.

Aber CGI kommt mit Fällen zurecht, die dein Script nicht handhaben kann=
,
z.B. wenn die Daten in irgend einer Form kodiert sind (z.B.
get-Parameter: leerzeichen -> %20 etc.)

>> noch strict/
>
> Faulheit? Zu geringe Zeit mit Perl?

Das war das perfekte Beispiel dafür, dass use strict; dir viel Zeit
gespart hätte ;-)

> DANKE Euch allen für Eure Hilfe.
>
> Gelobe Besserung.

Na immerhin ;-)

Grüße,
Moritz

--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Heiko Rompel schrieb:
>> Sorry für das Rumgeschreie, aber wirklich! Warum verwendest du weder das
>> CGI-Modul
>
> Weil ich damit nochweniger klar komme.

Dann lies dich da ein. Das wird dir viel Arbeit ersparen.

>> noch strict/
>> warnings,
>
> -w ist gesetzt, aber eventuell unter Windows wirkungslos.
>
>> sodass dann $value und $valve nicht
>> auffällt?

Huh?
d:\>perl -we "$value='a'; $value='b'; $valve='c'; print $value"
Name "main::valve" used only once: possible typo at -e line 1.

Mit -w hättest du also obige Warnung bekommen sollen.
Mit strict hätte es sich nicht mal ausführen lassen.

Wolf

Hallo,

Wolf Behrenhoff wrote:
> Heiko Rompel schrieb:
>>> warnings,
>>
>> -w ist gesetzt, aber eventuell unter Windows wirkungslos.
>>
>>> sodass dann $value und $valve nicht
>>> auffällt?
>
> Huh?
> d:\>perl -we "$value=3D'a'; $value=3D'b'; $valve=3D'c'; print $value"
> Name "main::valve" used only once: possible typo at -e line 1.

Ich vermute, dass etwas anderes gemeint ist. Wenn die erste Zeile eines
Scripts so aussieht:

#! perl -w

dann wird unter windows nicht perl -w $script ausgeführt, d.h. das -w
hat keinen Effekt.
Daher
use warnings;

HTH,
Moritz

--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Moritz Lenz schrieb:
> Hallo,
>
> Wolf Behrenhoff wrote:
>> Heiko Rompel schrieb:
>>>> warnings,
>>> -w ist gesetzt, aber eventuell unter Windows wirkungslos.
>>>
>>>> sodass dann $value und $valve nicht
>>>> auffällt?
>> Huh?
>> d:\>perl -we "$value='a'; $value='b'; $valve='c'; print $value"
>> Name "main::valve" used only once: possible typo at -e line 1.
>
> Ich vermute, dass etwas anderes gemeint ist. Wenn die erste Zeile eines
> Scripts so aussieht:
>
> #! perl -w
>
> dann wird unter windows nicht perl -w $script ausgeführt, d.h. das -w
> hat keinen Effekt.

Hier schon:

d:\progs\test>cat ng.pl
#! perl -w
$value='a'; $value='b'; $valve='c'; print $value

d:\progs\test>perl ng.pl
Name "main::valve" used only once: possible typo at ng.pl line 2.
b

Wolf

Hallo,

Wolf Behrenhoff wrote:
> Moritz Lenz schrieb:
>> Hallo,
>>
>> Wolf Behrenhoff wrote:
>>> Heiko Rompel schrieb:
>>>>> warnings,
>>>> -w ist gesetzt, aber eventuell unter Windows wirkungslos.
>>>>
>>>>> sodass dann $value und $valve nicht
>>>>> auffällt?
>>> Huh?
>>> d:\>perl -we "$value=3D'a'; $value=3D'b'; $valve=3D'c'; print $value"=

>>> Name "main::valve" used only once: possible typo at -e line 1.
>>
>> Ich vermute, dass etwas anderes gemeint ist. Wenn die erste Zeile eine=
s
>> Scripts so aussieht:
>>
>> #! perl -w
>>
>> dann wird unter windows nicht perl -w $script ausgeführt, d.h. das -=
w
>> hat keinen Effekt.
>
> Hier schon:
>
> d:\progs\test>cat ng.pl
> #! perl -w
> $value=3D'a'; $value=3D'b'; $valve=3D'c'; print $value
>
> d:\progs\test>perl ng.pl
> Name "main::valve" used only once: possible typo at ng.pl line 2.
> b

OK, du hast mich überzeugt, aber ich glaube mich zu erinnern, dass es
irgend einen Fall gab, wo das nicht respektiert wurde.

Siehe z.B http://gunther.web66.com/FAQS/taintmode.html#other_servers
"CGI Scripts running on non-UNIX Servers typically do not recognize the
magical #!/usr/local/bin/perl first line of the script. Instead, the web
server knows what language to execute the server with because of an
operating system or web server configuration variable."

Ob das irgendwo immer noch irgendwo zutrifft kann ich aber nicht beurteil=
en.

Grüße,
Moritz

--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Post removed (X-No-Archive: yes)

Martin Trautmann schrieb:
> On Fri, 22 Jun 2007 16:24:48 +0100, Moritz Lenz wrote:
>> OK, du hast mich überzeugt, aber ich glaube mich zu erinnern, dass es
>> irgend einen Fall gab, wo das nicht respektiert wurde.
>
> ueber commandline wird der Fehler angezeigt, nicht aber beim Aufruf
> ueber's Web.

Bei meinem Apache unter Windows wird die Warnung dann in die error.log
geschrieben. Auch da werden also die Parameter berücksichtigt, die in
der #!-Zeile stehen.

Nur kann der Taint-Modus nicht verspätet angeschaltet werden.

Wolf

Moritz Lenz:

> Ich vermute, dass etwas anderes gemeint ist. Wenn die erste Zeile eines
> Scripts so aussieht:
>
> #! perl -w
>
> dann wird unter windows nicht perl -w $script ausgeführt, d.h. das -w
> hat keinen Effekt.

Das ist falsch. Der Perl-Interpreter liest die _ganze_ Datei und natürlich
auch die erste Zeile mit der Shebang. Entdeckt er darin den String "perl",
so werden auch angegebene Switches berücksichtigt.

Was unter Windows anders funktioniert, ist das Aktivieren von perl.exe
ansich (was unter UNIX durch die Shebang-Line erreicht wird), indem
der entsprechende Dateitype (.pl) dem Perl-Interrpeter zugeordnet wird.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol [at] adv.magwien.gv.at

Heiko Romple:

> > WIE LANGE LIST DU HIER SCHON MIT?!
>
> Nicht lange genug.

Schon mal perlfaq (speziell perlfaq3) gelesen? Da steht u.a. das
mit "use warnings" drin. Falls noch nicht, empfehle ich dir diese
Lektüre dringend - es zahlt sich aus.

> Zu geringe Zeit mit Perl?

Sorry, aber wenn du die Zeit hast, in Perl zu programmieren und
hier zu posten, dann solltest du auch die Zeit haben, dich mit Perl
zumindest einigermaßen vertraut zu machen. Das "zu geringe Zeit"
Argument lasse ich so nicht gelten. Immerhin hatten auch wir genug
Zeit, dein Posting zu lesen und darauf zu antworten. Du wirst ja wohl
auch nicht ein Auto lenken, ohne wenigstens rudimentäre Kenntnisse
vom Fahren zu haben, oder?

> -w ist gesetzt, aber eventuell unter Windows wirkungslos.

Es ist dann wirkungslos - unter Windows wie unter UNIX - wenn
das Skript mit "use", "do" oder "require" eingebunden wird. Das
ist in einer CGI-Umgebung nur dann der Fall, wenn eine persistente
Umgebung (z.B mod_perl) verwendet wird - dort kann man dann
Warnings mit entsprechenden Direktiven global ein- und ausschalten.
Ansonsten sollte eine Shebang mit -w auch in einer CGI-Umgebung
funktionieren, allerdings landen die entsprechenden Meldungen
natürlich im jeweiligen Serverlog (wo man immer nachschauen sollte,
wenn ein CGI-Skript nicht das tut, was es soll!). Das gilt natürlich
auch für "use warnings" bzw. "use strict" - bei letzterem wäre es dir
allerdings schneller aufgefallen, weil es dein Skript schon beim
Kompilieren "zerissen" und der Request mit einem "500 Internal
Server Error" geendet hätte.

Aber gerade für ein CGI-Skript ist die Verwendung von "use
warnings/use strict" fast schon eine heilige Pflicht - einhergehend
mit -T zum Einschalten von Tainting (-> perlsec).

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol [at] adv.magwien.gv.at

Moinsen,
bist du dir sicher, das die Leerzeichen drin bleiben?
Oder wird evtl nur ein einzelnes entfernt? Nur das erste...
Du solltest vllt mal das "g" als Modifizierer verwenden...

$valve =~ s/^[\s\t]+//g;

Gruss
Jan...

Heiko Rompel schrieb:
> Moin,
>
> entweder bin ich blind oder stehe im Wald.
> Ich möchte Leerzeichen am Anfang eines Strings löschen.
> Da ich mich mit den Regulärenausdrücken noch etwas schwer tue,
> habe ich google befragt und bekomme das als Antwort.
>
> $valve =~ s/^[\s\t]+//; # Leerzeichen am Anfang löschen
>
> Aber bei mir beleiben die Leerzeichen drin - warum?
>
> MfG
> Heiko

Moritz Lenz schrieb:
> OK, du hast mich überzeugt, aber ich glaube mich zu erinnern, dass es
> irgend einen Fall gab, wo das nicht respektiert wurde.
>
> Siehe z.B http://gunther.web66.com/FAQS/taintmode.html#other_servers
> "CGI Scripts running on non-UNIX Servers typically do not recognize the
> magical #!/usr/local/bin/perl first line of the script. Instead, the web
> server knows what language to execute the server with because of an
> operating system or web server configuration variable."
>
> Ob das irgendwo immer noch irgendwo zutrifft kann ich aber nicht beurteilen.

Das betrifft lediglich den Interpreter, die Schalter werden trotzdem
berücksichtigt.

Ausserdem stimmt die obige Aussage nicht, wenn Perl dort liegt
/usr/local/bin dann war das unter Windows auch schon immer richtig, nur
liegt dort fast nie die Perl-exe. Daher gibt es im windows Apache auch
eine Einstellung, um den Perlinterpreter woanders zu suchen. Aber wie
gesagt -w funktionierte schon immer.

Struppi.

Martin Trautmann schrieb:
> On Fri, 22 Jun 2007 16:24:48 +0100, Moritz Lenz wrote:
>> OK, du hast mich überzeugt, aber ich glaube mich zu erinnern, dass es
>> irgend einen Fall gab, wo das nicht respektiert wurde.
>
> ueber commandline wird der Fehler angezeigt, nicht aber beim Aufruf
> ueber's Web.

use CGI::Carp

http://search.cpan.org/~lds/CGI.pm-3.29/CGI/Carp.pm

Struppi.

Jan Teune wrote:

> Du solltest vllt mal das "g" als Modifizierer verwenden...
>
> $valve =~ s/^[\s\t]+//g;

Modifier g ist hier sinnlos, da durch die
Verankerung mittels ^ es sowieso nur einen Match geben kann.

BTW: Das ursprüngliche Problem hatte sich, wenn ich es
richtig mitbekommen habe, als dämlicher Tippfehler entpuppt.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Frank Seitz wrote:
> Jan Teune wrote:
>> Du solltest vllt mal das "g" als Modifizierer verwenden...
>>
>> $valve =~ s/^[\s\t]+//g;
>
> Modifier g ist hier sinnlos, da durch die
> Verankerung mittels ^ es sowieso nur einen Match geben kann.

Stimmt, da geb' ich auch noch einen drauf ;-)

Nicht nur das /g in Skalarkontext ist falsch
sondern auch die Zeichenklasse, da \s das\t bereits
enthält. Ausserdem kann man das schön optimieren:


$valve =~ s/^\s\s*//g;

Viele Grüße

Mirco

Mirco Wahab wrote:
> Frank Seitz wrote:
>>Jan Teune wrote:
>>>
>>>Du solltest vllt mal das "g" als Modifizierer verwenden...
>>>
>>>$valve =~ s/^[\s\t]+//g;
>>
>>Modifier g ist hier sinnlos, da durch die
>>Verankerung mittels ^ es sowieso nur einen Match geben kann.
>
> Stimmt, da geb' ich auch noch einen drauf ;-)
>
> Nicht nur das /g in Skalarkontext ist falsch

Das /g ist nicht falsch, es ist nur überflüssig.
Bei s/// hat der Modifier nichts mit dem Kontext zu tun.

> sondern auch die Zeichenklasse, da \s das\t bereits
> enthält.

Die Zeichenklasse ist auch nicht falsch.
Aber fehlkonstruiert, da hast Du recht.

> Ausserdem kann man das schön optimieren:
>
> $valve =~ s/^\s\s*//g;

Ich würde es so formulieren:

$valve =~ s/^\s+//;

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Frank Seitz wrote:
> Jan Teune wrote:
>> Du solltest vllt mal das "g" als Modifizierer verwenden...
>> $valve =~ s/^[\s\t]+//g;
>
> Modifier g ist hier sinnlos, da durch die
> Verankerung mittels ^ es sowieso nur einen Match geben kann.

Stimmt, da geb' ich auch noch einen drauf ;-)

Nicht nur das /g in Skalarkontext ist falsch/umsonst
sondern auch die Zeichenklasse, da \s das\t bereits
enthält. Ausserdem kann man das schön optimieren:


$valve =~ s/^\s\s*//;

Viele Grüße

Mirco

Frank Seitz wrote:
> Mirco Wahab wrote:
>>
>> $valve =~ s/^\s\s*//g;

Ups, ich drückte "absenden" und hatte das /g
noch nicht gelöscht :-((


> Ich würde es so formulieren:
>
> $valve =~ s/^\s+//;

Ich vermute mal stark, bei Riesentexten
mit "nur gelegentlichen" führenden
Leerzeichen ist die explizit optimierte
Form

$valve =~ s/^\s\s*//;

vorzuziehen (Gefühl). Wenn ich dazu
komme,teste ich das mal.

Viele Grüße

M.

Mirco Wahab wrote:
> Frank Seitz wrote:
>>
>>Ich würde es so formulieren:
>>
>> $valve =~ s/^\s+//;
>
> Ich vermute mal stark, bei Riesentexten
> mit "nur gelegentlichen" führenden
> Leerzeichen ist die explizit optimierte
> Form
>
> $valve =~ s/^\s\s*//;
>
> vorzuziehen (Gefühl).

Ich habe da genau das konträre Gefühl, d.h. falls es
einen Unterschied macht, halte ich die Formulierung
mit + für besser.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Frank Seitz wrote:

> Mirco Wahab wrote:
>> Frank Seitz wrote:
>>>
>>>Ich würde es so formulieren:
>>>
>>> $valve =~ s/^\s+//;
>>
>> Ich vermute mal stark, bei Riesentexten
>> mit "nur gelegentlichen" führenden
>> Leerzeichen ist die explizit optimierte
>> Form
>>
>> $valve =~ s/^\s\s*//;
>>
>> vorzuziehen (Gefühl).
>
> Ich habe da genau das konträre Gefühl, d.h. falls es
> einen Unterschied macht, halte ich die Formulierung
> mit + für besser.

Ich habe das Gefühl, dass man auf lange Sicht am besten fährt, wenn man es
genau so hinschreibt, wie es gemeint ist, d.h. s/^\s+//; ohne irgendwelche
"Optimierungen", da die durch Optimierungen gestiftete Verwirrung
möglicherweise länger andauert als die Zeit, die durch sie eingespart wird.
Und selbst wenn \s\s* gerade schneller als \s+ sein sollte, wer garantiert,
dass es bei der nächsten Regexp-Engine auch noch so sein wird?

Gruss

Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/

Frank Seitz:

> Ich habe da genau das konträre Gefühl, d.h. falls es
> einen Unterschied macht, halte ich die Formulierung
> mit + für besser.

Nein - die Suche mit Quantifiern wie + und *, bei denen die
Anzahl der Zeichen, auf die sie passen, zunächst nicht festgelegt
ist, ist immer uneffizienter, als eine Suche ohne solche Quantifier -
zumindest, wenn ich die Arbeitsweise von Perls Suchmaschine
(NFA) richtig verstanden habe (hängt mit dem "Backtracking",
das # und * durchführen, ab).

Im Fall von:

/^\s\s*/

muss zunächst nur genau das Zeichen am Beginn passen. Passt
das schon nicht, bricht die Regex Engine die Suche sofort ab
und der Ausdruck mit dem * Quantifier kommt gar nicht mehr
zum Tragen. Daher ist dieser Ausdruck im Erkennen von _nicht_
passenden Datensätzen effizienter. Anders gesagt: wenn absehbar
ist, dass die Mehrzahl der zu prüfenden Sätze _nicht_ passen wird
(d.h., mit keinem Whitespace beginnt), ist die obige Form effi-
zienter - wenngleich sich das vermutlich auch erst bei ein paar
Millionen Sätzen spürbar auswirken wird. Ansonsten, d.h., wenn
die Sätze überwiegend passen, dürfte es egal sein, welche Form
verwendet wird.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol [at] adv.magwien.gv.at

Ferry Bolhar schrieb:
> Frank Seitz:
>
>> Ich habe da genau das konträre Gefühl, d.h. falls es
>> einen Unterschied macht, halte ich die Formulierung
>> mit + für besser.
>
> Nein - die Suche mit Quantifiern wie + und *, bei denen die
> Anzahl der Zeichen, auf die sie passen, zunächst nicht festgelegt
> ist, ist immer uneffizienter, als eine Suche ohne solche Quantifier -
> zumindest, wenn ich die Arbeitsweise von Perls Suchmaschine
> (NFA) richtig verstanden habe (hängt mit dem "Backtracking",
> das # und * durchführen, ab).
>
> Im Fall von:
>
> /^\s\s*/
>
> muss zunächst nur genau das Zeichen am Beginn passen. Passt
> das schon nicht, bricht die Regex Engine die Suche sofort ab
> und der Ausdruck mit dem * Quantifier kommt gar nicht mehr
> zum Tragen. Daher ist dieser Ausdruck im Erkennen von _nicht_
> passenden Datensätzen effizienter. Anders gesagt: wenn absehbar
> ist, dass die Mehrzahl der zu prüfenden Sätze _nicht_ passen wird
> (d.h., mit keinem Whitespace beginnt), ist die obige Form effi-
> zienter - wenngleich sich das vermutlich auch erst bei ein paar
> Millionen Sätzen spürbar auswirken wird. Ansonsten, d.h., wenn
> die Sätze überwiegend passen, dürfte es egal sein, welche Form
> verwendet wird.

Bei /^\s+ muß doch auch mindestens ein Whitespace am Beginn
vorhanden sein. Der Test *kann* der selbe sein.
Ich gebe aber gerne zu, daß ich mich mit der Suchmaschine nicht
näher beschäftigt habe, was ich brauche kann ich (meistens ;-))
und das andere brauche ich nicht.

--
Schönen Gruß aus dem Bergischen Land
Robert

Robert Berghaus wrote:
> Ferry Bolhar schrieb:
>>Frank Seitz:
>>>
>>>Ich habe da genau das konträre Gefühl, d.h. falls es
>>>einen Unterschied macht, halte ich die Formulierung
>>>mit + für besser.
>>
>>Nein - die Suche mit Quantifiern wie + und *, bei denen die
>>Anzahl der Zeichen, auf die sie passen, zunächst nicht festgelegt
>>ist,

Bei + ist die Anzahl auf mindestens ein Zeichen festgelegt.

>>ist immer uneffizienter, als eine Suche ohne solche Quantifier -
>>zumindest, wenn ich die Arbeitsweise von Perls Suchmaschine
>>(NFA) richtig verstanden habe (hängt mit dem "Backtracking",
>>das # und * durchführen, ab).
>>
>>Im Fall von:
>>
>>/^\s\s*/
>>
>>muss zunächst nur genau das Zeichen am Beginn passen. Passt
>>das schon nicht, bricht die Regex Engine die Suche sofort ab
>>und der Ausdruck mit dem * Quantifier kommt gar nicht mehr
>>zum Tragen. Daher ist dieser Ausdruck im Erkennen von _nicht_
>>passenden Datensätzen effizienter. Anders gesagt: wenn absehbar
>>ist, dass die Mehrzahl der zu prüfenden Sätze _nicht_ passen wird
>>(d.h., mit keinem Whitespace beginnt), ist die obige Form effi-
>>zienter - wenngleich sich das vermutlich auch erst bei ein paar
>>Millionen Sätzen spürbar auswirken wird. Ansonsten, d.h., wenn
>>die Sätze überwiegend passen, dürfte es egal sein, welche Form
>>verwendet wird.
>
> Bei /^\s+ muß doch auch mindestens ein Whitespace am Beginn
> vorhanden sein.

Völlig richtig. Ich kann diese Optimierungsidee nicht
nachvollziehen. Die beiden Ausdrücke sind äquivalent. Und
wenn zwei reguläre Ausdrücke äquivalent sind, wähle ich
den einfacheren. Das ist für mich besser, der ich den Code verstehen
möchte, und im Zweifel auch für die Regex-Engine.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

>> Ich würde es so formulieren:

>> $valve =~ s/^\s+//;

> Ich vermute mal stark, bei Riesentexten mit nur gelegentlichen"führenden
> Leerzeichen ist die explizit optimierte Form

> $valve =~ s/^\s\s*//;

> vorzuziehen (Gefühl).

Um mal die grosse deutsche Dichterin und Philosophin Yvonne Catterfield zu
zitieren: "Unsere Gefuehle sind so schoen"...

1> cat Space.pl
use Benchmark qw(cmpthese);
for my $size (qw(0 1 2 3 4 5 10 500 1000)) { # nach Belieben anpassen
my $string = " " x $size . "x";
print "$size\n";
cmpthese(
-2,
{
'star' => sub { my $s = $string; $s =~ s{^\s\s*}{}; },
'plus' => sub { my $s = $string; $s =~ s{^\s+}{}; },
#'none' => sub { my $s = $string; },
},
);
}

Auf meinem Rechner gewinnt \s+.

Joerg Plate wrote:

> use Benchmark qw(cmpthese);
> for my $size (qw(0 1 2 3 4 5 10 500 1000)) { # nach Belieben anpassen
> my $string = " " x $size . "x";
> print "$size\n";
> cmpthese(
> -2,
> {
> 'star' => sub { my $s = $string; $s =~ s{^\s\s*}{}; },
^^^^^^^^^^^^^^^^ ^^
Warum kopierst Du die Daten? Und s/// produziert durch die
Substitution einen (mit wachsender Stringlänge zunehmenden)
Zusatzaufwand, um den es eigentlich nicht ging. Ansich
ging es ja nur um den Pattern-Match.

Ich habe den Benchmark mal reformuliert zu:

use Benchmark qw(cmpthese);
for my $string ('x ',' x') {
print "String='$string'\n";
cmpthese(
-2,
{
'star' => sub { $string =~ /^\s\s*/ },
'plus' => sub { $string =~ /^\s+/ },
},
);
}

Erster Lauf:

String='x '
Rate plus star
plus 2835215/s -- -15%
star 3355050/s 18% --
String=' x'
Rate star plus
star 2131864/s -- -11%
plus 2399630/s 13% --

Zweiter Lauf:

String='x '
Rate plus star
plus 2976546/s -- -10%
star 3292474/s 11% --
String=' x'
Rate plus star
plus 2244197/s -- -9%
star 2457598/s 10% --

Dritter Lauf:

String='x '
Rate plus star
plus 2976441/s -- -6%
star 3157814/s 6% --
String=' x'
Rate plus star
plus 2285187/s -- -2%
star 2336575/s 2% --

Die Aussage, dass durch \s\s* Zeilen, die nicht mit Whitespace
beginnen, schneller ausgeschlossen werden, scheint der
Test zu bestätigen.

Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Joerg Plate wrote:

> use Benchmark qw(cmpthese);
> for my $size (qw(0 1 2 3 4 5 10 500 1000)) { # nach Belieben anpassen
> my $string = " " x $size . "x";
> print "$size\n";
> cmpthese(
> -2,
> {
> 'star' => sub { my $s = $string; $s =~ s{^\s\s*}{}; },
^^^^^^^^^^^^^^^^ ^^

Da stecken einige Zusatzaufwände drin: Das Kopieren der Daten,
und s/// produziert durch die Substitution einen (mit wachsender
Stringlänge zunehmenden) Zusatzaufwand, um den es eigentlich
nicht ging. Ansich ging es ja nur um den Pattern-Match.

Ich habe den Benchmark mal reformuliert zu:

use Benchmark qw(cmpthese);
for my $string ('x ',' x') {
print "String='$string'\n";
cmpthese(
-2,
{
'star' => sub { $string =~ /^\s\s*/ },
'plus' => sub { $string =~ /^\s+/ },
},
);
}

Erster Lauf:

String='x '
Rate plus star
plus 2835215/s -- -15%
star 3355050/s 18% --
String=' x'
Rate star plus
star 2131864/s -- -11%
plus 2399630/s 13% --

Zweiter Lauf:

String='x '
Rate plus star
plus 2976546/s -- -10%
star 3292474/s 11% --
String=' x'
Rate plus star
plus 2244197/s -- -9%
star 2457598/s 10% --

Dritter Lauf:

String='x '
Rate plus star
plus 2976441/s -- -6%
star 3157814/s 6% --
String=' x'
Rate plus star
plus 2285187/s -- -2%
star 2336575/s 2% --

Die Aussage, dass durch \s\s* Zeilen, die nicht mit Whitespace
beginnen, schneller ausgeschlossen werden, scheint der
Test zu bestätigen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel