Liebe Python-Freunde,
diesen Donnerstag, den 17.8.2009 (übermorgen!) findet wieder ein
PUB/DZUG-Treffen (Python und Zope User Group in Berlin) statt.
Ort und Zeit sind wie immer: 19 Uhr, im newthinking store [1].
Anschließend wird das Treffen wieder im Restaurant Tucholsky [2]
fortgesetzt. Zur Planung der Restaurantkapazitäten bitte ich euch
ein Häckchen in der Doodle-Umfrage [3] zu machen, wenn ihr an-
schließend noch mitkommen wollt.
Das Programm muss dieses mal etwas kurzfristig arrangiert werden.
Wer also schon immer mal einen kurzen Vortrag halten wollte, z.B.
zu einem der Themen im Python-Wiki [4] und diesen womöglich schon
in der Schublade hat, der (oder die) ist herzlich dazu eingeladen.
Dann bitte bei mir vorher kurz per E-Mail ankündigen!
Ansonsten werden einige, die auf der DZUG-Tagung letzte Woche in
München waren, locker darüber berichten. Dabei ging es unter an-
derem über die kommenden Versionen 4 und 5 von Plone. Sehr wahr-
scheinlich wird Veit dazu Prospekte verteilen.
Eine weitere Idee besteht darin, locker Buchempfehlungen zu den
Themen Python/Zope/Plone auszutauschen, was man am besten macht,
indem man das jeweilige Buch auch zum Treffen mitnimmt. Ich werde
am Donnerstag das Buch "Python for Linux and Unix System Admini-
stration" [5] dabei haben.
Liebe Grüße und bis Donnerstag,
Dinu
PS: Ich übernehme mit Veit bis auf Weiteres die Organisation die-
ser Treffen von Stephan, der das bisher vorbildlich gemacht hat,
aber nun seinen väterlichen Aufgaben höhere Priorität geben wird.
Nochmals vielen Dank, Stephan - ich hoffe, Du kannst trotzdem
noch vorbeischauen!
[1] newthinking store, Tucholskystr. 48, 10117 Berlin,
http://newthinking-store.de
[2] Restaurant Tucholsky, Torstraße 189, 10115 Berlin,
http://www.restauration-tucholsky.de
[3] http://doodle.com/rwqizz6ewxk6iscw
[4] http://wiki.python.de/User%20Group%20Berlin
[5] http://www.oreilly.de/catalog/9780596515829
......................................................................
Follow me on Twitter: http://twitter.com/dinugherman
Hi Zusammen
vor ein paar Tagen hab ich damit angefangen mich für das pyfilesystem2
https://www.pyfilesystem.org/ zu interessieren.
Eine sehr gute Idee um diverse storages gleich zu behandeln.
Andreas Jung, hat darüber schon vorgetragen
https://www.slideshare.net/ajung/pyfilesystem
Mir fehlt momentan ein GUI wie z.B. QtWidgets.QFileDialog in das ich diese
API einhängen kann. Gibt es da bereits irgendwas?
Viele Grüße
Reimar
Hi,
Woohoo! The PyCon 2018 CFP is open!
Here is a link to all the information: https://us.pycon.org/2018/speaking/
- Tutorial proposals — deadline is 24 November 2017 AoE.
- Talk, Poster, and Education Summit proposals — deadline is 3 January
2018 AoE.
If you know of a company who might be interested in sponsoring, feel free
to share our prospectus: https://us.pycon.org/2018/sponsors/prospectus/. Or
an email intro to me would be wonderful, too.
Cheers,
Betsy
________________________________________________________________________
ANKÜNDIGUNG
Python Meeting Düsseldorf
http://pyddf.de/
Ein Treffen von Python Enthusiasten und Interessierten
in ungezwungener Atmosphäre.
Mittwoch, 27.09.2017, 18:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf
Diese Nachricht ist auch online verfügbar:
http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2017-09-27
________________________________________________________________________
NEUIGKEITEN
* Bereits angemeldete Vorträge:
Dr. Uwe Ziegenhagen
"Datenanalyse mit Python pandas"
Charlie Clark
"Typ-Systeme in Python"
Weitere Vorträge können gerne noch angemeldet werden: info(a)pyddf.de
Allerdings wird vermutlich bei diesem Treffen kein Platz mehr sein,
sondern erst beim nächsten Mal im 27.09.2017.
* Startzeit und Ort:
Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer
Arcaden.
Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und
befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer
Arcaden.
Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter
der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock
hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus
dem Aufzug kommt.
Google Street View: http://bit.ly/11sCfiw
________________________________________________________________________
EINLEITUNG
Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in
Düsseldorf, die sich an Python Begeisterte aus der Region wendet:
* http://pyddf.de/
Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal,
auf dem wir die Vorträge nach den Meetings veröffentlichen:
* http://www.youtube.com/pyddf/
Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld,
in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:
* http://www.egenix.com/
* http://www.clark-consulting.eu/
________________________________________________________________________
PROGRAMM
Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning)
Talks und offener Diskussion.
Vorträge können vorher angemeldet werden, oder auch spontan während
des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung
steht zur Verfügung.
(Lightning) Talk Anmeldung bitte formlos per EMail an info(a)pyddf.de
________________________________________________________________________
KOSTENBETEILIGUNG
Das Python Meeting Düsseldorf wird von Python Nutzern für Python
Nutzer veranstaltet. Um die Kosten zumindest teilweise zu
refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von
EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00
inkl. 19% Mwst.
Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.
________________________________________________________________________
ANMELDUNG
Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir
bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung
eingegangen. Es erleichtert uns allerdings die Planung.
Meeting Anmeldung bitte formlos per EMail an info(a)pyddf.de
________________________________________________________________________
WEITERE INFORMATIONEN
Weitere Informationen finden Sie auf der Webseite des Meetings:
http://pyddf.de/
Mit freundlichen Grüßen,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Sep 26 2017)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> Python Database Interfaces ... http://products.egenix.com/
>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/http://www.malemburg.com/
Hallo liste,
gerade schreibe ich ein Python3 Programm, welches durch Makefiles
installiert wird. Somit können Applikationsdaten sowohl unter
/usr/share, als auch unter /usr/local/share liegen.
Nun möchte ich ein File aus diesem Ordner an ein Ziel kopieren. Wie
kann ich am Besten darauf zugreifen?
Gruß
Sascha
--
Sascha Manns | openSUSE Member
Email: saigkill(a)opensuse.org | Blog: http://saigkill.tuxfamily.org
GPG: 0x62ECD463
Hallo,
das ist etwas off-topic, aber vielleicht doch interessant ...
Ich habe bei einem Projekt vier Gruppen:
- Softwareentwickler
- Teamleiter der Softwareentwickler
- Anwender der Software
- Teamleiter der Anwender
Die ersten zwei sind angestellt beim Dienstleister, die anderen zwei sind "Kunden".
Für die Details haben wir ein Ticketsystem, das ist kein Problem.
Aber für die High-Level-Sicht fehlt mir derzeit ein passendes Tool.
Gantt Diagramme wäre schon schön. Also zB "Mit B kann es erst los gehen, wenn A fertig ist".
Es sollte webbasiert sein.
Wichtig ist eine gemeinsame Sicht...
Wenn man nach "web gantt project management" sucht, findet man endlos viele Treffer.
Hat hier jemand einen Tipp?
Wie schafft ihr Übersicht bei größeren Software-Projekten?
Gruß,
Thomas
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
On 2017-09-16 08:33, Stefan Behnel <python-de(a)behnel.de> wrote:
> Peter J. Holzer schrieb am 16.09.2017 um 09:28:
>> (String-Konkatenation ist in Python(3) zumindest bei langen Strings auch
>> schön linear)
>
> Es gibt sowohl für bytes-Objekte als auch für Unicode-Strings eine
> Sonderbehandlung, die realloc() verwendet. Auf vielen Platformen ist
> realloc() effizient und führt im Durchschnitt zu einer linearen Laufzeit
> auch bei mehreren Konkatenierungen. Aber nicht auf allen.
Ineffiziente Plattformen sollte man meiden :-). Allerdings ist das eher
eine Frage, wie Python damit umgeht als wie gut die Malloc-
Implementation ist - obwohl eine gute Malloc-Implementation gewisse
Schwächen im Interpreter gut übertünchen kann (wie eine Diskussion zum
gleichen Thema in Perl vor ein paar Jahren gezeigt hat).
> Außerdem greift die Optimierung nicht in allen Fällen. Beispielsweise hast
> du Pech, wenn über die Konkatenierungen hinweg der Zeichenraum erst von
> ASCII auf BMP und dann auf Astral wechselt. Dann muss beim Wechsel der
> komplette bisherige String doch wieder im Speicher herum kopiert werden.
Das dürfte weitgehend vernachlässigbar sein, weil es maximal 2 solche
Übergänge geben kann. Also viel weniger als die Kopiervorgänge, die
üblicherweise tatsächlich stattfinden, weil realloc nicht in-place
expandieren kann.
> Also kurz: join() ist in jedem Fall die bessere Variante bei vielen
> Strings. Konkatenierung ist ok bei einer überschaubaren Menge und da
> insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden werden.
Du vergisst, dass Listen einen nicht zu vernachlässigbaren
Memory-Overhead haben. Gerade bei langen Listen sollte man darauf
verzichten, sie aufzubauen, wenn man sie nicht unbedingt braucht (habe
damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl und
nicht Python, aber die beiden Sprachen sind sich da sehr ähnlich)).
Kleiner Test:
------------------------------------------------------------------------
#!/usr/bin/python3
import sys
import time
n = int(sys.argv[1])
t0 = time.clock_gettime(time.CLOCK_MONOTONIC)
s = ""
for i in range(n):
s += str(i)
t1 = time.clock_gettime(time.CLOCK_MONOTONIC)
print(n, t1-t0, n / (t1 - t0))
------------------------------------------------------------------------
------------------------------------------------------------------------
#!/usr/bin/python3
import sys
import time
n = int(sys.argv[1])
tick_size = 1000000
t0 = time.clock_gettime(time.CLOCK_MONOTONIC)
elems = []
for i in range(n):
elems.append(str(i))
s = "".join(elems)
t1 = time.clock_gettime(time.CLOCK_MONOTONIC)
print(n, t1 - t0, n / (t1 - t0))
------------------------------------------------------------------------
Ergebnis: Performance ist praktisch gleich, aber auf einer
32-Bit-Maschine kommt die Konkatenierungsversion gut 3 mal so weit,
bevor sie am Memory-Limit anstößt.
(Graphik auf <http://www.hjp.at/programming/python/concat-vs-join/>)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
On 2017-09-17 06:19, Stefan Behnel <python-de(a)behnel.de> wrote:
> Peter J. Holzer schrieb am 16.09.2017 um 22:46:
>> Gerade bei langen Listen sollte man darauf verzichten, sie
>> aufzubauen, wenn man sie nicht unbedingt braucht
>
> Natürlich. Einzig darauf zielt dein Beispielcode ja auch ab.
>
> Gilt übrigens genauso für lange Strings.
Natürlich. Wenn man den langen String nie braucht, soll man ihn auch
nicht aufbauen. Gerade, wenn der String an einen Konsumenten geschickt
werden soll, der ihn dann gleich wieder parst, hat man auch noch den
Vorteil, dass Produzent und Konsument sich zeitlich überlappen können,
wenn der Produzent Teile des Outputs so früh wie möglich schickt. Geht
aber leider nicht immer: Manche Protokolle brauchen z.B. eine
Längenangabe im Header und dafür muss man den Output erst mal komplett
haben, um die Länge bestimmen zu können.
>> (habe damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl
>> und nicht Python, aber die beiden Sprachen sind sich da sehr
>> ähnlich)).
>
> Wie du hier korrekt andeutest, handelt es sich bei dem gegebenen Fall um
> eine Optimierung. Optimierung bedeutet ja, dass du eigentlich gut
> geschriebenen Code ersetzt durch etwas, was dem spezifischen Anwendungsfall
> stärker angepasst ist und (nachweislich) unter den erwarteten Bedingungen
> effizienter funktioniert. Mit dem Risiko, dass es unter anderen (eben nicht
> erwarteten) Bedingungen vielleicht auch weniger gut funktioniert.
Richtig. Wobei in diesem Fall allerdings beide Varianten von der
Code-Länge und Lesbarkeit her ziemlich vergleichbar waren. Im Gegensatz
zu manchen anderen Fällen, wo es klar eine "saubere" und eine optimierte
Variante gibt, gab es hier zwei Varianten, die zwar verschiedenen
Ansätzen (eher prozedural und eher funktional) folgten, aber (für meinen
Geschmack) beide gleich sauber waren. Da dann die Variante zu wählen,
die weniger Speicher braucht und schneller ist, ist ein No-Brainer (und
ja, ich habe beide Varianten gebenchmarkt, bevor ich die Änderung
durchgeführt habe).
Bei dem kleinen Test-Programm sehe ich das ähnlich: Die Variante mit
join ist *nicht* klar sauberer. Eher im Gegenteil: Sie baut explizit
eine unnötige Datenstruktur auf, das empfinde ich als unelegant. (Etwas
anderes ist es, wenn die Datenstruktur nur implizit aufgebaut wird: Mit
map statt der explizitien Schleife (was bei diesem Trivialbeispiel
natürlich leicht möglich gewesen wäre) wäre der Code für mich eindeutig
eleganter und damit wäre eine möglich Optimierung nur sinnvoll, wenn die
positiven Effekte zur Laufzeit die negativen Effekte für den
Programmierer überwiegen.)
Aber im wesentlichen ging es mir eben um Deine dogmatisch vorgetragene
Aussage:
| join() ist in jedem Fall die bessere Variante bei vielen Strings.
Das sehe ich eben nicht so. Gerade bei vielen Strings gibt es Fälle, wo
es besser ist, den String stückweise in einer Schleife aufzubauen.
| Konkatenierung ist ok bei einer überschaubaren Menge und da
| insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden
| werden.
Und wie nun ausführlich begründet, sehe ich das genau umgekehrt: Bei
kurzen Strings, die aus wenigek Komponenten zusammengesetzt werden, ist
beides Ok. Bei langen Strings, die aus vielen Komponenten aufgebaut
werden, sollte man sich überlegen, ob nicht eine explizite Schleife
besser ist als ein Join.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Was ist besser?
a b und c enthalten strings.
d=a+b+c besser als
d="{}{}{}".format(a,b,c) ?
Hermann
der hier nicht an Lesbarkeit denkt.
--
http://www.hermann-riemann.de
On 2017-08-31 13:26, Peter Otten <__peter__(a)web.de> wrote:
> Hermann Riemann wrote:
>
>> Allerdings fällt mir bei der Gelegenheit ein,
>> was ist, wenn der Dateiname ein bytestring ist,
>> der sich nicht nach utf konvertieren lässt?
>> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.
>
> Unter Linux kein Problem:
>
>>>> import os
>>>> ord("/")
> 47
>>>> filename = bytes(c for c in range(1, 256) if c != 47)
>>>> filename
> b'\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f
> !"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'
>>>> os.path.exists(filename)
> False
>>>> with open(filename, "w") as f: f.write("yadda\n")
> ...
> 6
>>>> os.path.exists(filename)
> True
>>>> os.listdir()
> ['\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f
> !"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\udc80\udc81\udc82\udc83\udc84\udc85\udc86\udc87\udc88\udc89\udc8a\udc8b\udc8c\udc8d\udc8e\udc8f\udc90\udc91\udc92\udc93\udc94\udc95\udc96\udc97\udc98\udc99\udc9a\udc9b\udc9c\udc9d\udc9e\udc9f\udca0\udca1\udca2\udca3\udca4\udca5\udca6\udca7\udca8\udca9\udcaa\udcab\udcac\udcad\udcae\udcaf\udcb0\udcb1\udcb2\udcb3\udcb4\udcb5\udcb6\udcb7\udcb8\udcb9\udcba\udcbb\udcbc\udcbd\udcbe\udcbf\udcc0\udcc1\udcc2\udcc3\udcc4\udcc5\udcc6\udcc7\udcc8\udcc9\udcca\udccb\udccc\udccd\udcce\udccf\udcd0\udcd1\udcd2\udcd3\udcd4\udcd5\udcd6\udcd7\udcd8\udcd9\udcda\udcdb\udcdc\udcdd\udcde\udcdf\udce0\udce1\udce2\udce3\udce4\udce5\udce6\udce7\udce8\udce9\udcea\udceb\udcec\udced\udcee\udcef\udcf0\udcf1\udcf2\udcf3\udcf4\udcf5\udcf6\udcf7\udcf8\udcf9\udcfa\udcfb\udcfc\udcfd\udcfe\udcff']
>
> Hier sieht man, was mit nicht dekodierbaren Bytes geschieht -- Python
> verwendet den surrogate-escape error handler:
>
>>>> b"\xf1\xf2\xf3".decode("utf-8", "surrogateescape")
> '\udcf1\udcf2\udcf3'
>>>>
>
> Die Shell kann da nicht mithalten:
>
> [2]+ Angehalten python3
> $ ls
> ???????????????????????????????
> !"#$%&'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
Die Shell ist da gar nicht beteiligt. Die ruft ja nur "ls" auf. Der
Output, den Du da zitierst, stammt von ls, und das ersetzt per default
in der Ausgabe nicht-druckbare Zeichen durch "?" (das ist ein Feature -
man will in einem Terminal nicht, das ls irgendwelche Escape-Codes
ausgeben kann, nur weil der Ersteller eines Files lustig war). Es gibt
Optionen, um die Ausgabe zu ändern, z.B. auf (oktale) Escape-Codes:
% ls -b
\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\ !"#$%&'()*+,-.0123456789:;<\=\>?\@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{\|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377
Die Shell (zumindest die zsh, und ich nehme an, die bash auch nicht),
hat kein Problem mit solchen Filenamen:
% rm $'\001'$'\002'$'\003'$'\004'$'\005'$'\006'$'\a'$'\b'$'\t'$'\n'$'\v'$'\f'$'\r'$'\016'$'\017'$'\020'$'\021'$'\022'$'\023'$'\024'$'\025'$'\026'$'\027'$'\030'$'\031'$'\032'$'\033'$'\034'$'\035'$'\036'$'\037'\ \!\"\#\$%\&\'\(\)\*+,-.0123456789:\;\<=\>\?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\[\\\]\^_\`abcdefghijklmnopqrstuvwxyz\{\|\}\~$'\177'$'\200'$'\201'$'\202'$'\203'$'\204'$'\205'$'\206'$'\207'$'\210'$'\211'$'\212'$'\213'$'\214'$'\215'$'\216'$'\217'$'\220'$'\221'$'\222'$'\223'$'\224'$'\225'$'\226'$'\227'$'\230'$'\231'$'\232'$'\233'$'\234'$'\235'$'\236'$'\237'$'\240'$'\241'$'\242'$'\243'$'\244'$'\245'$'\246'$'\247'$'\250'$'\251'$'\252'$'\253'$'\254'$'\255'$'\256'$'\257'$'\260'$'\261'$'\262'$'\263'$'\264'$'\265'$'\266'$'\267'$'\270'$'\271'$'\272'$'\273'$'\274'$'\275'$'\276'$'\277'$'\300'$'\301'$'\302'$'\303'$'\304'$'\305'$'\306'$'\307'$'\310'$'\311'$'\312'$'\313'$'\314'$'\315'$'\316'$'\317'$'\320'$'\321'$'\322'$'\323'$'\324'$'\325'$'\326'$'\327'$'\330'$'\331'$'\332'$'\333'$'\334'$'\335'$'\336'$'\337'$'\340'$'\341'$'\342'$'\343'$'\344'$'\345'$'\346'$'\347'$'\350'$'\351'$'\352'$'\353'$'\354'$'\355'$'\356'$'\357'$'\360'$'\361'$'\362'$'\363'$'\364'$'\365'$'\366'$'\367'$'\370'$'\371'$'\372'$'\373'$'\374'$'\375'$'\376'$'\377'
(ich habe da einfach rm<space><tab> getippt, und die Expansion des
Namens, den ich nicht tippen will, der Shell überlassen)
Und weg is:
% ls
%
> Unter Windows sind die Regeln wohl etwas komplexer.
Ja. Einerseits, weil es mehr reservierte Zeichen gibt, die entweder gar
nicht oder nur an bestimmten Stellen vorkommen dürfen. Andererseits,
weil Filenamen in NTFS keine Byte-Strings sind, sondern UTF-16-Strings.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel