Automatischer String-Umbruch nach x Zeichen
WauWau
- perl
Hola,
ich grübele gerade vor einem kleinen Problemchen. Ich habe irgendeinen String, z.B. sowas:
$text = "Das hier ist dann der Text, der umgebrochen werden soll und zudem noch in einen schönen kleinen Rahmen gefasst werden soll. Schön, nicht wahr?";
und das soll am Ende in sowas:
+----------------------------------+
| Das hier ist dann der Text, der |
| umgebrochen werden soll und |
| zudem noch in einen schönen |
| kleinen Rahmen gefasst werden |
| soll. Schön, nicht wahr? |
+----------------------------------+
bzw. vergleichbares. Doch irgendwie schaff ich es nicht, den String nach X zeichen umbrechen zu lassen. Am Besten also als Bruchstücke in ein Array. Hier ist mein Code, wie ich ihn bis jetzt "entwickelt" habe:
#!D:/perl/bin/perl -w
print "Content-type: text/html\n\n";
$text = "Das hier ist dann der Text, der umgebrochen werden soll und zudem noch in einen schönen kleinen Rahmen gefasst werden soll. Schön, nicht wahr?";
print "<html><pre>\n";
$trenner = "+------------------------------+";
print $trenner."\n";
my @zeilen = split(/NACH-30-ZEICHEN.../,$text);
foreach(@zeilen)
{
format STDOUT =
| @<<<<<<<<<<<<<<<<<<<<<<<<<<<<|
$_
.
write;
}
print $trenner;
"NACH-80-ZEICHEN..." müsste hier irgendwie eben nach 30 Zeichen "trennen".
Hat jemand eine Idee, wie ich das realisieren könnte?
Vielen Dank schon mal im Vorraus :),
WauWau
Hi,
Hat jemand eine Idee, wie ich das realisieren könnte?
perldoc Text::Wrap
Cheatah
Hallo Cheatah,
Hat jemand eine Idee, wie ich das realisieren könnte?
perldoc Text::Wrap
Du meinst http://selfhtml.teamone.de/cgiperl/module/standardmodule.htm#textverarbeitung ;-)
Ja, danke, ich werd's mir gleich mal durchlesen :)
Irgendwie schon komisch: bei PHP ist das eine ganz einfache normale Funktion, für die man kein großes Modul braucht, und bei Perl, was ja als soooo tolle Sprache in Bezug auf Textbearbeitung angepriesen wird, braucht man dafür ein Modul und sonstwas.
tsts... ;-)
bis morgen,
WauWauq
Hallo WauWau,
Irgendwie schon komisch: bei PHP ist das eine ganz einfache normale Funktion, für die man
kein großes Modul braucht, und bei Perl, was ja als soooo tolle Sprache in Bezug auf
Textbearbeitung angepriesen wird, braucht man dafür ein Modul und sonstwas.
Falsch. Bei PHP bemerkst du nur nicht, dass es ein "Modul" (ein echtes Modul-System gibt es in
PHP nicht) ist.
Grüße,
CK
Hallo Christian,
Irgendwie schon komisch: bei PHP ist das eine ganz einfache normale Funktion, für die man
kein großes Modul braucht, und bei Perl, was ja als soooo tolle Sprache in Bezug auf
Textbearbeitung angepriesen wird, braucht man dafür ein Modul und sonstwas.
Falsch. Bei PHP bemerkst du nur nicht, dass es ein "Modul" (ein echtes Modul-System gibt es in
PHP nicht) ist.
Doch, afaik gibt es schon so eine Art Modul-System. Oder was sind dann diese ganzen "extension"-Einträge in meiner php.ini? ;-)
Aber eine ganze Menge Dinge bzw. extensions können afaik in php "mitkompiliert" werden beim kompilieren des interpreters.
Oder so ähnlich ;-)
Na gut, jetzt aber noch mal zum "Thema": Ich nutze jetzt das Modul und es funktioniert auch soweit wunderbar, nur nicht, wenn ich dieses format-Zeugs benutze:
--------------START--------------------
use Text::Wrap
print "Content-type: text/html\n\n";
$text = "Das hier ist dann der Text, der umgebrochen werden soll und zudem noch in einen schönen kleinen Rahmen gefasst werden soll. Schön, nicht wahr?";
print "<html><pre>\n";
$Text::Wrap::columns = 30;
$trenner = "+------------------------------+";
print $trenner."\n";
my @zeilen = wrap("", "", $text);
foreach(@zeilen)
{
# Mit diesem format-Zeugs geht es nicht:
format STDOUT =
| @<<<<<<<<<<<<<<<<<<<<<<<<<<<<|
$_
.
write;
# Stattdessen nur "print $_;" benutztend geht es schon!?
}
print $trenner;
----------------------------ENDE-------------
Ich habe keine Ahnung, warum das mit diesem format-Zeugs nicht geht. Gibt es für dieses format-Ding keine alternative? mir gefällt nämlich auch nicht, dass es sich nicht einrücken lässt, also etwa sowas
foreach(@zeilen)
{
format STDOUT =
|.....
$_;
.
write;
}
schreiben lässt.
Bis morgen & viele griese[tm],
WauWau
Hallo WauWau,
Irgendwie schon komisch: bei PHP ist das eine ganz einfache normale Funktion, für die
man kein großes Modul braucht, und bei Perl, was ja als soooo tolle Sprache in Bezug
auf Textbearbeitung angepriesen wird, braucht man dafür ein Modul und sonstwas.
Falsch. Bei PHP bemerkst du nur nicht, dass es ein "Modul" (ein echtes Modul-System gibt
es in PHP nicht) ist.Doch, afaik gibt es schon so eine Art Modul-System. Oder was sind dann diese ganzen
"extension"-Einträge in meiner php.ini? ;-)
Ein Modul-System beinhaltet für mich: Namespaces, dazuladen nur im Bedarfsfall, etc, pp.
Aber eine ganze Menge Dinge bzw. extensions können afaik in php "mitkompiliert" werden
beim kompilieren des interpreters.
Tatsächlich müssen sämtliche Extensions in PHP zum Interpreter dazukompiliert werden. Die
Extensions-Einträge sind nichts anderes als eine Umsetzung mit dynamischem dazubinden.
Technisch das gleiche.
Grüße,
CK
Moin Christian,[1]
Irgendwie schon komisch: bei PHP ist das eine ganz einfache normale Funktion, für die
man kein großes Modul braucht, und bei Perl, was ja als soooo tolle Sprache in Bezug
auf Textbearbeitung angepriesen wird, braucht man dafür ein Modul und sonstwas.
Falsch. Bei PHP bemerkst du nur nicht, dass es ein "Modul" (ein echtes Modul-System gibt
es in PHP nicht) ist.
Doch, afaik gibt es schon so eine Art Modul-System. Oder was sind dann diese ganzen
"extension"-Einträge in meiner php.ini? ;-)
Ein Modul-System beinhaltet für mich: Namespaces, dazuladen nur im Bedarfsfall, etc, pp.
http://de.php.net/manual/de/function.dl.php. Namespaces gibt es wohl kaum, weil es nicht so eine große Modul-Ansammlung wie bei Perl gibt (cpan). ;-)
Aber eine ganze Menge Dinge bzw. extensions können afaik in php "mitkompiliert" werden
beim kompilieren des interpreters.
Tatsächlich müssen sämtliche Extensions in PHP zum Interpreter dazukompiliert werden. Die
Extensions-Einträge sind nichts anderes als eine Umsetzung mit dynamischem dazubinden.
Technisch das gleiche.
Ja, sozusagen. Aber letztenendes macht dl(modulblabla); in etwa vergleichbares wie "use ..." in perl. Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur für CGI-Programmierung benutzt. Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist), dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Gute Nacht,
WauWau
[1] sehr angebracht. Wir haben nämlich schon Montag. :(((
Ich wäre dafür, die Woche einfach zu überspringen und direkt zum
nächsten Wochenende überzukehren :). Ja, bitte ;-)
Hallo WauWau,
Ich kenne dl(). Aber auch hier wird nur dynamisch gebunden.
Namespaces gibt es wohl kaum, weil es nicht so eine große Modul-Ansammlung wie bei Perl
gibt (cpan). ;-)
Wenn du das sagst... (so ein Quark).
Aber eine ganze Menge Dinge bzw. extensions können afaik in php "mitkompiliert" werden
beim kompilieren des interpreters.
Tatsächlich müssen sämtliche Extensions in PHP zum Interpreter dazukompiliert werden. Die
Extensions-Einträge sind nichts anderes als eine Umsetzung mit dynamischem dazubinden.
Technisch das gleiche.Ja, sozusagen. Aber letztenendes macht dl(modulblabla); in etwa vergleichbares wie
"use ..." in perl.
Nein. use macht viel mehr. perldoc Exporter. perldoc perlmod.
Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man
das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur
für CGI-Programmierung benutzt.
So wie es sinnvoll ist.
Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist),
Es *gibt* ein CGI-Modul.
dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Und dann damit leben, dass man es auch laedt, wenn man es nicht braucht.
Grüße,
CK
Hallo Christian,
http://de.php.net/manual/de/function.dl.php.
Ich kenne dl(). Aber auch hier wird nur dynamisch gebunden.
Und was macht "use" dann? Ach ja, ich glaube ich vergaß, dass diese PHP-Extensions ja kompilierte ".so" oder (windows) ".dll"-"Programmchen" sind, im Gegensatz zu den Perl-Packages. Oder verwechsel ich hier wieder etwas?
Namespaces gibt es wohl kaum, weil es nicht so eine große Modul-Ansammlung wie bei Perl
gibt (cpan). ;-)
Wenn du das sagst... (so ein Quark).
Hmm... also ich habe hier etwa 2000 Dateien in dem Unterverzeichnis "lib" im (Active-)Perl (für windows). Afaik sind das ja eine ganze Menge Perl-module. Scheinen auf den ersten Blick alles in irgendeiner Art und Weise Textdateien zu sein.
Vergleich zu PHP: Isch habe die (quelle: http://www.php.net/downloads.php) "(CGI binary plus server API versions for Apache, Apache2 (experimental), ISAPI, NSAPI, Servlet and Pi3Web. MySQL support built-in, many extensions included, packaged as zip)"-Version.
Mehr als 60 Extensions scheinen da nicht dabei gewesen zu sein. Gibt es noch richtig viel mehr? Hmm... tja, auf http://www.php.net habe ich da keine große Übersicht gesehen, von "cpan für php" habe ich auch noch nie etwas gehört. Gibt es wirklich sooooooooo viele? Und wenn, wo?
Aber eine ganze Menge Dinge bzw. extensions können afaik in php "mitkompiliert" werden
beim kompilieren des interpreters.
Tatsächlich müssen sämtliche Extensions in PHP zum Interpreter dazukompiliert werden. Die
Extensions-Einträge sind nichts anderes als eine Umsetzung mit dynamischem dazubinden.
Technisch das gleiche.
Ja, sozusagen. Aber letztenendes macht dl(modulblabla); in etwa vergleichbares wie
"use ..." in perl.
Nein. use macht viel mehr. perldoc Exporter. perldoc perlmod.
Ewig viel Text ;-). Ok, ich glaube dir ja schon, dass PHP nicht ein annähernd so entwickeltes Modulsystem wie Perl hat (vor allem gibt es bei PHP ja afaik nicht diese einfachen packages, dass eine PHP-Datei mit ein paar Auszeichnungen zu einem "Package" werden kann).
Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man
das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur
für CGI-Programmierung benutzt.
So wie es sinnvoll ist.
hmm... wenn man perl wirklich ausschließlich für die CGI-Programmierung nutzt und _immer_ das cgi-modul geladen haben will, dann wäre ein "standartladen" des cgi-moduls überaus sinnvoll, oder!?
Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist),
Es *gibt* ein CGI-Modul.
wie? wo?
dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Und dann damit leben, dass man es auch laedt, wenn man es nicht braucht.
Stimmt, bei Linux wird Perl auch auch in Shellscripten und so nem Zeugs verwendet, da braucht man es nicht, klar. Aber ansonsten - .
Gruß,
WauWau
Hallo WauWau,
http://de.php.net/manual/de/function.dl.php.
Ich kenne dl(). Aber auch hier wird nur dynamisch gebunden.Und was macht "use" dann? Ach ja, ich glaube ich vergaß, dass diese PHP-Extensions ja
kompilierte ".so" oder (windows) ".dll"-"Programmchen" sind, im Gegensatz zu den
Perl-Packages. Oder verwechsel ich hier wieder etwas?
Ja. Perl kann .so-Dateien benutzen aber auch Module, die in Perl geschrieben sind. use
bindet bei Bedarf die so-File irgendwann dazu, aber nur bei Bedarf.
Namespaces gibt es wohl kaum, weil es nicht so eine große Modul-Ansammlung wie bei Perl
gibt (cpan). ;-)
Wenn du das sagst... (so ein Quark).
Das habe ich als Quark bezeichnet, weil du gesagt hast, PHP haette keine Namespaces weil
es nicht so viele Module gibt. Das ist Quark. a) ist das nicht der Grund und b) hat PHP
durchaus eine ansehnliche Menge Module, siehe hier:
http://de.php.net/manual/en/index.php (Ab Function Reference bis Zend API sind
alle Links Extensions)
und hier:
Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man
das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur
für CGI-Programmierung benutzt.
So wie es sinnvoll ist.hmm... wenn man perl wirklich ausschließlich für die CGI-Programmierung nutzt und
_immer_ das cgi-modul geladen haben will, dann wäre ein "standartladen" des cgi-moduls
überaus sinnvoll, oder!?
Nein. Es gibt in einer realen Landschaft keine ausschliesslichen Zweck einer
Programmiersprache.
Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist),
Es *gibt* ein CGI-Modul.wie? wo?
In ext/standard/basic_functions.c
dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Und dann damit leben, dass man es auch laedt, wenn man es nicht braucht.Stimmt, bei Linux wird Perl auch auch in Shellscripten und so nem Zeugs verwendet, da
braucht man es nicht, klar. Aber ansonsten - .
Auch PHP wird auf der Shell gebraucht. Und beide nicht nur unter Linux.
Grüße,
CK
Hallo Christian,
http://de.php.net/manual/de/function.dl.php.
Ich kenne dl(). Aber auch hier wird nur dynamisch gebunden.
Und was macht "use" dann? Ach ja, ich glaube ich vergaß, dass diese PHP-Extensions ja
kompilierte ".so" oder (windows) ".dll"-"Programmchen" sind, im Gegensatz zu den
Perl-Packages. Oder verwechsel ich hier wieder etwas?
Ja. Perl kann .so-Dateien benutzen aber auch Module, die in Perl geschrieben sind. use
bindet bei Bedarf die so-File irgendwann dazu, aber nur bei Bedarf.
ach so, klar.
Namespaces gibt es wohl kaum, weil es nicht so eine große Modul-Ansammlung wie bei Perl
gibt (cpan). ;-)
Wenn du das sagst... (so ein Quark).
Das habe ich als Quark bezeichnet, weil du gesagt hast, PHP haette keine Namespaces weil
es nicht so viele Module gibt. Das ist Quark. a) ist das nicht der Grund und b) hat PHP
durchaus eine ansehnliche Menge Module, siehe hier:
http://de.php.net/manual/en/index.php (Ab Function Reference bis Zend API sind
alle Links Extensions)
echt? Diese ganzen dinge wie Array-Funktionen, String-Funktionen und sowas - alles Module? Wahnsinn... ja, ich glaube, langsam komme ich wirklich auf die Idee, eine Programmiersprache nicht mehr anhand ihrer "Standartfunktionalität" zu bewerten (wie ich es immer so abschätzig mit JavaScript mache).
und hier:
http://pear.php.net/
http://pear.php.net/packages.php - ok, ich nehme _alles_ zurück, was ich jemals über PHP|Perl|Module gesagt habe. Alles. Du hast mich überzeugt :)
Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man
das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur
für CGI-Programmierung benutzt.
So wie es sinnvoll ist.
hmm... wenn man perl wirklich ausschließlich für die CGI-Programmierung nutzt und
_immer_ das cgi-modul geladen haben will, dann wäre ein "standartladen" des cgi-moduls
überaus sinnvoll, oder!?
Nein. Es gibt in einer realen Landschaft keine ausschliesslichen Zweck einer
Programmiersprache.
Na gut, wenn man jede einzelne klitzekleine Ausnahme als ein "brechen" dieser Regel ansieht, nicht ;-). Aber z.B. mal PHP: Ich könnte mir nicht vorstellen, PHP für Batch-Scripte oder sowas zu benutzen...
Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist),
Es *gibt* ein CGI-Modul.
wie? wo?
In ext/standard/basic_functions.c
Hmmm... den Sourcecode von PHP habe ich mir ehrlich gesagt noch nie gangeschaut - obwohl er auch nur 4MB groß ist ;). Müsste ich mal tun, genau.
dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Und dann damit leben, dass man es auch laedt, wenn man es nicht braucht.
Stimmt, bei Linux wird Perl auch auch in Shellscripten und so nem Zeugs verwendet, da
braucht man es nicht, klar. Aber ansonsten - .
Auch PHP wird auf der Shell gebraucht.
Na gut, man kann es ohne weiteres dafür verwenden, aber das finde ich irgendwie komisch ;)
Und beide nicht nur unter Linux.
(Per|PHP) für Batchdateien unter Windows nutzen geht, habe ich sogar selbst mal gesehen ;-), gut. Aber wieso sollte man hier nicht diese einfache irgendwas-sprache, die dort standartmäßig benutzt wird (?) nutzen? Dann ist es wenigstens ein bisschen Windows-Plattformunabhängig. Immerhin lässt sich der Prozentanteil, der Perl oder PHP auf Windows so installiert hat, ja auch an 20.000 Händen abzählen (für die gesamte Welt). Oder auch an mehr. Oder weniger. naja, auf jeden FAll ist es vergleichsmäßig wenig, würde ich sagen.
WauWau
Ja, sozusagen. Aber letztenendes macht dl(modulblabla); in etwa vergleichbares wie "use ..." in perl. Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur für CGI-Programmierung benutzt. Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist), dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Ich weiß nicht, ob du dir mal das CGI Modul richtig angeguckt hast. Aber ich bezweifle, das das was dieses Modul kann in PHP als Standard integriert ist. Das CGI Modul ist nicht nur für die CGI Parameter gut, sondern gerade wenn es um HTML Tabellen oder Formulare geht erspart es dir einiges an Tipparbeit und macht aus jedem HTML/Quellcode misch masch ein schönes übersichtliches Perlprogramm, aber dazu muss man sich halt erst mit der Dokumentation dazu auseinandersetzen.
Struppi.
Hallo Struppi,
Ich weiß nicht, ob du dir mal das CGI Modul richtig angeguckt hast. Aber ich bezweifle, das das was dieses Modul kann in PHP als Standard integriert ist. Das CGI Modul ist nicht nur für die CGI Parameter gut, sondern gerade wenn es um HTML Tabellen oder Formulare geht erspart es dir einiges an Tipparbeit und macht aus jedem HTML/Quellcode misch masch ein schönes übersichtliches Perlprogramm, aber dazu muss man sich halt erst mit der Dokumentation dazu auseinandersetzen.
Ja, stimmt, da kann man HTML-Elemente und sowas erzeugen. Als ich das das erste mal gesehn habe, dachte ich "was soll denn der schwachsinn" - aber stimmt, damit ließe sich so ein gefriemel wie
"<img ".($bla?"bla":"bla").'src="'.$bla.'"....
ersparen. Nun, nein, das gibt es nicht in PHP, klar.
Das wiederspricht aber gewissermaßen andererseits dem, was Christian gesagt hat:
<zitat quelle="[pref:t=81012&m=470913]">
Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist),
Es *gibt* ein CGI-Modul.
</zitat>
?
Gruß,
WauWau