FYI: kein Video Overlay Support auf modernen Nvidia Chips.
Für alle die es interessiert, und weil es z.B. für xawtv Anwender die Hardware Scaling haben möchten eine Rolle spielt: mindestens auf dem 6600 Nvidia Grafik Chip, vermutlich aber auch auf allen neueren gibt es keinen Xvideo Overlay Support mehr wie auf früheren Geforce Chips. Auf dem 6800er soll es aber noch gehen, da das eine ältere Architektur ist (NV40 vs. NV41 beim 6600). Siehe dazu auch die Diskussionen hier http://www.nvnews.net/vbulletin/showthread.php?p=665114 http://www.nvnews.net/vbulletin/showthread.php?t=54336 http://www.nvnews.net/vbulletin/showthread.php?t=43619 D.h. Anwender die Hardware Skalierung (oder sogenannte YUV Acceleration) haben möchten werden sie auf diesen Chips nicht finden. Erkennbar ist das u.a. an den Xvideo ports die xvinfo listet. Auf meiner Ti4600 waren das z.B. Xvideo: video4linux: input video, ports 139-139 Xvideo: NV17 Video Overlay: input image, ports 140-140 Xvideo: NV17 Video Texture: input image, ports 141-141 Xvideo: NV05 Video Blitter: input image, ports 142-173 Xvideo: NVIDIA Video Interface Port: input video, ports 174-174 und auf dem 6600GT sind es nur noch Xvideo: video4linux: input video, ports 270-270 Xvideo: NV17 Video Texture: input image, ports 271-271 Xvideo: NV05 Video Blitter: input image, ports 272-303 Insbesondere ist der Video Overlay Port weggefallen. Auch findet sich im XFree86.0.log folgende Zeile nicht mehr (II) NVIDIA(0): v4l[/dev/video0]: using hw video scaling [YUY2] Wer also z.B. xawtv ohne schwarze Ränder im Xvideo Modus haben will sollte daher von neuen Nvidia Karten absehen. Gruss, Bruno. ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: xawtv im Vollbild ohne schwarze Ränder?
Alexander Fieroch [EMAIL PROTECTED] writes: Weitergebracht hat mich das leider noch nicht. Irgendwelche Ideen, was ich machen kann? Offen gestanden, ich bin mit meinem Latein jetzt auch am Ende. Ich würde an deiner Stelle nun auf die video4linux Liste gehen https://www.redhat.com/mailman/listinfo/video4linux-list wie vom xawtv Autoren auf seiner Seite http://linux.bytesex.org/xawtv empfohlen. Sorry daß wir mit dem Problem hier nicht durchgekommen sind. Gruss, Bruno.
Re: Asterisk Paket Installation
Zlatko Medibach [EMAIL PROTECTED] writes: Hallo Christian, Ich bin bestimmt in der falschen Mailing-Liste. Ich habe Probleme mit der Installation der Debian Pakete für Asterisk (Module werden reihenweise nicht geladen). Kann mir jemand eine gute Mailingliste hierzu nennen? die Mailinglists für Asterisk findest Du unter http://www.asterisk.org/index.php?menu=support#forums Das Problem ist dass Dein e-mail Inbox schnell überfüllt sein wird :-) (hunderte, vielleicht tausende e-mails pro Tag). Warum installierst Du nicht die aktuelle Version von Digium-ftp Server ? ftp://ftp.digium.com/pub Die aktuelle Version ist 1.07. Ich habe mehrere Asterisk Server unter anderem auch unter Debian Sarge die problemlos laufen. Es gab keinerlei Installationsprobleme ... Es wäre vielleicht schon nicht schlecht wenn er sagte was schief läuft, und man das dann mit dem Package Maintainer abklärt. Wozu haben wir asterisk debs wenn sie nicht funktionieren? Gruss, Bruno.
Re: Vor/Nachteile folgender NNTP Clients
Andreas Pakulat [EMAIL PROTECTED] writes: (BTW: Das kann mit UTf-8 oder?) Logisch. Auf Mail/News Ebene und beim Display ebenso wie beim Umgang mit Dateien. Oder mit anderen Worten, hier die Liste der bei mir unterstützten Enkodierungen: ### # List of coding systems in the following format: # MNEMONIC-LETTER -- CODING-SYSTEM-NAME # DOC-STRING 1 -- iso-latin-1 (alias: iso-8859-1 latin-1) ISO 2022 based 8-bit encoding for Latin-1 (MIME:ISO-8859-1). B -- chinese-big5 (alias: big5 cn-big5 cp950) BIG5 8-bit encoding for Chinese (MIME:Big5). J -- iso-2022-jp (alias: junet) ISO 2022 based 7bit encoding for Japanese (MIME:ISO-2022-JP). S -- japanese-shift-jis (alias: shift_jis sjis cp932) Shift-JIS 8-bit encoding for Japanese (MIME:SHIFT_JIS). u -- mule-utf-8 (alias: utf-8) UTF-8 encoding for Emacs-supported Unicode characters. 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) ISO 2022 based 8-bit encoding for Latin-9 (MIME:ISO-8859-15). 2 -- iso-latin-2 (alias: iso-8859-2 latin-2) ISO 2022 based 8-bit encoding for Latin-2 (MIME:ISO-8859-2). 3 -- iso-latin-3 (alias: iso-8859-3 latin-3) ISO 2022 based 8-bit encoding for Latin-3 (MIME:ISO-8859-3). 4 -- iso-latin-4 (alias: iso-8859-4 latin-4) ISO 2022 based 8-bit encoding for Latin-4 (MIME:ISO-8859-4). 5 -- cyrillic-iso-8bit (alias: iso-8859-5) ISO 2022 based 8-bit encoding for Cyrillic script (MIME:ISO-8859-5). 7 -- greek-iso-8bit (alias: iso-8859-7) ISO 2022 based 8-bit encoding for Greek (MIME:ISO-8859-7). 8 -- hebrew-iso-8bit (alias: iso-8859-8 iso-8859-8-e iso-8859-8-i) ISO 2022 based 8-bit encoding for Hebrew (MIME:ISO-8859-8). 9 -- iso-latin-5 (alias: iso-8859-9 latin-5) ISO 2022 based 8-bit encoding for Latin-5 (MIME:ISO-8859-9). c -- chinese-iso-8bit (alias: cn-gb-2312 euc-china euc-cn cn-gb gb2312 cp936) ISO 2022 based EUC encoding for Chinese GB2312 (MIME:GB2312). E -- japanese-iso-8bit (alias: euc-japan-1990 euc-japan euc-jp) ISO 2022 based EUC encoding for Japanese (MIME:EUC-JP). K -- korean-iso-8bit (alias: euc-kr euc-korea cp949) ISO 2022 based EUC encoding for Korean KSC5601 (MIME:EUC-KR). T -- thai-tis620 (alias: th-tis620 tis620 tis-620) 8-bit encoding for ASCII (MSB=0) and Thai TIS620 (MSB=1). W -- iso-latin-8 (alias: iso-8859-14 latin-8) ISO 2022 based 8-bit encoding for Latin-8 (MIME:ISO-8859-14). * -- windows-1252 windows-1252 encoding b -- windows-1251 (alias: cp1251) windows-1251 encoding M -- mac-roman Mac Roman Encoding (MIME:MACINTOSH). R -- cyrillic-koi8 (alias: koi8-r koi8 cp878) KOI8-R 8-bit encoding for Cyrillic (MIME: KOI8-R). U -- koi8-u KOI8-U 8-bit encoding for Cyrillic (MIME: KOI8-U) V -- vietnamese-viscii (alias: viscii) 8-bit encoding for Vietnamese VISCII 1.1 (MIME:VISCII) z -- chinese-hz (alias: hz-gb-2312 hz) Hz/ZW 7-bit encoding for Chinese GB2312 (MIME:HZ-GB-2312). C -- iso-2022-cn-ext ISO 2022 based 7bit encoding for Chinese GB and CNS (MIME:ISO-2022-CN-EXT). C -- iso-2022-cn (alias: chinese-iso-7bit) ISO 2022 based 7bit encoding for Chinese GB and CNS (MIME:ISO-2022-CN). J -- iso-2022-jp-2 ISO 2022 based 7bit encoding for CJK, Latin-1, and Greek (MIME:ISO-2022-JP-2). k -- iso-2022-kr (alias: korean-iso-7bit-lock) ISO 2022 based 7-bit encoding for Korean KSC5601 (MIME:ISO-2022-KR). u -- mule-utf-16be-with-signature (alias: utf-16be-with-signature mule-utf-16-be utf-16-be) Big endian UTF-16 (with BOM) for Emacs-supported Unicode characters. u -- mule-utf-16le-with-signature (alias: utf-16le-with-signature mule-utf-16-le utf-16-le) Little endian UTF-16 (with BOM) for Emacs-supported Unicode characters. u -- mule-utf-16 (alias: utf-16) UTF-16 (with or without BOM) for Emacs-supported Unicode characters. u -- mule-utf-16be (alias: utf-16be) UTF-16BE encoding for Emacs-supported Unicode characters. u -- mule-utf-16le (alias: utf-16le) UTF-16LE encoding for Emacs-supported Unicode characters. x -- compound-text (alias: x-ctext ctext) Compound text based generic encoding for decoding unknown messages. = -- emacs-mule Emacs internal format used in buffer and string. = -- no-conversion Do no conversion. J -- iso-2022-7bit ISO 2022 based 7-bit encoding using only G0 t -- raw-text Raw text, which means text contains random 8-bit codes. -- iso-2022-7bit-lock (alias: iso-2022-int-1) ISO-2022 coding system using Locking-Shift for 96-charset @ -- iso-2022-8bit-ss2 ISO 2022 based 8-bit encoding using SS2 for 96-charset - -- iso-safe (alias: us-ascii) Encode ASCII asis and encode non-ASCII characters to `?'. D -- in-is13194 (alias: devanagari) 8-bit encoding for ASCII (MSB=0) and IS13194-Devanagari (MSB=1). L -- lao 8-bit encoding for ASCII (MSB=0) and LAO (MSB=1). Q -- tibetan-iso-8bit (alias: tibetan) 8-bit encoding for ASCII (MSB=0) and TIBETAN (MSB=1). - -- undecided No conversion on encoding, automatic conversion on decoding A -- cyrillic-alternativnyj (alias: alternativnyj)
Re: xawtv im Vollbild ohne schwarze Ränder?
Alexander Fieroch [EMAIL PROTECTED] writes: Bruno Hertz wrote: Versuch es mal mit abgeschalteten DRI (XF86Config). Wenn das nichts hilft seh' ich auch keine anderen Möglichkeiten mehr. Hm, leider funktioniert auch das nicht. :-( Dann sieht's mittlerweile so aus als ob du kein Hardware Scaling hast. Hast du dich hierüber mal informiert (Karte, Treiber)? Wenn du magst kann ich dann auch nochmal eine Debug Ausgabe von mir posten, zum Vergleich für dich. Das kannst du gerne mal machen. OK, unten mal mein Debug Output. Nach dem Start mach ich zwei Sachen: (i) Fenster maximieren, unmaximieren Das sind die Zeilen Xvideo: video: win=0x2a00065, src=768x576+0+0 dst=384x288+0+0 Xvideo: video: win=0x2a00065, src=768x576+0+0 dst=1529x1147+195+0 ... Xvideo: video: win=0x2a00065, src=768x576+0+0 dst=1529x1147+195+0 Xvideo: video: win=0x2a00065, src=768x576+0+0 dst=384x288+0+0 Hierbei skaliert bei mir das Bild mit (Geforce Ti 4600 mit NVidia Treiber). (ii) xawtv 'fullscreen' per 'f' Taste und zurück Hierbei geht das Bild sogar über die Bildschirmgrenzen hinaus, da Xvideo den 'mode switch' nicht mitmacht. Letztrer ist ja auch nur für v4l gedacht, wo das Bild eben nicht skaliert sondern feste Dimensionen hat, an die man den X Mode entsprechend anpasst. Der 'fit' ist dabei natürlich nicht perfekt, wegen der unterschiedlichen Proportionen. Mit Xvideo benutze ich daher kein Fullscreen sondern Window Maximierung. Habe das aber der Vollständigkeit halber aber hier mit aufgeführt. Wenn du übrigens mit deim reinen v4l/v4l2 Fullscreen Mode auch dicke schwarze Ränder hast die das Bild aus dem sichtbaren Bereich rausdrücken, ist das vermutlich ein Problem des Window Managers. Bin mir aber nicht sicher. Das müßte man dann weiter untersuchen und evtl. den xawtv Author befragen. Gruss, Bruno. This is xawtv-3.94, running on Linux/i686 (2.6.8-2-686) visual: id=0x21 class=4 (TrueColor), depth=24 visual: id=0x22 class=5 (DirectColor), depth=24 visual: id=0x23 class=4 (TrueColor), depth=24 visual: id=0x24 class=4 (TrueColor), depth=24 visual: id=0x25 class=4 (TrueColor), depth=24 visual: id=0x26 class=4 (TrueColor), depth=24 visual: id=0x27 class=4 (TrueColor), depth=24 visual: id=0x28 class=4 (TrueColor), depth=24 visual: id=0x29 class=4 (TrueColor), depth=24 visual: id=0x2a class=4 (TrueColor), depth=24 visual: id=0x2b class=4 (TrueColor), depth=24 visual: id=0x2c class=4 (TrueColor), depth=24 visual: id=0x2d class=4 (TrueColor), depth=24 visual: id=0x2e class=4 (TrueColor), depth=24 visual: id=0x2f class=4 (TrueColor), depth=24 visual: id=0x30 class=4 (TrueColor), depth=24 visual: id=0x31 class=4 (TrueColor), depth=24 visual: id=0x32 class=4 (TrueColor), depth=24 visual: id=0x33 class=4 (TrueColor), depth=24 visual: id=0x34 class=4 (TrueColor), depth=24 visual: id=0x35 class=4 (TrueColor), depth=24 visual: id=0x36 class=5 (DirectColor), depth=24 visual: id=0x37 class=5 (DirectColor), depth=24 visual: id=0x38 class=5 (DirectColor), depth=24 visual: id=0x39 class=5 (DirectColor), depth=24 visual: id=0x3a class=5 (DirectColor), depth=24 visual: id=0x3b class=5 (DirectColor), depth=24 visual: id=0x3c class=5 (DirectColor), depth=24 visual: id=0x3d class=5 (DirectColor), depth=24 visual: id=0x3e class=5 (DirectColor), depth=24 visual: id=0x3f class=5 (DirectColor), depth=24 visual: id=0x40 class=5 (DirectColor), depth=24 visual: id=0x41 class=5 (DirectColor), depth=24 visual: id=0x42 class=5 (DirectColor), depth=24 visual: id=0x43 class=5 (DirectColor), depth=24 visual: id=0x44 class=5 (DirectColor), depth=24 visual: id=0x45 class=5 (DirectColor), depth=24 visual: id=0x46 class=5 (DirectColor), depth=24 visual: id=0x47 class=5 (DirectColor), depth=24 visual: id=0x48 class=5 (DirectColor), depth=24 x11: color depth: 24 bits, 3 bytes - pixmap: 4 bytes x11: color masks: red=0x00ff green=0xff00 blue=0x00ff x11: server byte order: little endian x11: client byte order: little endian check if the X-Server is local ... * ok (unix socket) main: dga extention... DGA version 2.0 main: xinerama extention... main: xvideo extention [video]... Xvideo: 5 adaptors available. Xvideo: video4linux: input video, ports 139-139 Xvideo: NV17 Video Overlay: input image, ports 140-140 Xvideo: NV17 Video Texture: input image, ports 141-141 Xvideo: NV05 Video Blitter: input image, ports 142-173 Xvideo: NVIDIA Video Interface Port: input video, ports 174-174 Xvideo: using port 139 for video XV_ENCODING get set, -1000 - 1000 XV_BRIGHTNESS get set, -1000 - 1000 XV_CONTRAST get set, -1000 - 1000 XV_SATURATION get set, -1000 - 1000 XV_HUE get set, -1000 - 1000 XV_VOLUME get set, -1000 - 1000 XV_MUTE get set, 0 - 1 XV_FREQ get set, 0 - 16000 XV_COLORKEY get set, 0 - 16777215 XV_AUTOPAINT_COLORKEY get set, 0 - 1 XV_SET_DEFAULTS set, 0 - 0 XV_ITURBT_709 get set, 0 - 1 main: xvideo extention [image]... blit: xv: 0x32595559 (YUY2) packed [ok: 16 bit YUV 4:2:2 (packed, YUYV)] blit: xv: 0x32315659 (YV12
Re: Vor/Nachteile folgender NNTP Clients
Andreas Pakulat [EMAIL PROTECTED] writes: Hi, ich bin momentan auf der Suche nach nem Newsclient fuer mich, da Mutt-NG nur rudimentaere Unterstuetzung hat... Da ich den nur fuer ein paar wenige Newsgroups brauche und auch nur gelegentlich suche ich was kleines leicht bedienbares Folgende hab ich jetzt im engeren Auswahlfeld: knode - zieht mir die kdepim Abhaengigkeit mit, nur wenns keinen besseren gibt pan - kenne ich nicht slrn - ist text-Only, also wohl relativ klein, aber wie ist das mit der Bennutzerfuehrung? (ich nutze mutt, also wenns dem aehnlich ist waere es mein Favorit) knews - bin ich skeptisch, da reines X11-App und ich bin da nur schlechte UI gewohnt (dann lieber GTK2...) tin - ?? Bevor ich mir die nun alle installiere und ausprobiere, wollte ich mal rundfragen: Was benutzt ihr so? Gibts wichtige Gruende die gegen oder fuer eine der o.g. Programme sprechen? Gibts evtl. noch einen viel tolleren NNTP-Client? Gnus. Der beste wo gibt :) Gruss, Bruno. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Vor/Nachteile folgender NNTP Clients
Andreas Pakulat [EMAIL PROTECTED] writes: Hmm, der kann aber wohl auch nur mit einem Server umgehen oder? Apropos leid tun (in Bezugnahme auf deine Antwort auf mein anderes Posting). Mit Gnus lese ich * News von 3 News Servern, insgesamt 33 Gruppen * Mail von 3 Accounts auf 2 IMAP Servern, organisiert in 68 Ordnern * RSS Feeds von 8 Servern (e.g. Slashdot) * und lokale Mail mit jeweils verschiedenen Accounts und 4 davon völlig unabhängigen Aliases als Absender Adressen. Das ganze in einem einheitlichen, total bequemen und voll konfigurierbaren Interface. Nur damit du weißt warum es dir leid tut. Gruss, Bruno.
Re: xawtv im Vollbild ohne schwarze Ränder?
Alexander Fieroch [EMAIL PROTECTED] writes: Bruno Hertz wrote: Probier mal 'xawtv -hwscan' . Bei mir gibt das (u.A.) /dev/video0: OK [ -device /dev/video0 ] type : v4l2 name : BT878 video (Hauppauge (bt878)) flags: overlay capture tuner und damit funktioniert dann auch scaling. D.h. maximieren des Fensters skaliert das Bild entsprechend hoch, und die eigentliche 'fullscreen' Funktion wird damit redundant. Hm, bei mir geht das dennoch nicht. 'xawtv -hwscan' zeigt an, dass v4l2 geladen wurde und der overlay modus unterstützt wird. $ xawtv -hwscan xscreensaver-command: exiting. This is xawtv-3.94, running on Linux/i686 (2.6.11.7) looking for available devices port 356-356[ -xvport 356 ] type : Xvideo, video overlay name : video4linux port 357-357 type : Xvideo, image scaler name : NV17 Video Texture port 358-389 type : Xvideo, image scaler name : NV05 Video Blitter /dev/video0: OK [ -device /dev/video0 ] type : v4l2 name : BT878 video (Hauppauge (bt878)) flags: overlay capture tuner Der explizite Aufruf für Nutzung der Xvideo extension wäre 'xawtv -xv', aber er sollte sie auch ohne Parameter schon per default nutzen. Auch das geht leider nicht. Hier der Output mit verbose 1: ~$ xawtv -v 1 -xv -c /dev/video0 Natürlich geht es nicht, weil du die Option '-xv' mit der Angabe '-c /dev/video0' gleich wieder deaktivierst. Man page: -c, -device device set video4linux device (default is /dev/video0). This option also disables Xvideo support. Man bemerke den letzten Satz. Also nochmal, mit deinen obigen Angaben (i) mit Xvideo 'xawtv -xv' oder äquivalent 'xawtv -xvport 356' (ii) mit v4l (d.h. ohne Xvideo) 'xawtv -c /dev/video0' Variante (i) sollte skalieren. Gruss, Bruno. PS: Bitte kein CC Mail an mich.
Re: xawtv im Vollbild ohne schwarze Ränder?
Alexander Fieroch [EMAIL PROTECTED] writes: Bruno Hertz wrote: Natürlich geht es nicht, weil du die Option '-xv' mit der Angabe '-c /dev/video0' gleich wieder deaktivierst. Man page: -c, -device device set video4linux device (default is /dev/video0). This option also disables Xvideo support. Man bemerke den letzten Satz. Also nochmal, mit deinen obigen Angaben Oh, das habe ich überlesen. (i) mit Xvideo 'xawtv -xv' oder äquivalent 'xawtv -xvport 356' (ii) mit v4l (d.h. ohne Xvideo) 'xawtv -c /dev/video0' Variante (i) sollte skalieren. Allerdings hatte ich es auch einzeln ausprobiert (gerade nochmal überprüft) und ebenfalls keine Skalierung. :-( Kann man den Grund in der folgenden Verbose Ausgabe finden? Hmm, vielleicht. Der einzige auffällige Unterschied zu meiner Ausgabe ist die Verwendung von DRI bei dir. Soweit ich weiss versucht xawtv damit zu skalieren, falls es DRI support erkennt, und das mag dann bei dir nicht funktionieren. Versuch es mal mit abgeschalteten DRI (XF86Config). Wenn das nichts hilft seh' ich auch keine anderen Möglichkeiten mehr. Wenn du magst kann ich dann auch nochmal eine Debug Ausgabe von mir posten, zum Vergleich für dich. Gruss, Bruno.
Re: gcc und 32bit grenze
Michael Ott [EMAIL PROTECTED] writes:
Hallo Ihr!
Ich lese gerade mittels socket eine Struct, das sich nicht an die
32bit-Grenze nicht hält.
Ich habe folgendes Strukt:
struct {
char[10];
int;
}
und genau das bekomme ich über das Netz, nur das er mir wirklich 10bit
und danach die Zahl bringt,
10 Byte wahrscheinlich. Und wo ist das Problem? Du sagst es wird alles
übertragen, erst 10 und dann nochmal 4 Byte. Da sehe ich weit und
breit kein Problem, und wenn da eines wäre hat es mit einer wie immer
gearteten 32bit Grenze vermutlich gar nichts zu tun.
Weisst du nicht wie du die 14 Byte korrekt lesen sollst, oder wo
hapert es? Mit etwas Quellcode ließe sich nebenbei vielleicht mehr
sagen.
Gruss, Bruno.
Re: gcc und 32bit grenze
Michael Ott [EMAIL PROTECTED] writes:
Hallo Bruno!
Ich lese gerade mittels socket eine Struct, das sich nicht an die
32bit-Grenze nicht hält.
Ich habe folgendes Strukt:
struct {
char[10];
int;
}
und genau das bekomme ich über das Netz, nur das er mir wirklich 10bit
und danach die Zahl bringt,
10 Byte wahrscheinlich. Und wo ist das Problem? Du sagst es wird alles
übertragen, erst 10 und dann nochmal 4 Byte. Da sehe ich weit und
breit kein Problem, und wenn da eines wäre hat es mit einer wie immer
gearteten 32bit Grenze vermutlich gar nichts zu tun.
Weisst du nicht wie du die 14 Byte korrekt lesen sollst, oder wo
hapert es? Mit etwas Quellcode ließe sich nebenbei vielleicht mehr
sagen.
gcc schreibt aber intern das int nicht gleich hinter die chars, sondern
fängt an der nächsten 32bit-Grenze an. Und dabei liegt das Problem. Die
Daten aus dem Socket sind aber hintereinander weg geschrieben.
Ich habe mir die Speicheraddressen ausgegeben und da fängt das int vom
Socket zwei Bytes vor dem dem int aus der Struktur an.
Ich habe dabei die Bytes mir einzeln ausgelesen
Ah, OK. Du deklarierst ein analoges struct auf der receiver Seite und
da passt es nicht mehr. Das Schlagwort hier heißt 'struct padding'.
Zwei Alternativen:
struct {
char[10];
int;
} __atribute__((packed));
oder du stellst das int einfach an den Anfang, natürlich auf sender
und receiver Seite
struct {
int;
char[10];
}
Generell, und insbesondere wenn binäre Daten über's Netzwerk gehen
sollen, empfiehlt es sich in structs die 'dicken Teile' an den Anfang
zu stellen, d.h. zumindest die Teile, die auf alignment boundaries
fallen.
Gruss, Bruno.
Re: xawtv im Vollbild ohne schwarze Ränder?
Alexander Fieroch [EMAIL PROTECTED] writes: Kiro Zimmer wrote: Hallo Alexander, hier mal die relevanten Teile meiner .xawtv wichtig ist der fullscreen-Parmeter ;) Ne, das hatte ich auch und klappt bei mir nicht. xawtv wechselt beim Vollbild zur Auflösung 1024x768 im virtuellen Screen. D.h. ich kann in dem Ausschnitt innerhalb meiner ursprünglichen Größe von 1280x1024 umherscrollen. xawtv bleibt jedoch in der standard-Auflösung von 768x576 mit schwarzen Rändern. [global] freqtab = europe-west ratio = 4:3 #use-wm-fullscreen = no fullscreen = 1024x768 [defaults] input = Television capture = overlay norm = PAL Probier mal 'xawtv -hwscan' . Bei mir gibt das (u.A.) /dev/video0: OK [ -device /dev/video0 ] type : v4l2 name : BT878 video (Hauppauge (bt878)) flags: overlay capture tuner und damit funktioniert dann auch scaling. D.h. maximieren des Fensters skaliert das Bild entsprechend hoch, und die eigentliche 'fullscreen' Funktion wird damit redundant. Der explizite Aufruf für Nutzung der Xvideo extension wäre 'xawtv -xv', aber er sollte sie auch ohne Parameter schon per default nutzen. Gruss, Bruno.
Re: xawtv im Vollbild ohne schwarze Ränder?
Steffen Hey [EMAIL PROTECTED] writes: Hallo, kann jemand die Unterschiede erklären? xawtv -hwscan This is xawtv-3.94, running on Linux/i686 (2.4.18-bf2.4) looking for available devices port 69-69 [ -xvport 69 ] type : Xvideo, video overlay name : video4linux port 70-70 type : Xvideo, image scaler name : Matrox G-Series Backend Scaler /dev/video0: OK [ -device /dev/video0 ] type : v4l name : BT878(Hauppauge (bt878)) flags: overlay capture tuner Wie der Name sagt, das sind die 'devices', die xawtv erkennt. Die ersten zwei werden von der Xvideo Extension bereit gestellt, das letzte von v4l. In den eckigen Klammern siehts du die Optionen, die du xawtv für den Zugriff auf das jeweilige Device mitgeben kannst. I.e. xawtv -xvport 69 xawtv -device /dev/video0 Die erste Variante sollte dir Scaling geben und eigentlich der Default sein, schon beim einfachen Aufruf 'xawtv', mindestens aber beim Aufruf 'xawtv -xv'. Ich vemute übrigens mal, daß du einen 2.4 Kernel hast, da nur v4l und kein v4l2 ... Gruss, Bruno.
Re: xawtv im Vollbild ohne schwarze Ränder?
[EMAIL PROTECTED] (Walter Saner) writes: Bruno Hertz schrieb: Steffen Hey [EMAIL PROTECTED] writes: This is xawtv-3.94, running on Linux/i686 (2.4.18-bf2.4) [...] Ich vemute übrigens mal, daß du einen 2.4 Kernel hast, da nur v4l und kein v4l2 ... Ein Wildschwein für den Seher! Muss ich mir denn immer alles durchlesen? :) Gruss, Bruno.
mount / mit noatime.
Macht das jemand? Wenn ja, gibt es Probleme, Fallstricke? Ich möchte gerne die nervigen 5 sekündigen Commits auf meiner ext3 / Partition auf echte write requests reduzieren. Mount mit noatime soll da helfen, bin mir aber nicht sicher ob irgendein Systemdienst auf vernünftige access times angwiesen ist (Sarge/2.6). Danke für Hinweise, Bruno.
Re: mount / mit noatime.
Richard Mittendorfer [EMAIL PROTECTED] writes: um den commit einzustellen gibt's AFAIK die mountoption commit=seconds Partition auf echte write requests reduzieren. Mount mit noatime soll da helfen, bin mir aber nicht sicher ob irgendein Systemdienst auf vernünftige access times angwiesen ist (Sarge/2.6). nix probelm. noatime bestimmt aber eher die menge der daten die geschrieben werden muessen. ich empfehle bdflush (2.4.) bzw. dirty_expire_centisecs und dirty_writeback_centisecs (2.6) zu tunen und commit= hoeher zu setzen. Danke erstmal, es ist wie gesagt ein 2.6er Kernel. Eigentlich wollte ich das commit Intervall nicht höher setzen. Meine These war eher, daß selbst wenn keine echten Schreibanfragen vorliegen trotzdem Inode Access Times laufend upgedated werden und ich daher dauernd Flushes sehe. Mit noatime hoffte ich das unterbinden zu können. Scheint aber nicht zu stimmen. Ich habe einen remount noatime gemacht, und kjournald rödelt trotzdem munter weiter. Versuche, 'echte' Schreibzugriffe zu lokalisieren haben auch nichts gebracht. Per lsof habe ich mir alle offenen Dateien angesehen, hauptsächlich syslogd Log Dateien wie sich rausstellte, aber da rührt sich schreibmäßig nicht viel. Kann natürlich noch immmer sein, daß trotzdem ein oder mehrere Prozesse dauernd schreiben, aber die jeweilige Datei nur kurzzeitig öffnen. Sehr undurchsichtig die Sache. Habe auch mal gegoogelt, und insbesondere Laptop Besitzer scheinen unter dem Thema zu leiden, von wegen APM und HD spin down. Kam aber trotzdem irgendwie nichts wirklich Nützliches rum. Swapping sollte es eigentlich auch nicht sein, und warum das VM Subsystem dauernd dirty pages auf die Platte schreiben müßte sehe ebenfalls nicht. Naja, sei's drum. Vielen Dank also, Bruno.
Re: mount / mit noatime.
Richard Mittendorfer [EMAIL PROTECTED] writes: IIRC ist das schreiben manchmal vom MM. grossteil aber halt journaling fs. setz das commit mal hoeher, sysctl, und sieh mit einem dstat o.ae. nach. ich hab meinen SOHO (bei mir SOcialHOming) server so recht ruhig gestellt. daten sind dort sowieso auf ide: nfs,samba,apache,mserv werden da gespeisst und die platte haelt automagisch. system ist auf scsi. bei scsi muesst den kernel patchen, fuer squid/mail aber auch nicht moeglich/noetig. Das commit ist wohl tatsächlich der Angelpunkt. Habe mir grad' mal die laptop-mode-tools installiert, und im Wesentlichen ist das nur ein bash Skript. Wenn man da reinschaut, sieht man daß es auch nichts anderes macht als * commit höher setzen (das geht sogar als mount Option, läßt sich also z.B. partitionsweise in fstab reinschreiben) * ein paar VM Parameter tunen (/proc/sys/vm) * hdparm Powersaving (hdparm -B) und Standby (hdparm -S) Parameter setzen. Die ersten zwei Punkte sind also an sich nichts anderes als was du auch meintest, und damit werden die Schreibzugriffe allerding merklich reduziert. Bei einem commit von 10 Minuten allerdings auch nicht verwunderlich :) Das Verlustrisiko bzgl. Daten/Crash wird damit zwar höher, weshalb ich es eben ursprünglich ohne commit Tuning machen wollte, aber anders geht es wohl nicht. Ich denke mal das Thema haben wir damit durch ... Danke nochmal, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-04-22 12:29:39, schrieb Andreas Pakulat: On 22.Apr 2005 - 10:03:43, Heino Tiedemann wrote: Finde ich aber interessant, das Du sowas einfach ausführst. Mich würde ja mal ne Antwort von Gebhard interessieren, ob er das auf seinem Heimrechner wirklich so ausprobiert hat - ich kann mir das beim besten Willen nicht vorstellen Mal sehn, was er sagt, wenn er seine Maschine neu installiert hat. Ihr scheint das irgendwie alle für lustig zu halten. Ich seh' das überhaupt nicht so. Falls er wirklich seine Installation zerschossen hat, wäre nach meinem Empfinden jedenfalls eine Entschuldigung angebracht. Ich weiß, das 'rm -rf /' Späßchen zwar allgemein üblich sind und aus mir unerfindlichen Gründen irgendwie als 'hip' angesehen werden, aber speziell die 'Obfuskation' solchen Mistes auf einer Liste, wo sich eben auch Anfänger einfinden, ist gelinde gesagt eine ziemliche Sauerei. Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Werner Mahr [EMAIL PROTECTED] writes: Am Freitag, 22. April 2005 20:44 schrieb Bruno Hertz: Danke jedenfalls aber für die zusätzliche Subtilität und Verfeinerung der Diskussion. Ich hol' auch gerne noch die Waage raus. Das wird dann leider eine sehr kurze Diskussion, da ich zu den stark untergewichtigen Leute zähle. Mensch. Um das Salz auf der Straße abzuwiegen, meinte ich ... Bei Untergewicht hilft übrigens reichlich Bier, viel und gutes Essen kombiniert mit möglichst wenig Bewegung. Hat bei mir Wunder gewirkt :) Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Martin Dickopp [EMAIL PROTECTED] writes: Bruno Hertz [EMAIL PROTECTED] writes: Ihr scheint das irgendwie alle für lustig zu halten. Ich seh' das überhaupt nicht so. Falls er wirklich seine Installation zerschossen hat, wäre nach meinem Empfinden jedenfalls eine Entschuldigung angebracht. Ich weiß, das 'rm -rf /' Späßchen zwar allgemein üblich sind und aus mir unerfindlichen Gründen irgendwie als 'hip' angesehen werden, aber speziell die 'Obfuskation' solchen Mistes auf einer Liste, wo sich eben auch Anfänger einfinden, ist gelinde gesagt eine ziemliche Sauerei. Das fragliche Kommando stand in einer *Signatur*. Ein Kommando, das ohne Kommentar in einer Signatur steht, einfach auszuführen, und diesem auf Nachfrage auch noch das root-Passwort anzuvertrauen, ist ungefähr das Online-Äquivalent dazu, eine auf der Straße gefundene Packung unbekannter Tabletten aufzuheben und mal auszuprobieren, was passiert, wenn man ein paar der Tabletten schluckt. Lustig finde ich es zwar auch nicht, aber für das Opfer ist es sicher immer noch besser, anhand einer zerschossenen Root-Patition zu lernen, als zum Beispiel anhand eines erfolgreichen Angriffs krimineller Phisher, die auf Kreditkarten-, Online-Banking-Daten oder ähnliches aus sind. Tolle Kommentare. Wenn ihr vor'm Haus eine Grube schaufelt und sie nicht absperrt, dann ein Kind vorbeikommt, reinknallt und sich den Schädel aufschlägt sagt ihr wohl auch: na, haste was gelernt? Nächstes mal besser aufpassen bitte, hahaha. Sorry, aber das hier ist die Debian User Liste. Hier kann der 12jährige, der sich überhaupt zum erstenmal ein System installiert, ebenso vorbeikommen wie der alte Hase. Ersterer weiß evtl. nicht mal was eine Signatur ist, geschweige denn den ganzen Rest. Die 'Entschuldigung' mit der Signatur ist dazu ja wohl völliger Schwachsinn. Was soll denn die wem sagen? Wie toll man ist, weil man einen destruktiven Befehl so schön verschleiern kann? Sieht außerdem aus, als ob sich besagte Person die Signaturen auch noch generieren läßt. Als ob er jede Menge offtopic aber hochwichtige Nachrichten zu kommunizieren hätte, die er unbedingt und überall noch mit reinschmeißen muß. Super. Ne, Leute. Es mag zwar nicht 'hip' sein verantwortlich zu handeln, und manche mögen Listen wie diese als Spielwiese ansehen auf der sie jeden noch so überflüssigen Scheiß treiben können, aber meine Meinung hierzu ist klar. Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Werner Mahr [EMAIL PROTECTED] writes: Am Freitag, 22. April 2005 17:05 schrieb Bruno Hertz: Sorry, aber das hier ist die Debian User Liste. Hier kann der 12jährige, der sich überhaupt zum erstenmal ein System installiert, ebenso vorbeikommen wie der alte Hase. Ersterer weiß evtl. nicht mal was eine Signatur ist, geschweige denn den ganzen Rest. Da gibts nur eine Möglichkeit. Setz einen Bugreport ab, am besten so hoch einstufen das er RC wird. Darin forderst du dann, das MUA's per default keine Signaturen anzeigen sollten, da es User geben könnte, die auch einen destruktiven Befehl der darin steht, ohne zu fragen, aber unter Angabe des root Passwortes, ausführen könnten. Wenn das noch mehr machen, sagen sie am mende auch noch Debian wäre nicht stabil, oder würde nicht vor eigener Dummheit schützen. Wie gesagt, es gibt noch eine andere Möglichkeit: verantwortliches Handeln, und zwar auf allen Seiten. Dann muß man nämlich auch nicht immer nach Autoritäten rufen, die alles regeln (cf. Bug Report). Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Martin Dickopp [EMAIL PROTECTED] writes: Bruno Hertz [EMAIL PROTECTED] writes: Tolle Kommentare. Wenn ihr vor'm Haus eine Grube schaufelt und sie nicht absperrt, dann ein Kind vorbeikommt, reinknallt und sich den Schädel aufschlägt sagt ihr wohl auch: na, haste was gelernt? Nächstes mal besser aufpassen bitte, Wie man das für eine zu dem vorliegenden Fall passende Analogie halten kann, ist mir völlig schleierhaft. Muß dir schleierhaft sein, da du die Lücke in deinem Versuch einer Analogie selbst jetzt noch nicht nicht gesehen hast. Kleine Hilfe: wer die Tabletten aufliest und einfach ißt, macht natürlich einen Fehler. Aber derjenige, der sie bewußt auf die Straße wirft während er um deren Gefährlichkeit weiß, macht auch einen. Oder siehst du das anders? Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Jochen Schulz [EMAIL PROTECTED] writes: * Bruno Hertz: Ihr scheint das irgendwie alle für lustig zu halten. Nicht sonderlich. Ich seh' das überhaupt nicht so. Falls er wirklich seine Installation zerschossen hat, wäre nach meinem Empfinden jedenfalls eine Entschuldigung angebracht. Huh? Sicher muß man sowas nicht unbedingt in seine Signatur packen. Aber genauso sicher ist es wirklich unglaublich riskant, einen unverstandenen Befehl auszuführen und sogar dafür auch noch sein root-Passwort einzugeben. Führe niemals Code aus nicht vertrauenswürdiger Quelle aus ist *die* Grundregel für sicheren Umgang mit Computern. Und was man als Linuxnutzer ebenfalls immer wieder liest: Arbeite nicht als root, wenn es nicht unbedingt sein muß. Gebhard hat beide Regeln ignoriert und die Quittung erhalten. Es tut mir zwar leid, daß er es auf die harte Tour lernen mußte, aber mein Mitleid hält sich ehrlich gesagt in Grenzen. Ich weiß, das 'rm -rf /' Späßchen zwar allgemein üblich sind und aus mir unerfindlichen Gründen irgendwie als 'hip' angesehen werden, aber speziell die 'Obfuskation' solchen Mistes auf einer Liste, wo sich eben auch Anfänger einfinden, ist gelinde gesagt eine ziemliche Sauerei. Sonderlich obfuscated war der Befehl nun nicht. Allein 'su' muß doch alle Alarmglocken schrillen lassen. Außerdem gilt auch hier, in einer zugegeben einigermaßen geschützten Umgebung: versteh was Du tust, oder laß es bleiben. Es hat seinen Grund, daß in vielen hilfreichen Antworten auf manpages verwiesen wird. Genau. Und am Eingang zu dieser Liste steht bitte nur eintreten wenn ihr sowieso schon alles wisst. Natürlich hat Gebhard einen Fehler gemacht. Aber man muß solche Fehler doch nicht völlig überflüssigerweise provozieren. Oder andersrum: nenn' mir einen guten Grund eine solche Signatur unkommentiert in diese Liste zu posten. Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Werner Mahr [EMAIL PROTECTED] writes: Am Freitag, 22. April 2005 19:37 schrieb Bruno Hertz: Kleine Hilfe: wer die Tabletten aufliest und einfach ißt, macht natürlich einen Fehler. Aber derjenige, der sie bewußt auf die Straße wirft während er um deren Gefährlichkeit weiß, macht auch einen. Oder siehst du das anders? Natürlich kann man das anders sehen. Wenn ich ein Pfund Salz auf die Straße werfe, bin ich mir höchsten der Schuld bewusst, wenn du mir Umweltverschmutzung vorwirfst. Wenn aber irgendwein Hirni auf die Idee kommt, das ganze Pfund zu essen, dann kann mir da keiner einen Vorwurf draus machen. Bei Medikamenten ist es meistens so, das erst eine falsche Dosierung den gefährlichen Effekt hervor ruft. Wenn du es drauf anlegst, kannst du auch an Aspirin krepieren. Mir schien, und man möge mich korrigieren, daß die Medizin in unserem Falle doch sehr konzentriert war. Vielleicht sogar die schärfste, die auf diesem Wege verabreicht werden kann. Danke jedenfalls aber für die zusätzliche Subtilität und Verfeinerung der Diskussion. Ich hol' auch gerne noch die Waage raus. Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Martin Dickopp [EMAIL PROTECTED] writes: Ansonsten bin ich der Meinung, daß derjenige, der die Tabletten auf die Straße wirft (egal ob fahrlässig oder absichtlich), nicht damit rechnen muß, daß sie jemand schluckt. Danke für die klare Positionsnahme. Gruss, Bruno.
Re: su -c destroy my system, please
Peter Wiersig [EMAIL PROTECTED] writes: On Fri, Apr 22, 2005 at 02:13:21PM +0200, Bruno Hertz wrote: Ihr scheint das irgendwie alle für lustig zu halten. Ich seh' das überhaupt nicht so. Falls er wirklich seine Installation zerschossen hat, wäre nach meinem Empfinden jedenfalls eine Entschuldigung angebracht. Nein, lustig finde ich das nicht. Ich sehe das auf einer Stufe damit, auf ein Attachment in einer Mail zu klicken und sich an den Wurmepedimien im Internet zu beteiligen. Keine Entschuldigung, nicht einmal Beileid von mir. Sicher, die Zauberformel kam ja auch nicht von dir. Es liesse sich übrigens anmerken, daß in dem Debian Listenkontext hier natürlich ein höherer Vertrauensvorschuß herrschen mag als bei irgendwelchen Mails mit wirren Absendern und dubiosem Inhalt. Aber egal, ich habe meine Meinung gesagt, und eine reine Meinungsäußerung war es ja von Anfang an. Zusammenfassung: * mein Beileid hat er, falls der allerdings tragische Unfall wirklich eingetreten ist * wäre das Teil von mir gekommen, würde ich mir dann schon ziemlich bescheuert vorkommen, und mir für eine Entschuldigung auch nicht zu schade sein; zusätzlich würde ich, wenn ich diese Signatur unbedingt weiter verwenden will, zukünftig mindestens einen Warnhinweis dazuschreiben. So einfach sind die Dinge. Gruss, Bruno.
Re: su -c dd if=/dev/urandom of=`mount |grep 'on / ' |awk '{print $1;}'`
Werner Mahr [EMAIL PROTECTED] writes: Am Freitag, 22. April 2005 22:40 schrieb Bruno Hertz: Bei Untergewicht hilft übrigens reichlich Bier, viel und gutes Essen kombiniert mit möglichst wenig Bewegung. Hat bei mir Wunder gewirkt Bei mir nicht. 2 Schnitzel mit Weizenbier runterspülen, danach ins Bett. Am nächsten morgen kein Gramm mehr. Vielleicht hätte ich mich vorm kacken wiegen sollen. 1,81m 52 KG. Naja. Du weißt, daß das zuwenig ist und unternimmst hoffentlich etwas. Das fällt, scheint mir, ja fast schon in's medizinische Fach. Meine 184/90 sind zwar bereits etwas viel, aber ich kann noch gut damit leben. Das Verhältnis war allerdings nicht immer so, hat erst nach dem Studium angefangen. Im Rückblick finde ich aber, lieber so als anders. Gruss, Bruno.
Re: Gelegentliche Probleme mit mailbox
Ulrich Fürst [EMAIL PROTECTED] writes: Michael Flaig [EMAIL PROTECTED] wrote: Hi, leider ist das ein bekanntes Problem mit mbox. entweder maildir, oder mailbox von procmail mit lock versehen lassen Ergänzung: Ich hatte zwar ein LOCKFILE= festgelegt, aber in den reciepes dann :0: verwendet, was das ganze ja umgeht; vielleicht ist mein Problem damit schon gelöst. Danke auf jeden Fall (für den Denkanstoss) Interessant. Ohne Debian Details zu kennen möchte ich doch darauf hinweisen, daß es verschiedene Lock Mechanismen für Dateien gibt. Zu nennen wären flock, fcntl und dotlocks, wo dotlocks eben mit Lockfiles arbeitet. Diese Mechanismen sind natürlich nicht kompatibel, und es ist eine Frage der Policy, welchen Mechanismus ein System verwendet. Wie Debian's Policy aussieht weiß ich nicht, aber insbesondere wenn du Drittsoftware installiert hast solltest du prüfen ob sie sich daran hält. Es kann eben auch sein, daß dein LOCKFILE eben nicht der Policy entspricht (gleichwohl, 'man lockfile' suggeriert daß Debian tatächlich damit arbeitet - müsste man mal herausfinden). Anzumerken wäre auch, daß die flock/fcntl Mechanismen afaik nicht NFS safe sind. Gruss, Bruno.
Re: Mail-Attachment mit Bash-Script versenden
Al Bogner [EMAIL PROTECTED] writes: Am Dienstag, 19. April 2005 00:08 schrieb Michelle Konzack: Am 2005-04-18 17:26:26, schrieb Al Bogner: PINGERGEBNIS=`ping -c 1 $MAILSV 21` PINGOK=`echo $PINGERGEBNIS | grep 0% packet loss` Bist Du sicher, das dies funktioniert ? Klar, dass das nicht 100% funktioniert, hast du aber eine bessere Lösung abzufragen, ob die Internetverbindung grundsätzlich funktioniert und ob der Mailserver erreichbar ist. Ist das nicht ein typischer Anwendungsfall für netcat? Also z.B. echo QUIT | nc6 --half-close --timeout=5 $MAILSV 25 und dann $? abprüfen. Gruss, Bruno.
Re: Neue Pakete 'bookmarken' ?
Sven Bergner [EMAIL PROTECTED] writes: Frage also: wie merkt man sich diese Pakete? Aptitude hat soweit ich sehe keine Bookmarking Funktion, und ähnlich schicke Alternativen sind jedenfalls mir nicht bekannt. Wie löst ihr das Problem ? Hat da jemand einen Tip? Ich persönlich benutze EmacsWiki um mir strukturiert Informationen zu merken. Das ist natürlich nur was für Leute, die eh Emacs als Editor verwenden. Das EmacsWiki ist aber als Paket bei Debian dabei. Ein einfaches Text-File tut es sicherlich auch. Das ablegen von Informationen in Textdateien hat für mich den Vorteil, dass keine Zettel auf dem Schreibtisch herumliegen, die ich irgendwann nicht zuordnen kann oder die verloren gehen. Zum anderen kann man in solchen Dateien bestens mit Hilfe von z.B. grep suchen. Wenn man dann noch Meta-Informationen in Form von Einrückungen, Klammern oder Aufzählungszeichen (o,-) benutzt sieht das auch noch geordnet aus. OK, aber das ist doch alles noch bei weitem zu umständlich. Natürlich kann ich die Daten aus dem Paketmanagementsystem meiner Wahl abschreiben, irgendwohin kopieren oder auswendig lernen. Der Hintergrund meiner Frage war aber, und ich dachte das war offensichtlich, daß ich in dem Interface in dem ich das Package Management mache und insbesondere auch alle Daten verfügbar habe, wie Dependencies und dergleichen, mir gerne auch Pakete für eine spätere Inspektion 'merken' können möchte. Kaum glaublich, daß das noch keiner vermißt hat. Synaptic kann das anscheinend auch nicht, und sogar auf Kommandozeilenebene (apt etc.) sich auch nur die neuen Pakete listen zu lassen ist wohl auch ein Krampf, falls überhaupt möglich. Könnte ich wenigstens die neuen Pakete inklusive Kurzbeschreibungen bequem in eine Datei 'cat'en wäre wenigstens etwas gewonnen. Wajig kann das vielleicht, habe ich eben per Google gesehen. Aber daß das so ein Krampf ist ... Naja, dann ist es halt mal so. Toll. Danke euch allen jedenfalls, Bruno. PS: Apropos Emacs, da hab' ich mal was von einem apt Mode gelesen. Hast du den mal ausprobiert? Gut? Vielleicht ließe sich wenigstens so alles unter eine Haube bringen ...
Re: Neue Pakete 'bookmarken' ?
Bruno Hertz [EMAIL PROTECTED] writes:
Könnte
ich wenigstens die neuen Pakete inklusive Kurzbeschreibungen bequem in
eine Datei 'cat'en wäre wenigstens etwas gewonnen. Wajig kann das
vielleicht, habe ich eben per Google gesehen. Aber daß das so ein
Krampf ist ...
So zum Beispiel:
aptitude update
cat /var/lib/aptitude/pkgstates |
sed -n '/Package:/ { s/Package: //; h; d; }; /Unseen: yes/ { g; p; }' |
sort |
xargs wajig whatis
Noch immer Müll, aber besser als nix.
Gruss, Bruno.
Re: Neue Pakete 'bookmarken' ?
Bruno Hertz [EMAIL PROTECTED] writes:
Bruno Hertz [EMAIL PROTECTED] writes:
Könnte
ich wenigstens die neuen Pakete inklusive Kurzbeschreibungen bequem in
eine Datei 'cat'en wäre wenigstens etwas gewonnen. Wajig kann das
vielleicht, habe ich eben per Google gesehen. Aber daß das so ein
Krampf ist ...
So zum Beispiel:
aptitude update
cat /var/lib/aptitude/pkgstates |
sed -n '/Package:/ { s/Package: //; h; d; }; /Unseen: yes/ { g; p; }' |
sort |
xargs wajig whatis
Noch immer Müll, aber besser als nix.
Jawoll: aptitude search '~N'
Geht doch. Zwar noch kein Bookmarking, aber wenigstens kommt man
halbwegs bequem an die Daten ran ...
Re: Mail-Attachment mit Bash-Script versenden
Al Bogner [EMAIL PROTECTED] writes: Am Mittwoch, 20. April 2005 09:38 schrieb Bruno Hertz: Al Bogner [EMAIL PROTECTED] writes: Am Dienstag, 19. April 2005 00:08 schrieb Michelle Konzack: Am 2005-04-18 17:26:26, schrieb Al Bogner: PINGERGEBNIS=`ping -c 1 $MAILSV 21` PINGOK=`echo $PINGERGEBNIS | grep 0% packet loss` Bist Du sicher, das dies funktioniert ? Klar, dass das nicht 100% funktioniert, hast du aber eine bessere Lösung abzufragen, ob die Internetverbindung grundsätzlich funktioniert und ob der Mailserver erreichbar ist. Ist das nicht ein typischer Anwendungsfall für netcat? Also z.B. echo QUIT | nc6 --half-close --timeout=5 $MAILSV 25 und dann $? abprüfen. Zumindest müsste man mehr als Port 25 prüfen. Einer der Server, die ich abfrage, verwendet Port 587. Den Schluß mit $? verstehe ich nicht. $? ist der exit Status von netcat (nc6). Dieser ist 0 außer in folgenden Fällen: * kein connect möglich (mit ICMP port unreachable) * kein connect möglich, aber gefiltert (timeout) * connect möglich, aber QUIT kann nicht gesendet werden (half-close) * connect möglich, QUIT kann gesendet werden, aber Server schickt kein EOF (d.h. er hängt). Voila. Anhand des Status läßt somit nicht nur sicherstellen, daß auf dem Port überhaupt ein Service läuft, sondern auch ob er halbwegs vernünftig läuft. Das war doch die Frage, oder? Zu erkennen, ob der Mailserver läuft. Wenn $? also 0 ist, ist er nicht nur erreichbar, er reagiert sogar auf ein QUIT vernünftig. Gruss, Bruno. PS: der Port ist ja wohl hoffentlich nicht das Problem. Server und Ports können immerhin in einer Schleife parametrisiert werden, wenn denn mehrere abzuprüfen sind.
Neue Pakete 'bookmarken' ?
Mal 'ne blöde Frage ... wie wahrscheinlich einige andere auch benutze ich aptitude für Package Maintenance, und da werden ja auch neue Pakete immer hübsch angezeigt. Die Liste neuer Pakete sehe ich mir dann auch i.d.R. durch und denke oft genug 'hallo, das ist aber interessant', möchte das Paket aber nicht gleich installieren, sondern mich später in Ruhe darüber informieren. Frage also: wie merkt man sich diese Pakete? Aptitude hat soweit ich sehe keine Bookmarking Funktion, und ähnlich schicke Alternativen sind jedenfalls mir nicht bekannt. Wie löst ihr das Problem ? Hat da jemand einen Tip? Danke, Bruno.
Re: Mail-Attachment mit Bash-Script versenden
Al Bogner [EMAIL PROTECTED] writes: Es scheint so, dass Debian ein anderes mail/nail verwendet, als SuSE. Mit mail von SuSE konnte man einen Absender definieren, sowie ein Attachment anhängen. In der Debian-manpage von mail finde ich die Optionen nicht, bzw. hat die Option eine andere Bedeutung. Womit bzw. wie versende ich aus einem Bashscript ein Mail mit definiertem Absender und Attachment? Und ergänzend zu den bisherigen Tips noch eine Randnotiz, daß nämlich generell 'mail' i.d.R. kein MIME versteht, und insbesondere nicht mit Attachements umgehen kann. SuSE's Version ist also entschieden aufgebohrt. Ich hatte das Problem mal auf Solaris, wo wir im Rahmen eines Projektes binäre Dateien per Skript versenden sollten. Attachement ging wie gesagt nicht, mit uuencode ging es, aber es wurde dann eben nur die Datei ohne extra Text versendet, und weil keine weitere Software installiert werden durfte aber Perl vorhanden war, haben wir es schließlich mit Perl gemacht. Soviel zum guten, alten 'mail'. Gruss, Bruno.
Re: Authentifizierungsmechanismen für Cyrus / Samba usw.
Udo Mueller [EMAIL PROTECTED] writes: Hallo Stefan, * Stefan Pampel schrieb [18-04-05 15:16]: ich würde mich gerne mal etwas näher über Authentifizierungsmethoden informieren. z.B. Samba, Cyrus, Benutzeraccounts, FTP Server, Squid usw. sollen ja möglichst aus dem _gleichen_ Fundus schöpfen. Aber nachdem ich einiges über PAM, SASL LDAP gelesen habe fehlt mir wieder ein wenig die Richtung. Ein Link zu einem einschlägigen Howto wären sehr wilkommen. Da Samba und LDAP wohl die Schwierigen sind, solltest du damit anfangen. Linux Anmeldung ergibt sich daraus. Postfix arbeitet auch sehr gut mit LDAP zusammen, genauso wie Courier. Wie es mit Cyrus aussieht, weiss ich nicht. Squid geht auch, wenn der LDAP-Inhalt für Samba steht. Gleiches gilt für Apache. Bei allem hilft dir Google suchen: samba ldap pdc Wär' noch zu ergänzen, daß PAM auch LDAP kann. I.e. neben eventuell eigenem LDAP Interfacing, das Applikationen wie Postfix haben, kann generell jede Anwendung die PAM kann damit auch gegen LDAP authentifizieren. Ich habe z.B. hier grade einen Test News Server (innd) aufgesetzt, und der macht genau das: innd - PAM - LDAP. Ich will damit allerdings nicht empfohlen haben auch standard Logins gegen LDAP laufen zu lassen. Passwd/shadow ist da doch robuster :) Gruss, Bruno.
Re: ntp.org verstorben ?
Michelle Konzack [EMAIL PROTECTED] writes: Hallo, nachdem ich unbekannte Probleme mit meinem DCF-77 Empfänger habe (nichts geht mehr, kein funksignal, auch meine beiden Uhren gehen falsch) habe ich für mein Netzwerk einen NTP-Server eingerichtet und de.pool.ntp.org verwendet. nun muß ich feststellen, das die Domain nicht mehr existiert... Kann mir jemand sagen, was passiert ist ? ich habe jetzt aber noch http://www.ntp.net/ gefunden, die aber ne eigenartige Webseite haben. Kann mir jemand einen NTP-Server in Deutschland oder Frankreich sagen, der permanent erreichbar ist ? Ich habe eine Liste von 18 Stück, nur die meisten existieren nicht mehr und die existieren befinden sich in den USA, die ich nicht verwenden will. http://ntp.isc.org/bin/view/Servers/StratumTwoTimeServers (lädt etwas langsam) Ich selbst benutze chronos.zedat.fu-berlin.de Ansonsten nach 'stratum 2 servers' o.Ä. googlen. Gruss, Bruno.
Re: ntp.org verstorben ?
Kiro Zimmer [EMAIL PROTECTED] writes: Am Sonntag, 17. April 2005 15:02 schrieb Michelle Konzack: Hallo, Hallo Michelle, Kann mir jemand einen NTP-Server in Deutschland oder Frankreich sagen, der permanent erreichbar ist ? Ich habe eine Liste von 18 Stück, nur die meisten existieren nicht mehr und die existieren befinden sich in den USA, die ich nicht verwenden will. In Deutschland stehen die offiziellen Zeitserver bei der Physikalischen Technischen Bundesanstalt. Soweit ich weiß, wird auch das Signal für die Funkempfänger von diesen generiert. ptbtime1.ptb.de ptbtime2.ptb.de FYI, das sind Stratum 1 Server. Weiß nicht, ob sich heute noch jemand daran hält, aber wen's interessiert hier ein paar RulesOfEngagement http://ntp.isc.org/bin/view/Servers/RulesOfEngagement Gruss, Bruno.
Re: ntp.org verstorben ?
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-04-17 15:53:07, schrieb Bruno Hertz: Kiro Zimmer [EMAIL PROTECTED] writes: ptbtime1.ptb.de ptbtime2.ptb.de FYI, das sind Stratum 1 Server. Weiß nicht, ob sich heute noch jemand daran hält, aber wen's interessiert hier ein paar RulesOfEngagement http://ntp.isc.org/bin/view/Servers/RulesOfEngagement Wie ich in meiner vorherigen E-Mail schrieb, da war doch was... Die Server kenne ich, nur möchte ich nicht gerade einen Stratum 1 belästigen. Für dich evtl. auch noch interessant: http://www.cru.fr/NTP/serveurs_francais.html Gruss, Bruno.
Re: ntp.org verstorben ?
Helmut Wollmersdorfer [EMAIL PROTECTED] writes: Und wozu sind sie dann da? www.ptb.de scheint zwar heute down zu sein, aber hier der Google Cache zur ursprünglichen Pressemeldung. Vielleicht steht da ja eine Antwort, und falls sie nicht eindeutig ausfällt könnt ihr euch immerhin mit dem Material schön weiter beharken :) http://google.com/search?q=cache:www.ptb.de/de/aktuelles/archiv/presseinfos/pi2000/pi0100.html Gruss, Bruno.
Re: newsgroup für debian
Sven Hartge [EMAIL PROTECTED] writes: Bruno Hertz [EMAIL PROTECTED] wrote: Christian Frommeyer [EMAIL PROTECTED] writes: Bruno Hertz schrieb am Montag, 11. April 2005 21:00: Lösung wäre: subscribe die newsgroup und bringe deinem Client bei, Followups an die Mailingliste zu posten. Für's Posten mußt du nämlich NICHT TUN!!! (nein meine Shift-Taste klemmt nicht) Das zerstört die Referenzen und damit das Threading in den Newsgroups und auch bei Mailclients, die ausschließlich nach References sortieren. News lesen - News Posten! Mail lesen - Mail Posten! Bitte um Details. Z.B. diese Mail ist ein Followup auf einen Gmane News Artikel. Bei Gmane funktioniert das so, bei lists.bofh.it _nicht_. OK, abschließendes Statement von meiner Seite. Es funktioniert mit Gmane, weil dort die Message IDs nicht umgeschrieben werden. Da dies aber als 'undocumented feature' angesehen werden kann, daß sich auch mal ändert, habe ich mal bei Lars Magne Ingebrigtsen, Autor von Gnus und Maintainer von Gmane, angefragt. Hier meine Frage und seine Antwort: [quote Meine Frage] Hi Lars I've been looking through the FAQ for an entry about Gmane not rewriting Message IDs with no avail, so I guess it hasn't been asked that much. I'd still like, however, to ask if you could drop some words on this issue. Especially on the German Debian User list there's been extended discussions why followups posted directly to mailing lists, thus effectively circumventing the news gateway, are possible with Gmane but not with gateways like bofh.it. The reason obviously being that the latter rewrites MIDs which then break references. Gmane apparently behaves differently, i.e. leaves MIDs intact, but this very much looks like an 'undocumented feature' which might change any day. Since it is still of relevance, I and I'm sure many others would highly appreciate some clarification on this matter. A FAQ entry would be even more great, just as point of reference for future discussions. Thanks very much, Bruno. [end quote Meine Frage] [quote Larsi's Antwort] Gmane apparently behaves differently, i.e. leaves MIDs intact, but this very much looks like an 'undocumented feature' which might change any day. Since it is still of relevance, I and I'm sure many others would highly appreciate some clarification on this matter. Unconditional Message-ID rewriting is pretty silly, and I don't know why anybody does that. It break threading, might lead to injection loops on Usenet, makes it difficult to respond in a sensible way. So, no, Gmane is never going to start doing unconditional Message-ID rewriting. (It's sometimes necessary when the same message is posted to several mailing lists, though.) [quote end Larsi's Antwort] Wer also *_BZGL. GMANE_* (ich fange an die hiesigen Gepflogenheiten zu übernehmen) noch Einwände hat warum es ein Problem sein sollte am Gateway vorbei zu posten, e.g. obskure Crossposting Features o.Ä., mag sie im *_DETAIL UND FACHLICH FUNDIERT VORBRINGEN ODER FÜR IMMER SCHWEIGEN_* :) Gruss, Bruno.
Re: Gepflogenheiten
Andreas Pakulat [EMAIL PROTECTED] writes: On 13.Apr 2005 - 21:01:10, Bruno Hertz wrote: Sven Hartge [EMAIL PROTECTED] writes: Wer also *_BZGL. GMANE_* (ich fange an die hiesigen Gepflogenheiten zu sie im *_DETAIL UND FACHLICH FUNDIERT VORBRINGEN ODER FÜR IMMER SCHWEIGEN_* :) Und was soll da die Gepflogenheit sein? Liess den Thread und du verstehst was ich meine. Um etwas zu bekräftigen nutzt man doch wohl * drumherum. Mails mit vielen Worten in Grossbuchstaben landen gerne im Spamfilter - wozu auch so rumbrüllen (denn als das werden Grossbuchstaben i.a. angesehen) Danke. Seh' ich genauso. Gruss, Bruno.
Re: newsgroup für debian
Bruno Hertz [EMAIL PROTECTED] writes: [quote Larsi's Antwort] Gmane apparently behaves differently, i.e. leaves MIDs intact, but this very much looks like an 'undocumented feature' which might change any day. Since it is still of relevance, I and I'm sure many others would highly appreciate some clarification on this matter. Unconditional Message-ID rewriting is pretty silly, and I don't know why anybody does that. It break threading, might lead to injection loops on Usenet, makes it difficult to respond in a sensible way. So, no, Gmane is never going to start doing unconditional Message-ID rewriting. (It's sometimes necessary when the same message is posted to several mailing lists, though.) [quote end Larsi's Antwort] Noch ein Followup, FYI und um zu vermeiden, daß jetzt Leute an bofh.it posten und vielleicht Larsi (falsch) zitieren. Genauer macht es einen Unterschied, ob ein News server standalone ist, wie Gmane, oder tatsächlich in's Usenet eingebunden ist, wie bofh.it. Daher habe ich nochmal nachgefragt: [quote Meine Frage] So, no, Gmane is never going to start doing unconditional Message-ID rewriting. (It's sometimes necessary when the same message is posted to several mailing lists, though.) That is, if I understand correctly, it's sometimes necessary to specifically convert multiposts into crossposts ? And that would then be the only reason you can imagine right now why conditional MID rewriting might make sense for Mailing Lists/News gateways ? Thanks a lot, Bruno. [quote end Meine Frage] [quote Larsi's Antwort] That is, if I understand correctly, it's sometimes necessary to specifically convert multiposts into crossposts ? It's not generally possible to convert multiposts, because you don't know that it is a multipost until you see the second copy. By that time it's too late to do anything other than rewrite the Message-ID. And that would then be the only reason you can imagine right now why conditional MID rewriting might make sense for Mailing Lists/News gateways ? Well, if the list is supposed to be distributed to the general Usenet, then there's another reason. it.lists.linux-kernel and de.lists.linux-kernel might really be the same mailing list. Then news servers that carry both these Usenet news groups will look very strange -- they won't have messages for these groups based on which group got the messages in question first. But if you're not a Usenet news server (and Gmane isn't a Usenet news server), then that's basically the only reason. [quote end Larsi's Antwort] Also, in summa, während das MID rewriting bei bofh.it durchaus Sinn machen kann, und daher in diesem Fall eben nicht am Gateway vorbei gepostet werden sollte, ist ein rewriting bei Gmane eben nicht nötig. Gruss, Bruno.
Re: Gepflogenheiten
Andreas Pakulat [EMAIL PROTECTED] writes: On 13.Apr 2005 - 22:29:49, Bruno Hertz wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 13.Apr 2005 - 21:01:10, Bruno Hertz wrote: Sven Hartge [EMAIL PROTECTED] writes: Wer also *_BZGL. GMANE_* (ich fange an die hiesigen Gepflogenheiten zu sie im *_DETAIL UND FACHLICH FUNDIERT VORBRINGEN ODER FÜR IMMER SCHWEIGEN_* :) Und was soll da die Gepflogenheit sein? Liess den Thread und du verstehst was ich meine. Das hab ich, also als Reaktion auf das NICHTS TUN! ?? Naja, wenn du meinst... Ich meine. Als Reaktion auf ein sowieso unangebrachtes Winken mit Verbotsschildern, begleitet von Gebrüll, anstelle der sachlichen Vermittlung von Informationen. Gruss, Bruno.
Re: newsgroup für debian
Christian Frommeyer [EMAIL PROTECTED] writes: Bruno Hertz schrieb am Montag, 11. April 2005 21:00: Lösung wäre: subscribe die newsgroup und bringe deinem Client bei, Followups an die Mailingliste zu posten. Für's Posten mußt du nämlich NICHT TUN!!! (nein meine Shift-Taste klemmt nicht) Das zerstört die Referenzen und damit das Threading in den Newsgroups und auch bei Mailclients, die ausschließlich nach References sortieren. News lesen - News Posten! Mail lesen - Mail Posten! Bitte um Details. Z.B. diese Mail ist ein Followup auf einen Gmane News Artikel. Ich sende sie, mit Gnus, direkt an debian-user-german@lists.debian.org und der Referenzen Header Eintrag ist, wie du sehen kannst, folgender References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Sehe also nicht recht, wo das Threading kaputt gehen sollte. Gruss, Bruno.
Re: newsgroup für debian
Sven Hartge [EMAIL PROTECTED] writes: Bruno Hertz [EMAIL PROTECTED] wrote: Christian Frommeyer [EMAIL PROTECTED] writes: Bruno Hertz schrieb am Montag, 11. April 2005 21:00: Lösung wäre: subscribe die newsgroup und bringe deinem Client bei, Followups an die Mailingliste zu posten. Für's Posten mußt du nämlich NICHT TUN!!! (nein meine Shift-Taste klemmt nicht) Das zerstört die Referenzen und damit das Threading in den Newsgroups und auch bei Mailclients, die ausschließlich nach References sortieren. News lesen - News Posten! Mail lesen - Mail Posten! Bitte um Details. Z.B. diese Mail ist ein Followup auf einen Gmane News Artikel. Bei Gmane funktioniert das so, bei lists.bofh.it _nicht_. Danke für die Info. Von bofh.it hatte zwar ausser dir keiner gesprochen, aber trotzdem schön daß das auch nochmal gesagt wurde. Gruss, Bruno.
Re: Anzahl der Pakete
Nico Jochens [EMAIL PROTECTED] writes: On Mon, Apr 11, 2005 at 06:04:39PM +0200, Alexander Schmehl wrote: * Alexander Schmehl [EMAIL PROTECTED] [050411 17:56]: wie kann ich mir die Gesamtanzahl aller installieretn Pakete anzeigen lassen? Ist da as mit apt-get möglich oder wie macht man das? echo `dpkg -l|grep ^ii |wc -l`-5|bc Bei genauerer Ueberlegung ist das Quatsch, weil durch das grep ^ii die Statuszeilen ja gar nicht mehr da sind, die man mit dem echo ..|bc subtrahieren muesste. Also verbleibt eigentlich nur ein: dpkg -l|grep -c ^ii So, hab ich sonst noch was uebersehen? Mmh, das gibt bei mir 809. Mit dpkg --get-selections /sicherung/paketauswahl und wc -l /sicherung/paketauswahl bekomme ich 813, was richtig ist. Wieso? --get-selections listet auch deinstalls, d.h. Pakete die deinstalliert aber nicht purged sind. Gruss, Bruno.
Re: Anzahl der Pakete
Nico Jochens [EMAIL PROTECTED] writes: On Mon, Apr 11, 2005 at 06:53:36PM +0200, Bruno Hertz wrote: Nico Jochens [EMAIL PROTECTED] writes: On Mon, Apr 11, 2005 at 06:04:39PM +0200, Alexander Schmehl wrote: * Alexander Schmehl [EMAIL PROTECTED] [050411 17:56]: wie kann ich mir die Gesamtanzahl aller installieretn Pakete anzeigen lassen? Ist da as mit apt-get möglich oder wie macht man das? echo `dpkg -l|grep ^ii |wc -l`-5|bc Bei genauerer Ueberlegung ist das Quatsch, weil durch das grep ^ii die Statuszeilen ja gar nicht mehr da sind, die man mit dem echo ..|bc subtrahieren muesste. Also verbleibt eigentlich nur ein: dpkg -l|grep -c ^ii So, hab ich sonst noch was uebersehen? Mmh, das gibt bei mir 809. Mit dpkg --get-selections /sicherung/paketauswahl und wc -l /sicherung/paketauswahl bekomme ich 813, was richtig ist. Wieso? --get-selections listet auch deinstalls, d.h. Pakete die deinstalliert aber nicht purged sind. Weiß ich, gibt es bei mir nicht. Das ist es also nicht. Dann extrahier in beiden Fällen mit 'cut' o.Ä. die reinen Paketnamen, sortier sie jeweils in Dateien, mach'n diff und schau dir die entsprechenden Pakete an. Irgendwas wird dann doch wohl zu finden sein was auf den Grund hinweist warum sie in dem einen Fall auftauchen und in dem anderen nicht. Gruss, Bruno.
Re: newsgroup für debian
Maria Baptista da Cunha [EMAIL PROTECTED] writes: Hallo, hat jemand von euch einen newsgroup account für die Debian Liste eingerichtet, würde nämlich lieber über news meine debian liste beziehen als über mails. Das dauert mir zu lange und zieht zuviel speicherplatz. Benutzen tue ich den Thunderbird als Mailclient. Habe mich auch schon bei news.gmane.org angemeldet und die newsgroup gmane.linux.debian.user.german subscribed. Leider kann ich hierrüber nicht antworten, bzw. ich habs nicht hingekriegt. Hat Jemand einen Rat? Alle Debian Listen werden schon in's Usenet gespiegelt, allerdings afaik nur moderated, i.e. die Spiegelung ist unidirektional und du kannst nicht posten. Würde mich daher wundern, wenn's über gmane geht. Lösung wäre: subscribe die newsgroup und bringe deinem Client bei, Followups an die Mailingliste zu posten. Für's Posten mußt du nämlich nicht subscribed sein. E.g. Gnus erlaubt eine solche Konfiguration. Weiß nicht, ob's mit TB geht. Gruss, Bruno.
Re: Anzahl der Pakete
Markus Schulz [EMAIL PROTECTED] writes: Am Montag, 11. April 2005 18:04 schrieb Alexander Schmehl: * Alexander Schmehl [EMAIL PROTECTED] [050411 17:56]: wie kann ich mir die Gesamtanzahl aller installieretn Pakete anzeigen lassen? Ist da as mit apt-get möglich oder wie macht man das? echo `dpkg -l|grep ^ii |wc -l`-5|bc Bei genauerer Ueberlegung ist das Quatsch, weil durch das grep ^ii die Statuszeilen ja gar nicht mehr da sind, die man mit dem echo ..|bc subtrahieren muesste. Also verbleibt eigentlich nur ein: dpkg -l|grep -c ^ii So, hab ich sonst noch was uebersehen? ja die Pakete die auf hold gesetzt sind. dpkg -l|grep -c ^[hi]i liefert dir auch die. Damit sollte dann nichts mehr fehlen. Schöner Hinweis. Wenn man dann ein bischen rumspielt, machen Dinge wie dpkg --get-selections | grep -v '\install\' dann die Dinge auch klarer. Nimmt man das '-v' weg und hängt ein 'wc -l' an die Pipe, sollte dann auch in diesem Fall die gleiche Anzahl installierter Pakete herauskommen wie mit 'dpgk -l' und einem grep auf 'ii' (schließlich ist es ja sowieso dpkg in beiden Fällen). Gruss, Bruno.
Re: newsgroup für debian
Jörg Arlandt [EMAIL PROTECTED] writes: Bruno Hertz wrote: Alle Debian Listen werden schon in's Usenet gespiegelt, allerdings afaik nur moderated, i.e. die Spiegelung ist unidirektional und du kannst nicht posten. Würde mich daher wundern, wenn's über gmane geht. wie Du an meiner Mail sehen kannst, geht es durchaus :) Hab's schon gesehen, danke. War ein Mißverständnis meinerseits, gmane hat ja einen eigenen standalone News Server (i.e. kein Feed in's Usenet), und da können sie's natürlich bidirektional aufsetzen. Gruss, Bruno.
Re: Sexismus in der Liste
Werner Mahr [EMAIL PROTECTED] writes: Am Sonntag, 10. April 2005 21:54 schrieb Nikolaus Schulz: Laber doch nicht immer so einen gequirlten Scheiss. Ein oder zwei Speicherriegel konsumieren nie im Leben 60Watt. Hast Du überhaupt eine Ahnung davon, wieviel Strom 60W bei 5V oder gar 3,3V bedeutet? Bleib lieber beim Stricken... *BAMM* Erschossen! Rüpelhaftes Benehmen, hirnerweichende Haarspaltereien und blasiertes Unix-Wizard-Getue sind in Foren wie diesen ja leider normal und man hat sich daran gewöhnt. Aber man muß doch nicht _jede_ Form der Blamage auskosten. Mal abgesehen davon, das das kein Forum ist, kann ich nicht nachvollziehen, wo du hier was sexistisches sehen willst. Find ich auch reichlich übertrieben. Ausserdem muß man sich auch mal streiten können ohne daß gleich die selbsternannte Sittenpolizei meint eingreifen zu müssen. Gruss, Bruno.
Re: [OT] - Reine Interessensfrage zu gcc-Meldung
Jochen Heller [EMAIL PROTECTED] writes: Hallo, es ist wirklich nichts weltbewegendes oder störendes. Ich beginne nur gerade damit, mich mit C zu beschäftigen und habe das Buch von Kernighan und Ritchie auf dem Schoß. Da habe ich gemerkt, wenn ich ein Programm kompiliere und eben nach der schließenden geschweiften Klammer nicht nochmal Enter gedrückt hab, dass gcc dann bemerkt, dass da keine neue Zeile am Ende der Datei zu finden war. Und da ich diese Meldung ja auch von der /etc/fstab her kenne, wenn man es da eben nicht macht, ohne dass es weiter schlimm ist, möchte ich nur gerne mal wissen, aus welchem Grund stört er sich eigentlich daran? - Oder wird ihm durch die letzte Leerzeile dann eindeutig das Ende der Datei angezeigt oder wie? Ich mein er kompiliert ja das Programm, er sagt halt nur, dass die letzte Zeile keine leere ist. Ich danke Euch für Eure Hilfe Er stört sich nicht daran, er warnt nur. Die Gründe kann ich nicht definitv nennen, aber einer der unmittelbar einleuchtet ist daß C eben auch einen Präprozessor mit einschließt, der z.B. includes erlaubt. Stelle man sich also mal vor eine Source (i.A. ein Header, aber das muß ja nicht so sein) mit einer Makrodefinition auf der letzten Zeile und ohne Newline am Ende würde in ein anderes File inkludiert ... Gruss, Bruno.
Re: [OT] - Reine Interessensfrage zu gcc-Meldung
Nico Jochens [EMAIL PROTECTED] writes: On Sun, Apr 10, 2005 at 11:43:42PM +0200, Jochen Heller wrote: Hallo, es ist wirklich nichts weltbewegendes oder störendes. Ich beginne nur gerade damit, mich mit C zu beschäftigen und habe das Buch von Kernighan und Ritchie auf dem Schoß. Da habe ich gemerkt, wenn ich ein Programm kompiliere und eben nach der schließenden geschweiften Klammer nicht nochmal Enter gedrückt hab, dass gcc dann bemerkt, dass da keine neue Zeile am Ende der Datei zu finden war. Und da ich diese Meldung ja auch von der /etc/fstab her kenne, wenn man es da eben nicht macht, ohne dass es weiter schlimm ist, möchte ich nur gerne mal wissen, aus welchem Grund stört er sich eigentlich daran? - Oder wird ihm durch die letzte Leerzeile dann eindeutig das Ende der Datei angezeigt oder wie? Ich mein er kompiliert ja das Programm, er sagt halt nur, dass die letzte Zeile keine leere ist. Moin Moin, es wird ein EOF (End of file) oder ein LF (LineFeed) erwartet. Da der Compiler zeilenweise liest, erwartet er eine leere Zeile damit er weiß das Schluß ist. Hättste auch noch gesagt er würd' zeilenweise kompilieren wäre 'ne goldene Palme fällig gewesen. Gruss, Bruno.
Re: Sexismus in der Liste
Nikolaus Schulz [EMAIL PROTECTED] writes: kann ich nicht nachvollziehen, wo du hier was sexistisches sehen willst. Ach ja. H, ist es rassistisch, wenn man zu einem Schwarzen sagt geh doch zurück in den Busch, trommeln? Analogie nicht erkennbar. Find ich auch reichlich übertrieben. Ausserdem muß man sich auch mal streiten können ohne daß gleich die selbsternannte Sittenpolizei meint eingreifen zu müssen. Ich habe hier niemanden ernannt :-) Grobiane zu tolerieren gehört zum Handwerk. Die Wahrung gewisser Grenzen auch. Na dann bemüh' dich mal in beidem. Viel Erfolg. Gruss, Bruno.
Re: [OT] - Reine Interessensfrage zu gcc-Meldung
Nico Jochens [EMAIL PROTECTED] writes: On Mon, Apr 11, 2005 at 12:33:55AM +0200, Bruno Hertz wrote: Jochen Heller [EMAIL PROTECTED] writes: Hallo, es ist wirklich nichts weltbewegendes oder störendes. Ich beginne nur gerade damit, mich mit C zu beschäftigen und habe das Buch von Kernighan und Ritchie auf dem Schoß. Da habe ich gemerkt, wenn ich ein Programm kompiliere und eben nach der schließenden geschweiften Klammer nicht nochmal Enter gedrückt hab, dass gcc dann bemerkt, dass da keine neue Zeile am Ende der Datei zu finden war. Und da ich diese Meldung ja auch von der /etc/fstab her kenne, wenn man es da eben nicht macht, ohne dass es weiter schlimm ist, möchte ich nur gerne mal wissen, aus welchem Grund stört er sich eigentlich daran? - Oder wird ihm durch die letzte Leerzeile dann eindeutig das Ende der Datei angezeigt oder wie? Ich mein er kompiliert ja das Programm, er sagt halt nur, dass die letzte Zeile keine leere ist. Ich danke Euch für Eure Hilfe Er stört sich nicht daran, er warnt nur. Die Gründe kann ich nicht definitv nennen, aber einer der unmittelbar einleuchtet ist daß C eben auch einen Präprozessor mit einschließt, der z.B. includes erlaubt. Stelle man sich also mal vor eine Source (i.A. ein Header, aber das muß ja nicht so sein) mit einer Makrodefinition auf der letzten Zeile und ohne Newline am Ende würde in ein anderes File inkludiert ... Lieber Bruno, entschuldige das ich versucht habe zu helfen (siehe andere Mail von dir). Ich habe da wahrscheinlich unrecht und vielleicht C mit der bash verwechselt, k.A. Da ich aber eh nicht so viel Ahnung vom programmieren habe, finde ich es sehr nett von dir das du mir und allen anderen Programmieranfängern es soo einfach erklärt hast...und mit so viel Aussagekraft...bist du Politiker? Nana, ein Späßle darf doch noch mal drin sein, oder? War ja nicht böse gemeint. Außerdem ist doch der Ausblick auf die goldene Palme gar nicht schlecht. Ich selbst wäre auch gern schon mal so nah dran gewesen ... :) Gruss, Bruno.
Re: emacs Darstellung unter root anders
Bruhin [EMAIL PROTECTED] writes: Hallo zusammen Ich weiss nicht ob ich hier richtig bin. Ich habe folgendes: Eine Sarge installation mit KDE, Gnome und Afterstep als WM. Nun wenn ich emacs (emacs21 von gnu) unter root starte, dann ist alles OK. Wenn ich emacs mit einem gewöhnlichen User starte, dann sind die Zeichen kaum lesbar die ich über die Tastatur eingebe. Jetzt welche Berechtigungen fehlen mir (ich habe nur ein apt-get install emacs21 gemacht)? Wahrscheinlich kein Berechtigungs- sondern ein Fontproblem. Die root locale ist Posix, und dafür reichen die standardmäßig installierten Fonts. Nicht aber für de_DE und ähnliches. Installier mal xfonts-base-transcoded xfonts-75dpi-transcoded xfonts-100dpi-transcoded nach und schau dir die Sache nochmal an. Gruss, Bruno.
Re: [OT] - Reine Interessensfrage zu gcc-Meldung
Werner Mahr [EMAIL PROTECTED] writes:
Am Montag, 11. April 2005 01:01 schrieb Nico Jochens:
entschuldige das ich versucht habe zu helfen (siehe andere Mail von
dir). Ich habe da wahrscheinlich unrecht und vielleicht C mit der
bash verwechselt, k.A. Da ich aber eh nicht so viel Ahnung vom
programmieren habe, finde ich es sehr nett von dir das du mir und
allen anderen Programmieranfängern es soo einfach erklärt hast...und
mit so viel Aussagekraft...bist du Politiker?
Mal ein bisschen anschaulicher (falls ich ihn richtig verstanden habe)
#include 1.h
a=b+c;
Nur ein Ausschitt, aber reicht zu zeigen. Für alle nicht Programmierer,
das include kopiert einfach den Inhalt der angegeben Datei an diese
Stelle.
In 1.h steht jetzt irgendwas in der Art:
b=6;
c=7;
Am Ende diese Datei steht jetzt aber kein Newline oder Ähnliches.
Wenn der genannte Präprozessor fertig ist, sieht dein Quelltext in etwa
so aus:
b=6;
c=7;a=b+c;
In diesem Beispiel würde das sogar funktionieren, da das Ende der
Anweisung jeweils durch ein Semikolon gekenzeichnet wird. Es gibt
allerdings auch Konstrikte ohne Semikolon am Ende (würde jetzt
wahrschienlich zu weit führen, ist ja auch nur ein Beispiel), und dann
hättest du zumindest eine schwer zu findenden Bug eingebaut.
Ich hatte doch schon das Schlagwort Makrodefinition erwähnt.
a.h:
/* Ohne Newline am Ende */
#define blah 5
a.c:
#include a.h
int x=2; /* hier kriegen wir jetzt eigentlich #define blah 5x=2; */
int main() {
...
}
So, das kannst du jetzt mit gcc -E a.c testen, und, quelle surprise,
es wird wider die Logik trotzdem das vom Entwickler vermutlich
Erhoffte herauskommen. Und zwar weil der gcc Präprozessor smart genug
ist hier ein Newline einzufügen.
Fakt ist aber, daß der Präprozessor komplette Zeilen inklusive Newline
prozessiert, aus dem Source File entfernt und ggf. mit ihrem Ergebnis
ersetzt. D.h. gcc macht eigentlich mehr als er sollte, und sagt
einfach nochmal Bescheid.
Gruss, Bruno.
Re: Sexismus in der Liste
Nikolaus Schulz [EMAIL PROTECTED] writes: Bruno Hertz wrote: Nikolaus Schulz [EMAIL PROTECTED] writes: snip Ach ja. H, ist es rassistisch, wenn man zu einem Schwarzen sagt geh doch zurück in den Busch, trommeln? Analogie nicht erkennbar. Verdammt. Find ich auch reichlich übertrieben. Ausserdem muß man sich auch mal streiten können ohne daß gleich die selbsternannte Sittenpolizei meint eingreifen zu müssen. Ich habe hier niemanden ernannt :-) Grobiane zu tolerieren gehört zum Handwerk. Die Wahrung gewisser Grenzen auch. Tja, was hab ich da wohl gemeint? Na dann bemüh' dich mal in beidem. Viel Erfolg. Oh Mann. Die Leute lesen es doch, wie sie wollen. Das jemand, der einen Netcop wittert, das so lesen wird, hätte ich mir denken können. *schauder* Gehört das schon zur Bemühung? Nur um deren Qualität richtig einschätzen zu können ... Gruss, Bruno.
Re: [OT] - Reine Interessensfrage zu gcc-Meldung
Bruno Hertz [EMAIL PROTECTED] writes:
a.c:
#include a.h
int x=2; /* hier kriegen wir jetzt eigentlich #define blah 5x=2; */
int main() {
...
}
Sorry, das sollte natürlich heissen
/* hier kriegen wir jetzt eigentlich #define blah 5int x=2; */
Und weil wir dabei sind hier nochmal der Text aus ISO/IEC 9899:1999
6.10.2 Source file inclusion
Constraints
1 A #include directive shall identify a header or source file that
can be processed by the implementation.
Semantics
2 A preprocessing directive of the form
# include h-char-sequence new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the and
delimiters, and causes the replacement of that directive by the
entire contents of the header. How the places are specified or the
header identified is implementation-defined.
Insbesondere ist das Newline auf der #include Zeile Teil der (und
jeder Präprozessor) Direktive, würde also laut Standard mit ersetzt.
Wenn ich den Standard weiter durchwühlte würde ich wahrscheinlich
einen expliziten Hinweis finden, daß Implementierungen (i.e. Compiler)
zu fehlenden Newlines am Dateiende Warnungen ausgeben sollen. Im ANSI
C Standard hat's den nämlich gegeben ...
Gruss, Bruno.
Re: Bashscripting
Andreas Pakulat [EMAIL PROTECTED] writes:
On 07.Apr 2005 - 04:06:11, Bruno Hertz wrote:
Andreas Pakulat [EMAIL PROTECTED] writes:
mailboxes = `find $HOME/.Mail \
-type d \
-name cur \
-maxdepth 2 \
-printf =%P\n \
| sed -e s/cur$ \
-e s/ /\\\ /g \
-e 's^\(.*\)$\1' \
-e /$(date +.%Y-%m)/ p \
-e '/.[0-9]\{4\}-[0-9]\{2\}/ ! p' \
-n \
| sort | xargs echo`
Funktioniert super :-)
Kewl :) (aber irgendwie noch immer monströs, hehe )
Na, so monströs find ichs nicht, ausserdem ist das sehr schnell -
starten von MuttNG dauert jetzt ca. 2 Sekunden (inkl. einlesen von
inbox mit 600 Messages) :-) Das XTerm in dem Mutt läuft braucht fast
schon länger um sich aufzubauen (ist aber auch ein konsole)
Hast recht, sieht gar nicht so schlecht aus bei zweitem Hinsehen.
Vielleicht würde ich noch das Ausschluss-Pattern an den Anfang stellen,
und bei match ein 'd' machen, für next cycle, ähnlich wie continue in
while Schleifen. Damit sparst du dir die ganzen Replacements wo sie nicht
nötig sind. Aber viel macht das natürlich auch nicht aus solange der
Input mengenmässig überschaubar ist. Hauptsache du bist zufrieden ...
Gruss, Bruno.
Re: Bashscripting
Andreas Pakulat [EMAIL PROTECTED] writes:
On 07.Apr 2005 - 13:35:04, Bruno Hertz wrote:
Andreas Pakulat [EMAIL PROTECTED] writes:
On 07.Apr 2005 - 04:06:11, Bruno Hertz wrote:
Andreas Pakulat [EMAIL PROTECTED] writes:
| sed -e s/cur$ \
-e s/ /\\\ /g \
-e 's^\(.*\)$\1' \
-e /$(date +.%Y-%m)/ p \
-e '/.[0-9]\{4\}-[0-9]\{2\}/ ! p' \
-n \
Hast recht, sieht gar nicht so schlecht aus bei zweitem Hinsehen.
Vielleicht würde ich noch das Ausschluss-Pattern an den Anfang stellen,
und bei match ein 'd' machen, für next cycle, ähnlich wie continue in
while Schleifen. Damit sparst du dir die ganzen Replacements wo sie nicht
nötig sind. Aber viel macht das natürlich auch nicht aus solange der
Input mengenmässig überschaubar ist. Hauptsache du bist zufrieden ...
Kannst du mir mal nen kleinen Tipp geben? Das Problem ist nämlich, ich
habe Ordner die heissen
bla.fasel
und welche die heissen
bla.fasel.-MM
für ML's. So, wenn ich man sed richtig verstehe (und dich), meinst du
ich soll die Zeile
-e '(.[0-9]\{4\}-[0-9]\{2\}/ !p'
durch
-e '(.[0-9]\{4\}-[0-9]\{2\}/ d'
ersetzen? Dann würde er aber auch die erwünschten ML-Ordner dieses
Monats aussortieren. Ich will aber nur die ML-Ordner die nicht für
diesen Monat sind aussortieren...
Wenn ich nun aber -e '$(date ...)/ n' mache, um zuerst diese
reinzubekommen und danach die obige Zeile mit 'd' matche, dann werden
die nicht weiter bearbeitet (cur entfernt usw.)
Schon klar. Wie gesagt hatte ich kein Bild wie dein Input aussieht, aber
jetzt ist es etwas klarer.
Das Problem wäre natürlich am besten gelöst mit einem 'and' von regexps,
was aber (afaik) in sed nicht geht. Der Guru ;) hat aber natürlich immer
was in petto, nämlich einen Branch wie z.B. in
sed \
-e /$(date +.%Y-%m)/ b good \
-e '/.[0-9]\{4\}-[0-9]\{2\}/ d' \
-e ':good' \
-e s/cur$ \
-e s/ /\\\ /g \
-e 's^\(.*\)$\1' \
D.h. Matches für `date` gehen sofort zu label 'good', alle weiteren
Datum Matches werden deleted, aber 'nicht Datum Matches' gehen durch.
Involviert etwas mehr als ursprünglich angenommen, und zugegebenermaßen
ein Beispiel aus der Fortgeschrittenenklasse, aber immer noch chique.
Das '-n' fällt übrigens damit weg.
Gruss, Bruno.
PS: das obige branch Kommando ist natürlich eine Remineszenz (oder
Hommage, wenn du willst) an Johnny B. Good.
Re: fetchmail, postfix und die poese HTML-Mail
Peter Schaefer [EMAIL PROTECTED] writes: Am 06.04.2005 23:32, Peter Schaefer wrote: Hallo zusammen, mein fetchmail stirbt reproduzierbar bei einem bestimmten monatlichen HTML-Newsletter, wenn es die Mail an den lokalen Postfix weiterleiten will: fetchmail[14302]: SIGPIPE geworfen von einem MDA oder Stream-Socket-Fehler fetchmail[14302]: Socket-Fehler bei Auslieferung zu SMTP-Host pop.1und1.com fetchmail[14302]: Abfragestatus=2 (SOCKET) Ich Depp. Für die Nachwelt: Es ist eine FAQ: http://www.catb.org/~esr/fetchmail/fetchmail-FAQ.html#R10 Nix für ungut. 30 Tage Fasten inklusive Schlafentzug und allabendlicher Selbstkasteiung sollten reichen, denk ich. Was meint ihr? Gruss, Bruno.
Re: fetchmail, postfix und die poese HTML-Mail
Peter Schaefer [EMAIL PROTECTED] writes: Am 07.04.2005 22:24, Bruno Hertz wrote: 30 Tage Fasten inklusive Schlafentzug und allabendlicher Selbstkasteiung sollten reichen, denk ich. Was meint ihr? Kein Problem - solange mir der DSL-Zugang bleibt ... :) Natürlich. Wollten wir dir den nehmen, würden sicher Menschenrechts- organisationen einschreiten und ein Aufschrei um die Welt gehen. Daher die milderen Maßnahmen :) Gruss, Bruno.
Re: Einstellen der Wiederholrate
Andreas Brillisauer [EMAIL PROTECTED] writes: Hallo, ich habe einen 19-Zoll-Monitor und arbeite am liebsten mit einer 1152x864-Auflösung. Das kann ich mit gnome-display-properties wunderbar einstellen. Jedoch wird mir dort bei der Wiederholrate nur 75 Hz angeboten. Ich möchte den Monitor aber gerne mit 85 Hz betreiben (wird in der Bedienungsanleitung empfohlen). Habe es aber weder mit xf86cfg noch mit dpkg-reconfigure xserver-xfree86 geschafft den Monitor bei 1152x864 auf 85 Hz einzustellen. Wie kann ich das schaffen? Hab ein Sarge vom 19.02.2005 am Laufen. Cheers Andreas Du brauchst eine entsprechende modeline fur XF86Config-4, generierbar mit gtf (man gtf). Wenn sie innerhalb der Monitor/Grafikkarten specs liegt wird sie verwendet, sonst nicht. Am besten daher auch prüfen, ob diese in XF86Config-4 richtig angegeben sind ...
Re: Einstellen der Wiederholrate
Andreas Brillisauer [EMAIL PROTECTED] writes: Am Mittwoch, den 06.04.2005, 19:59 +0200 schrieb Bruno Hertz: Du brauchst eine entsprechende modeline fur XF86Config-4, generierbar mit gtf (man gtf). Wenn sie innerhalb der Monitor/Grafikkarten specs liegt wird sie verwendet, sonst nicht. Am besten daher auch prüfen, ob diese in XF86Config-4 richtig angegeben sind ... Danke für den Tipp! Hab mir mit gtf eine entsprechende Modeline generiert und in die XF86Config-4 eingefügt. Danach konnte ich durch gnome-display-properties die 85 Hz auswählen. Kostet 'ne Mark :) Gruss, Bruno.
Re: MC anderen Prompt beibringen (was: Umsteigen - gleich auf Sarge?)
Michelle Konzack [EMAIL PROTECTED] writes: Greetings Michelle -- [31mLinux-User #280138 with the Linux Counter, http://counter.li.org/[0m [32mMichelle Konzack [33mApt. 917[36mICQ #328449886[0m [32m [33m50, rue de Soultz [36mMSM LinuxMichi[0m [32m0033/3/88452356 [33m67100 Strasbourg/France [36mIRC #Debian (irc.icq.com)[0m Kleine Randbemerkung, und ich weiß nicht wie andere das sehen, aber aus meiner Perspektive hat's deine Signatur irgendwie zerissen. Nur zur Info ...
Re: Bashscripting
Andreas Pakulat [EMAIL PROTECTED] writes:
Hi,
bin ja nun nicht sooo der Bash-Crack, deswegen erlaube ich mal hier
nach Hilfe zu fragen. Folgendes Konstrukt generiert mir meine
Mailbox-Liste für Mutt und ich würd das gerne beschleunigen. Das
Problem dürfte die while-Schleife sein (mutt ist schneller beim
starten wenn ich das rausnehme):
mailboxes = `find $HOME/.Mail \
-type d \
-name cur \
-maxdepth 2 \
-printf =%P\n \
| sed -e s/cur$ \
-e s/ /\\\ /g \
-e 's^\(.*\)$\1' \
| while read f; do \
if [[ $( echo $f | egrep -v .[0-9]{4}-[0-9]{2}) || \
$(echo $f | egrep $(date +.%Y-%m)) ]] ; then \
echo $f; \
fi ; \
done \
| sort | xargs echo`
Ziel der Schleife ist, nur die statischen Maildirs und die
dynamischen des aktuellen Monats stehen zu lassen (also für April alle
maildir.Jahr-Monat auszusortieren wo nicht 2005-04 steht)
OK, das klabüster ich nicht auseinander. Nur soviel: deine egrep regexps
lassen sich in sed auch entweder verwenden oder entsprechend übersetzen.
Zusammen mit der Tatsache, daß 'sed -n' nicht mehr alle Zeilen printet
sondern nur die bei denen du ein 'p' Kommando mit einer Bedingung (match)
deiner Wahl angibst, sollte sich der ganze 'while read' Kram in sed
reinziehen lassen. Vermutlich geht es sogar noch einfacher, aber da ich
kein mutt/Maildir verwende habe ich kein Bild ...
Gruss, Bruno.
Re: Bashscripting
Andreas Pakulat [EMAIL PROTECTED] writes:
On 06.Apr 2005 - 22:30:27, Bruno Hertz wrote:
Andreas Pakulat [EMAIL PROTECTED] writes:
bin ja nun nicht sooo der Bash-Crack, deswegen erlaube ich mal hier
nach Hilfe zu fragen. Folgendes Konstrukt generiert mir meine
Mailbox-Liste für Mutt und ich würd das gerne beschleunigen. Das
Problem dürfte die while-Schleife sein (mutt ist schneller beim
starten wenn ich das rausnehme):
mailboxes =`find $HOME/.Mail \
-type d \
-name cur \
-maxdepth 2 \
-printf =%P\n \
| sed -e s/cur$ \
-e s/ /\\\ /g \
-e 's^\(.*\)$\1' \
| while read f; do \
if [[ $( echo $f | egrep -v .[0-9]{4}-[0-9]{2}) || \
$(echo $f | egrep $(date +.%Y-%m)) ]] ; then \
echo $f; \
fi ; \
done \
| sort | xargs echo`
Ziel der Schleife ist, nur die statischen Maildirs und die
dynamischen des aktuellen Monats stehen zu lassen (also für April alle
maildir.Jahr-Monat auszusortieren wo nicht 2005-04 steht)
OK, das klabüster ich nicht auseinander.
Ist doch nicht schwer: Das find findet alle Ordner mit Namen cur und
maxdepth == 2 (Halt maildir Format) und gibt dann =Ordername/cur
zurück. Das sed entfernt dann das cur und escaped die Leerzeichen mit
\ und den ganzen String mit .
Nur soviel: deine egrep regexps
lassen sich in sed auch entweder verwenden oder entsprechend übersetzen.
Zusammen mit der Tatsache, daß 'sed -n' nicht mehr alle Zeilen printet
sondern nur die bei denen du ein 'p' Kommando mit einer Bedingung (match)
Mit dem Tipp und ein wenig probieren hab ich jetzt:
mailboxes = `find $HOME/.Mail \
-type d \
-name cur \
-maxdepth 2 \
-printf =%P\n \
| sed -e s/cur$ \
-e s/ /\\\ /g \
-e 's^\(.*\)$\1' \
-e /$(date +.%Y-%m)/ p \
-e '/.[0-9]\{4\}-[0-9]\{2\}/ ! p' \
-n \
| sort | xargs echo`
Funktioniert super :-)
Kewl :) (aber irgendwie noch immer monströs, hehe )
Gruss, Bruno.
Re: fetchmail SMTP Fehler 553
Martin Künstner [EMAIL PROTECTED] writes: Hallo zusammen, ich versuche seit längerem mir von fetchmail meine e-mail abholen zu lassen. so wie ich die meldung in /var/log/syslog deute funktioniert das auch. Danach erscheint jedoch ein SMTP 553. Ich weis nicht was hier falsch läuft. Kann mich jemand auf die richtige Fährte bringen ? Anbei die Fehlermeldung: einträge aus /var/log/syslog Apr 5 14:58:16 linux fetchmail[3427]: fetchmail 6.2.5 Dämon wird gestartet Apr 5 14:58:23 linux fetchmail[3427]: 1 Nachricht für [EMAIL PROTECTED] bei pop.mydomain.com (1499 Oktetts). Apr 5 14:58:24 linux fetchmail[3427]: Nachricht [EMAIL PROTECTED]@pop.mydomain.com:1 von 1 wird gelesen (1499 Oktetts) Apr 5 14:58:27 linux fetchmail[3427]: SMTP-Fehler: 553 [EMAIL PROTECTED]: Sender address rejected: not logged in as owner Apr 5 14:58:28 linux fetchmail[3427]: kann noch nicht einmal an fetchmail senden! Apr 5 14:58:29 linux fetchmail[3427]: geflusht Mail 'abholen' involviert idR zwei Schritte: vom Server lesen und irgendwo hin schreiben. Letzteres ist konfigurierbar, aber default sollte sein, daß die Mails an den lokalen Mailserver gehen, und zwar für den User den du entweder auf der Kommandozeile oder im fetchmailrc angegeben hast. Mich dünkt, da läuft etwas schief. Hast du den verkehrten User angegeben? Will der Mailserver Authentifizierung haben?
Re: Haupauge PVR-350 - Einfach nur Fernsehn???
Christian Borchmann [EMAIL PROTECTED] writes: Hallo, bevor ich mit Viedeorecorderexperimenten anfange will ich mit dem Teil erstmal fernsehn. Habe die neustem ivtv Treiber nach einem der vielen Howtos installiert und bekomme keine Fehler beim Laden der Treiber (soweit ich sehe). Wenn ich versuche Video zu capturen bekomm ich nur ein schwarzes .mpg und Fernsehn mit TVTime will auch nicht /dev/video0 not found. Hab ich was übersehen? (1) Der Treiber lädt korrekt und registriert auch seine streams. Zeig uns mal den output von 'ls -l /dev/video* (2) tvtime wird (vermutlich) nicht funktionieren. Der Stream, den die PVR350 liefert, ist mpeg encoded. Du kannst ihn entweder in eine Datei speichern, oder ihn dir live mit mplayer bzw. xine oder einem mythtv setup ansehen. Wie auch immer, die verwendete Applikation muss in der Lage sein, einen mpeg2 Stream zu dekodieren.
Re: Haupauge PVR-350 - Einfach nur Fernsehn???
Christian Borchmann [EMAIL PROTECTED] writes: Hallo, ich habe gar kein /.dev Das mit /etc/udev/links.conf:L video/dev/video ist ein BEfehl oder eine Konfiguraionsdatei??? bis denne Christian Zum dritten Mal (das erste Mal hier, das zweite auf der ivtv Liste): poste die Ausgabe von ls -l /dev/video* -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Mal wieder resolver: dhclient und fqdn .
OK, wahrscheinlich ein FAQ, aber der Tag war hart und ich kann grad nicht mehr, also: sollte dhclient eingentlich nicht einen Eintrag in /etc/hosts schmeissen? hostname --fqdn gibt mir nämlich brav localhost.localdomain zurück, wie es auch richtig für das lokale Interface dort steht. Damit muß ich doch aber hoffentlich nicht leben, oder? Dank voraus für lichtvolle Einblicke, Bruno.
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth [EMAIL PROTECTED] writes: Hallo Bruno, :-) On Wed, 30 Mar 2005, Bruno Hertz wrote: Thomas Antepoth [EMAIL PROTECTED] writes: [ Logfiles in near-realtime parsen ] OK, unter Perl wäre die Vorgehensweise vielleicht wie folgt: * anstatt einer read loop eine select loop mit timeout * in jeder Iteration mit stat prüfen ob sich der inode meiner Datei geändert hat * wenn ja, file neu öffnen. Oder? Ganz genau so muß es funktionieren. Gerade habe ich ein wenig geapt-cached. Hierbei fand sich dann libfile-tail-perl, welches genau dies macht. Ich konnte mir auch ehrlich gesagt nicht vorstellen, dass dieses Basisproblem nicht schon von irgendeinem Menschen auf dem Planeten gelöst wurde. Das gefällt mir dann doch viel besser als alle tail --retry -n ... Backtick-Wurschdeleien. Das auf File::Tail angepasste Script findet sich a.a.O. - der diff dazu findet sich bei http://212.227.20.60/debian/denyssh.diff Herzlichen Dank noch für den Denkanstoß und ein schönes Wochenende! :-) t++ Gleichfalls, vielen Dank :) Das Problem ist übrigens klassisch, insbesondere auch für C Programmierer. I.e. wenn du ein 'open' auf eine Datei machst, kriegst du einen descriptor der valid ist auch wenn die Datei von einem anderen Prozess entfernt wird. D.h. die Datei ist in Wirklichkeit noch da, du kannst sie noch immer lesen und in sie schreiben, sie ist halt nur nicht mehr im Dateisystem sichtbar und wird eben in Wirklichkeit erst entfernt wenn kein Prozess mehr einen offenen file descriptor auf sie hält. All das ist sehr schön, aber es nützt dir natürlich nichts wenn du selbst aus der Datei lesen willst was andere Prozesse in sie schreiben, diese aber bereits eine neue Datei verwenden. Das andere Thema, i.e. 'read' und 'select' ist fast noch klassischer. I.e. in der Regel blockiert ein read auf einem descriptor solange bis Daten zum Lesen eintreffen, was recht lange dauern kann insbesondere wenn keiner mehr in die zugehörige Datei schreibt :) Man kann zwar nun, wenn man regelmäßig andere Bedingungen abprüfen will wie den Zustand der Datei, den read nonblocking setzen, aber das würde auf eine busy loop hinauslaufen solange keine Daten eintreffen, was natürlich unerwünscht ist. Die Standardlösung ist eben 'select', das den Prozess ebenso hübsch schlafen legt wie read wenn keine Daten da sind, aber wo man zusätzlich ein timeout setzen kann, was bei read alleine eben nicht möglich ist. In summa ist also die ganze Thematik, vom programmiertechnischen Standpunkt aus, wirklich ein sehr typischer Standardfall :) Gruss, Bruno.
Re: Experimentelle cyrus22-imapd Pakete verfügbar
Sven Mueller [EMAIL PROTECTED] writes: Schon seit geraumer Zeit verwende ich cyrus 2.1/2.2 erfolgreich mit diesem Patch: http://email.uoa.gr/download/cyrus/cyrus-imapd-2.2.12/cyrus-imapd-2.2.12-autocreate-0.9.2.diff Ich werde das mal mit den anderen cyrus-Maintainern bequatschen, aber meine persönliche Meinung dazu ist, dass dieser Patch dem Admin im Endeffekt mehr Kummer bereitet als er nützt. Aber wie gesagt: Ich werde es mal mit den anderen diskutieren. In dem Zuge auch gleich die anderen Patches von email.uoa.gr. Er ist eigentlich auch nicht wirklich nötig. Egal was man Usern zur Registrierung anbietet, Webinterface oder sonstwas, es kann auch ohne diesen Patch eine Inbox immer gleich mit angelegt werden. Ich hatte mir das Thema vor einem Jahr auch mal angesehen und fand das autocreate gleichfalls recht schnuckelig, habe mich aber schliesslich dagegen entschieden weil mir das Risiko von Seiteneffekten zu hoch war. Ich finde nicht daß der Patch Bestandteil des Standardpaktes sein sollte. Gruss, Bruno.
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Gerhard Brauer [EMAIL PROTECTED] writes: Gruesse! * Bruno Hertz [EMAIL PROTECTED] schrieb am [02.04.05 12:16]: Das gefällt mir dann doch viel besser als alle tail --retry -n ... Backtick-Wurschdeleien. Gleichfalls, vielen Dank :) Das Problem ist übrigens klassisch, insbesondere auch für C Programmierer. I.e. wenn du ein 'open' auf eine Datei machst, Nur der Vollständigkeit halber sei noch erwähnt, das tail für das ständige Parsen von Dateien noch einen anderen (besseren?) Modus bereithält, um FileDescriptor-Änderungen zu überstehen: tail --follow=name /var/log/syslog anstatt tail -f ... orientiert sich *immer* am Namen, nicht am Handle. Du meinst wohl -F : '-F same as --follow=name --retry' Stimmt, funktioniert. Danke, Bruno.
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Gerhard Brauer [EMAIL PROTECTED] writes:
Probiere es bitte aus z.B. mit der syslog. Ohne explizites
--follow={name} überlebt dein tail kein logrotate.
Doe man page sagt lediglich das -f, --follow und
--follow=descriptor equivalent sind. --follow={name} ist eine
seperate Option. Und nur mit dieser Option wird nicht mit dem
jeweils letzten Filedescriptor gearbeitet.
Haha, lustig. Die Thematik wird sogar explizit in der man page
erwähnt, man muß nur etwas runterblättern. Hätten sie aber auch
bei der Option schreiben können, daß weiter unten zu dem Thema
noch etwas gesagt wird. Wie auch immer, gut observiert :)
Gruss, Bruno.
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Gerhard Brauer [EMAIL PROTECTED] writes:
Bruno Hertz schrieb:
Probiere es bitte aus z.B. mit der syslog. Ohne explizites
--follow={name} überlebt dein tail kein logrotate.
Haha, lustig. Die Thematik wird sogar explizit in der man page
erwähnt, man muß nur etwas runterblättern. Hätten sie aber auch
bei der Option schreiben können, daß weiter unten zu dem Thema
noch etwas gesagt wird. Wie auch immer, gut observiert :)
Nee, das ist lediglich eines der 151 Dinge, die ich im Leben
wirklich auswendig weiß. Jedesmal habe ich mir nämlich auch
den Wolf gesucht und erst alle möglichen Kombinationen
durchprobieren müssen.
Tut mir leid, trotzdem gut observiert :)
Gruss, Bruno.
Re: Logfiles
Michelle Konzack [EMAIL PROTECTED] writes: Nimm ein BASH Script und werte mit 'tail -f datei dann Zeile für Zeile mit | grep -i sshd\[.*: illegal user oder | grep -i POSSIBLE BREAKIN ATTEMPT aus... ... $RETVAL ist das, was der oben genannte grep zurückgibt. Rein interessenshalber, wie soll das denn funktionieren? In tail -f datei | grep irgendwas kehrt grep nicht zurück bevor es ein EOF auf der Pipe sieht, d.h. 'nie' ...
Re: Logfiles
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-30 14:13:25, schrieb Bruno Hertz: Rein interessenshalber, wie soll das denn funktionieren? In tail -f datei | grep irgendwas kehrt grep nicht zurück bevor es ein EOF auf der Pipe sieht, d.h. 'nie' ... for RETVAL in `tail -f auth.log |grep -i sshd\[.*: illegal user` do ... ... done Das hast du nicht getestet, weil das eben nicht funktionieren kann. Genau auf dieses Problem hat meine Bemerkung gezielt. Was zum Beispiel geht ist tail -f auth.log | while read line do echo $line | grep blah if [ $? -eq 0 ] then blah fi done und blah müsste dann den Mail Code enthalten. Eigentlich Banalitäten, aber wie gesagt interessenshalber Dabei kann es dir aber passieren das Du 1000 messages pro Tag bekommst. Das hatte ich mir auch gedacht. I.d.R. testet eine IP ja etliche User Namen. Vielleicht besser Perl anstatt Shell, geht einfacher.
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth [EMAIL PROTECTED] writes: Soweit die Theorie: In der Praxis tut sich dann aber folgendes Problem auf: Wenn irgendeine Instanz auf dem Rechner das Logfile weglöscht, dann hängt das Script Ohne deine Situation zu kennen, die besagte 'irgendeine Instanz, kann doch eigentlich nur logrotate sein. Wäre es nicht ratsam das entsprechende logrotate Skript anzupassen, so daß dein Skript vorher gestoppt und dann wieder gestartet wird?
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth [EMAIL PROTECTED] writes: On Wed, Mar 30, 2005 at 07:11:43PM +0200, Thomas Antepoth wrote: ist zwar auch schoen, aber wqas spricht denn gegen iptables -A INPUT -m dstlimit -p tcp --dport 22 --dstlimit 1/hour \ --dstlimit-mode srcip-dstip -j ACCEPT und einer DROP Rule/ Gefällt mir auch sehr gut. Vielleicht lohnt auch mal ein Blick auf http://blog.andrew.net.au/2005/02/17
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth [EMAIL PROTECTED] writes: Ja komma aber ;-) Das Script selbst sollte das doch der reinen Lehre nach erkennen können, ob eine Datei aus der sie zu lesen versucht, mittlerweile schon gelöscht ist. Hat irgendwie was von Selbständigkeit und Seiteneffektfreiheit. Weiss zwar nicht welche reine Lehre das ist, aber genau dies Problem ist nicht das trivialste. Ein Prozeß, der in einem 'read' blockiert, ist halt blockiert und kann nichts anderes machen. Je nach Umgebung (Shell, Perl, C) kann man zwar diverse Timeouts setzen (e.g. via select()), aber unter bash habe ich so ein Problem noch nicht behandelt. Kann hierzu jemand was sagen, wäre interessant ...
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth [EMAIL PROTECTED] writes: Soweit verstanden. Aber diese Module sind sicherlich nicht in: ii iptables 1.2.11-8 enthalten, oder? Soweit ich sehe nicht, auch nicht in unstable. Wenn du das nutzen willst, wirst du vermutlich selbst Hand anlegen müssen (es sei denn irgendwo fliegt ein aktuelleres netfilter deb herum). Mehr kann ich dazu leider derzeit auch nicht sagen, ich weiß nur daß dieses Modul vermehrt genutzt wird insbesondere um ssh Attacken abzuwehren und wollte es der Vollständigkeit halber erwähnt haben :) Selber installiert habe ich es auch noch nicht (insbesondere weil ich Passwörter deaktiviert habe und mir um die Dödel daher nicht gar soviele Sorgen machen muss ...)
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth [EMAIL PROTECTED] writes: Andererseits fand ich die Sache mit dem Tail etwas krude. Mir schwebte sowas wie eine automatische Erkennung des Umstands der Löschung oder Umbenennung in PERL vor. Eigensinnigerweise, versteht sich :-) OK, unter Perl wäre die Vorgehensweise vielleicht wie folgt: * anstatt einer read loop eine select loop mit timeout * in jeder Iteration mit stat prüfen ob sich der inode meiner Datei geändert hat * wenn ja, file neu öffnen. Oder?
Re: libssh-Bruteforcer in IPTABLES Chain bannen
Stefan Muthers [EMAIL PROTECTED] writes: also bei mir mit iptables v1.2.6a und kernel 2.4.27-1-386 funktioniert folgendes: __( 'firewall' )___ / | iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \ | --hitcount 4 -j LOG --log-prefix SSH_BRUTE_FORCE | iptables -A INPUT -p tcp --dport 22 -m recent --set | iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \ | --hitcount 4 -j DROP | iptables -A INPUT -p tcp --dport 22 -j ACCEPT | \__ Stimmt, sorry. Auf Sarge: $ dpkg -l iptables ii iptables 1.2.11-8 Linux kernel 2.4+ iptables administration $ dpkg -L iptables | grep -i recent /lib/iptables/libipt_recent.so Geht also sogar 'out of the box'. Danke. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OS Backup
Ulf Volmer [EMAIL PROTECTED] writes: Formatieren brauchst du so eben nicht, nur Partitionen solten existieren. Grundsätzlich kann man das so machen wenn man ein paar Sachen beachtet: - Im Laufenden Betrieb ist das resultierende Image nicht konsistent, was aber nicht ganz so schlimm ist: - r/o- mounten, dann dd - knoppix o.a. booten, dann dd - dd, dann fsck $IMAGE (etwas hakelig, hier jedoch meist problemlos) Ansonsten noch ein Paar Tips: - Um das Image klein zu halten, vor dem dd den freien Speicherplatz mit Nullen füllen und das Image komprimieren: dd if=/dev/zero bs=4M of=/mountpoint/BIG rm /mountpoint/BIG dd if=/dev/hda1 bs=4M | gzip -c - backup.iso.gz Als Nebenbemerkung, es gibt hierfür auch (GPL) Lösungen. Zu nennen wäre in jedem Fall http://www.mondorescue.org/
Re: IMAP über SSL: Passwort trotzdem im Klartext?
Bernhard Schwartz [EMAIL PROTECTED] writes: Hi, ich habe mal eine vielleicht etwas blöde Frage. Ich habe auf einem Server Courier-IMAP-SSL installiert, aber um CRAM-MD5 zum laufen zu kriegen, muss man ja noch so einiges konfigurieren. Denn für CRAM-MD5 muss Courier ja das Klartext-Passwort kennen. Jetzt die Fragen: Wird bei SSL/TLS mit IMAP das Passwort im Klartext übertragen und nur der Mailtransport selbst verschlüsselt (dann wäre CRAM-MD5 ja auf jeden Fall noch notwendig), oder kann ich mir das sparen, wenn ich SSL/TLS benutze? s.u. Punkt 3.1 Was ist besser: SSL oder TLS? s.u. Punkt 1 Danke, Bernhard Aus RFC 2595: 1. Motivation The TLS protocol (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. ... 3.1. STARTTLS Command Arguments: none Responses: no specific responses for this command Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete. The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism. Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. The formal syntax for IMAP is amended as follows: command_any =/ STARTTLS Example:C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED S: a001 OK CAPABILITY completed C: a002 STARTTLS S: a002 OK Begin TLS negotiation now TLS negotiation, further commands are under TLS layer C: a003 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL S: a003 OK CAPABILITY completed C: a004 LOGIN joe password S: a004 OK LOGIN completed Mit anderen Worten, unter TLS wird die Authentifizierung verschlüsselt durchgeführt. Die Verwendung von plain/login ist also 'sicher'. Gruss, Bruno.
Re: variablen durch pipes (bash)
Christoph Wegscheider [EMAIL PROTECTED] writes:
for i in `find . -name *gif`;do
echo convert $i `echo $i | sed 's/^\(.*\)gif$/\1jpg/'`
done
Oder (in bash):
for i in *.gif; do
echo convert $i ${i%gif}jpg
done
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: finden von dateien, die andere zeichen als muster enthalten
Bastian Venthur [EMAIL PROTECTED] writes: Hi Liste, ich möchte in einem Verzeichnis (und seinen Unterverzeichnissen) alle Dateien finden, die nicht ausschließlich a-z, A-Z, 0-9, -_. enthalten. Ziel ist es alle Dateien aufzuspüren, die irgendwelchen Obskuren Sonderzeichen enthalten. Da ich aber nicht weis nach welchen Sonderzeichen ich genau suchen sollte, will ich also alle Dateien finden, die nicht ausschließlich aus Nicht-Sonderzeichen bestehen. Kann mir einer auf die Sprünge helfen, wie der entsprechende find-Befehl aussehen muss? Z.B. find . ! \( -name .[A-Za-z0-9._-]* -or -name [A-Za-z0-9._-]* \)
Re: finden von dateien, die andere zeichen als muster enthalten
Bastian Venthur [EMAIL PROTECTED] writes: Hi Liste, ich möchte in einem Verzeichnis (und seinen Unterverzeichnissen) alle Dateien finden, die nicht ausschließlich a-z, A-Z, 0-9, -_. enthalten. Ziel ist es alle Dateien aufzuspüren, die irgendwelchen Obskuren Sonderzeichen enthalten. Da ich aber nicht weis nach welchen Sonderzeichen ich genau suchen sollte, will ich also alle Dateien finden, die nicht ausschließlich aus Nicht-Sonderzeichen bestehen. Kann mir einer auf die Sprünge helfen, wie der entsprechende find-Befehl aussehen muss? ... und noch einfacher find . -name [EMAIL PROTECTED] :)
Re: finden von dateien, die andere zeichen als muster enthalten
Bruno Hertz [EMAIL PROTECTED] writes: ... und noch einfacher find . -name [EMAIL PROTECTED] :) ... ist aber nicht korrekt, eher find . -name [EMAIL PROTECTED]@_-]* -or -name [EMAIL PROTECTED] um auch Dateien einzuschliessen, die mit einem '.' anfangen. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: finden von dateien, die andere zeichen als muster enthalten
Evgeni -SargentD- Golov [EMAIL PROTECTED] writes: On Fri, 25 Mar 2005 14:05:20 +0100 Bruno Hertz [EMAIL PROTECTED] wrote: Bastian Venthur [EMAIL PROTECTED] writes: Hi Liste, ich möchte in einem Verzeichnis (und seinen Unterverzeichnissen) alle Dateien finden, die nicht ausschließlich a-z, A-Z, 0-9, -_. enthalten. Ziel ist es alle Dateien aufzuspüren, die irgendwelchen Obskuren Sonderzeichen enthalten. Da ich aber nicht weis nach welchen Sonderzeichen ich genau suchen sollte, will ich also alle Dateien finden, die nicht ausschließlich aus Nicht-Sonderzeichen bestehen. Kann mir einer auf die Sprünge helfen, wie der entsprechende find-Befehl aussehen muss? Z.B. find . ! \( -name .[A-Za-z0-9._-]* -or -name [A-Za-z0-9._-]* \) -name ist hier bestimmt falsch *SCNR* Er meint wohl alle Dateien finden, deren Name nicht ausschließlich a-z, A-Z, 0-9, -_. und nicht alle Dateien finden, die nicht ausschließlich a-z, A-Z, 0-9, -_.
Re: finden von dateien, die andere zeichen als muster enthalten
Elvis Cehajic [EMAIL PROTECTED] writes: find . -name [EMAIL PROTECTED]@_-]* -or -name [EMAIL PROTECTED] Hm, auch das ist nicht ganz korrekt. Dieser ausdruck findet zum Beispiel keine Dateien mit dem Namen - (ohne Anführungszeichen). Klar, sehr viele sinnvolle Dateinamen enthalten einen Bindestrich, zum Beispiel bash-2.1.10.tar.gz. Deshalb habe ich ihn in's Pattern mit aufgenommen. Wer das nicht will, nimmt ihn halt raus: find . -name [EMAIL PROTECTED]@_]* -or -name [EMAIL PROTECTED]
Re: finden von dateien, die andere zeichen als muster enthalten
Elvis Cehajic [EMAIL PROTECTED] writes: find . -name [EMAIL PROTECTED]@_]* -or -name [EMAIL PROTECTED] Naja, das Problem ist dass Dateien welche 2 Bindestriche enthalten (z.B. --) gefunden werden und diejenigen mit nur einem Bindestrich nicht. Will ja eigentlich gar nicht motzen, soll der OP entscheiden was ihm am besten schmeckt. Sehr gut, danke für den Hinweis. Manchmal schmeißt man Regex Syntax und Shell Patterns gedanklich durcheinander :) Besser also: pat='[EMAIL PROTECTED]' find . -name .$pat -or -name $pat
Re: finden von dateien, die andere zeichen als muster enthalten
Bruno Hertz [EMAIL PROTECTED] writes: pat='[EMAIL PROTECTED]' find . -name .$pat -or -name $pat Fehlt'n Semikolon, und Bindestrich/@ hatte ich auch wieder dabei. Also jetzt mein letzter Versuch zu dem Thema pat='*[^[:alnum:]._]*'; find . -name .$pat -or -name $pat So is OK, oder? :) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
Sven Mueller [EMAIL PROTECTED] writes: Vergiss mal das unset LC_ALL. Das ändert nichts. LC_COLLATE hat Vorrang vor LC_ALLLC_CTYPE. Quatsch. Probier's mal aus. Teste mal (mit LANG != C/POSIX) LC_COLLATE=C echo * unset LC_ALL echo * LC_CTYPE hat mit dem Thema übrigens gar nichts zu tun. Fängt ja gut an ... Ganz einfach: Die Bash startet für Prozesse in `` keinen eigenen Prozess, wenn sondern erstellt nur einen neuen internen Context. Programme in `` werden natürlich ebenso gestartet, wie auch bei direktem Aufruf. Auch für Pseudo-Subshells wie ( ls; echo N ) wird kein eigener Shell-Prozess gestartet, sondern nur ein Thread bzw. neuer interner Context. Selten so dämliches Zeug gelesen. Selbst für ein builtin wie echo wird in backticks ein child process erzeugt, erst recht für binaries. Lass mal deine Scripts mit strace -f laufen und schau dir mal die clones/forks an. Weiss gar nicht warum ich auf solchen Blödsinn überhaupt antworte ... Deshalb macht es auch absolut keinen Unterschied für die Auflösung von Aufzählungen auf der Kommandozeile, ob Du vor einem for i in [A-C]; do echo $i; done nun LC_COLLATE ändert oder nicht. Leg mal ein Verzeichnis an mit den Dateien a A b B (das reicht für die Demonstration) und mache nacheinander folgendes: unset LC_ALL LC_CTYPE LC_COLLATE Du hast noch immer nicht verstanden was 'unset LC_ALL' bewirkt. Meld' dich wieder, wenn du einen Schimmer hast (kann allerdings nicht garantieren, daß ich so lange warte). Und versuche zu verstehen, warum die Ausgaben so aussehen, wie sie aussehen. Versuch's mal besser selbst. Ich räum' dir allerdings wenig Chancen ein. Kenne ich, danke. Ich weiss, wie locales funktioniert. Du aber scheinbar nicht vollständig. Wie kann man nur so peinlich sein. Und das auch noch öffentlich, auf von Suchmaschinen indizierten Listen ... kaum glaublich.
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-22 12:57:59, schrieb Bruno Hertz: Genau darüber reden wir die ganze Zeit, von den Buchstaben 'A bis Z'. Wenn die collation order aber z.B. a A b B z Z ist, sind das aber eben nicht nur Grossbuchstaben (sondern alle Gross- und Kleinbuchstaben von a bis z ausser 'klein a'). LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp zeigt aber ebenfals klein und gross Buchstaben an... Logisch. LC_COLLATE=C wird hier nur an ls exportiert, für die Shell bleibt es aber unwirksam. D.h. hier greift immer noch dein locale setting. Um auch für die Shell also LC_COLLATE auf C zu setzen LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Um es auch für Subshells/geforkte Prozesse wirksam zu machen export LC_COLLATE=C LC_COLLATE hat NICHTS mit RegExp zu tun, sonern nur mit der Reihenfolge Wie du auf RegExp kommst ist mir ein Rätsel. Hat das irgendjemand erwähnt? Und brüllen mußt du auch nicht unbedingt ... Na also, Problem gelöst. Nee, denn es ist nicht die Loesung zu ls $HOME/devel/bash/[A-Z]*.tmp Ich könnt's nochmal erklären, spare es mir aber. Es ist wirklich alles gesagt. Alles as ich verwende ist [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Dann poste auch mal die Ausgabe von locale. Gute Frage. Wie gesagt handelt es sich um die glibc. Wenn also irgendwo ein 'Fehler' ist, liegt er dort. Steht irgendwo im BTS und auch in der debian-devel Stimmt. Bei all den Bug Reports schien sich aber bisher zu bewahrheiten, dass es kein Bug war sondern eben Unverständnis der collate Thematik. Ich sehe kein offenes/relevantes Bug Listing zu diesem Thema.
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-23 21:07:53, schrieb Bruno Hertz: Um auch für die Shell also LC_COLLATE auf C zu setzen LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Hä ? Für was ? Stimmt, war falsch. Richtig: export LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Ein 'ls $HOME/devel/bash/[A-Z]*.tmp' benötigt kein LC_COLLATE. Inkorrekt. Es braucht es sogar zweimal: (1) $HOME/devel/bash/[A-Z]*.tmp wird von der Shell expandiert. Die Reihenfolge wird dabei bestimmt von LC_COLLATE. man bash, 'path expansion' und 'range expression' (2) ls erhält die expandierte Parameterliste und sortiert jetzt aber nochmal, wieder gemäß LC_COLLATE. Deshalb oben das export. man strcoll (wird von ls verwendet) Das LC_COLLATE ist nur bei 'ls $HOME/devel/bash/*.tmp' witksam. Leider falsch. man bash. Um es auch für Subshells/geforkte Prozesse wirksam zu machen export LC_COLLATE=C Das will ich aber nicht... LC_COLLATE=de_DE Das wird nicht gehen. Entgegen eines vorherigen Postings von mir (hatte einen Fehler gemacht weil bei mir de_DE überhaupt nicht installiert war, deshalb hatte ein entsprechendes collate setting auch keine Auswirkung) ist die collation order für de_DE die gleiche wie bei en_US, nämlich a A b B z Z D.h. eine range expression der Form [A-C] enthält die Buchstaben A b B c C d.h. eben nicht nur Grossbuchstaben, und gemäß dieser Reihenfolge wird auch sortiert. Du kannst aber [ABCDEFGHIJKLMNOPQRSTUVWXYZ] schreiben, das geht dann auch mit de_DE :) Die collation order ist für die country locales vor einiger Zeit mal umgestellt worden (sie war vorher wie ASCII, i.e. entsprechend LC_COLLATE=C). Das ist aber schon Jahre her, meine ich ... Wie du auf RegExp kommst ist mir ein Rätsel. Hat das irgendjemand erwähnt? Und brüllen mußt du auch nicht unbedingt ... Esa geht darum das die BASH [A-Z]* expandiert, aber ein SCRIPT in der gleichen Shell es ignoriert. Du meinst daß das Skript anders expandiert als die Shell. Mit regexps hat das aber nichts zu tun, und das hat auch niemand behauptet. Ihr redet nur con LC_COLLATE was nichts damit zu tun hat. Ich habe erste heute vormittag eine WOODY Maschine von den 3.0r0 CD's installiert und mein Script funktioniert... Unser Thema war die Sortierreihenfolge von Ausdrücken wie ls /irgendeinpfad/[A-Z]*.irgendwas und welche Buchstaben (klein,groß) in solchen range expressions vorkommen. Und das ist sowohl was die shell expansion als auch die Sortierung von ls angeht bestimmt von LC_COLLATE. Probier's dochmal mit einem Testskript der Form LC_COLLATE=$1 echo $LC_COLLATE # shell expansion gemäß $1 echo /irgendeinpfad/[A-Z]*.irgendwas # shell expansion und sortierung von ls; da LC_COLLATE nicht # exportiert wurde, greift $1 hier noch nicht ls /irgendeinpfad/[A-Z]*.irgendwas export LC_COLLATE # shell expansion gemäß $1 echo /irgendeinpfad/[A-Z]*.irgendwas # ausgabe von ls sollte mit vorherigem echo korrespondieren # da LC_COLLATE exportiert wurde ls /irgendeinpfad/[A-Z]*.irgendwas und ruf es mit skript.sh C resp. de_DE und wasnoch auf. Dann wird die Sache vielleicht klarer. Nach dem Update auf r4 funktionierren keine BACKUP-Scripts und jede menge andere Scrips nicht mehr. Schlimm. Soweit ich das aus GOOLGE erfahren habe hängt das mit dem Security update der libc6 zusammen... da ist was kaputt gegangen. Kann sein. Wie gesagt habe ich kein Woody, nur Sarge. Letztres ist aber up-to-date, und die Dinge funktionieren hier genau so wie von mir beschrieben. LC_COLLATE=[EMAIL PROTECTED] OK, das sollte dann aber auch für die interaktive Shell gelten. Wenn die mit diesem setting [A-Z] in A B C ... Z expandiert, ist etwas komisch. Sie sollte es in a A b B ... z Z expandieren, interaktiv ebenso wie per Skript.
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-23 22:38:19, schrieb Bruno Hertz: (1) $HOME/devel/bash/[A-Z]*.tmp wird von der Shell expandiert. Die Reihenfolge wird dabei bestimmt von LC_COLLATE. man bash, 'path expansion' und 'range expression' Was bedeutet das GNU/Linux plötzlich Case-Insensitive geworden ist. denn bei mir sind A-Z GROSSbuchstaben und a-z kleinBUCHSTABEN. S.u. (2) ls erhält die expandierte Parameterliste und sortiert jetzt aber nochmal, wieder gemäß LC_COLLATE. Deshalb oben das export. man strcoll (wird von ls verwendet) Aber die expandierte Liste ist enen nur [A-Z]* . Also woher kommt dann [a-z]* ? Unter de_DE ist [A-Z] = A b B c C ... z Z Dann darf es am BASH Prompt ja auch nicht funktionieren, was es aber tut. Skript und interaktive Shell sollten mit demselben LC_COLLATE gleich arbeiten, richtig. Wenn es das bei dir nicht tut, hast du (noch) ein anderes Problem. Bei mir funktioniert es einheitlich. LC_COLLATE=de_DE Das wird nicht gehen. Entgegen eines vorherigen Postings von mir (hatte Das wiederspricht dann aber das am BASH prompt es auch funktiniert. wenn ich z.b. for i in `ls -d` ; do ls $i/[A-Z]* ; echo ; done ^ Sub-SHELL Sub-SHELL aufrufe funktioniert es einwqndfrei, wogegen Deine Erklärung nicht standhällt. Kann ich nichts zu sagen ohne Verzeichnisinhalte und output. Ich habe innerhalb des Scripts locale aufgerufen und es liefert die gleiche Antwort wie am BASH prompt. Wenn am BASH Prompt 'ls [A-Z]*' funktioniert und im BASH Script die gleichen locale vorhanden sind, muß der Fehler noch woanderst liegen. Kann sein. Ich gebe ja an das ich nur Dateien die mit GROSS Buchstaben anfangen haben will. LC_COLLATE hat aber mit der Sortierreihenfolge zu tun. (hat mir jemand von der debian-devel klar gemacht) Hier versucht dir auch einer was klar zu machen, und es gestaltet sich sehr mühsam. Deine Aussage, du gäbest an 'nur GROSS Buchstaben' haben zu wollen, ist verkehrt. Unter de_DE heißt [A-Z] eben nicht 'nur GROSS Buchstaben', sondern alle Buchstaben die gemäß der wirksamen Sortierreihenfolge in dem Range A bis Z enthalten sind. Wenn die Sortierung aber eben a A b B ... z Z ist, sind in dem Range auch alle Kleinbuchstaben außer (klein) a enthalten. __( command 'skript.sh de_DE' )___ / | de_DE | /home/michelle.konzack/devel/bash/[A-Z]*.tmp Wieso wird das nicht expandiert? Hast du quotes eingefügt? | /home/michelle.konzack/devel/bash/BASE.tmp | /home/michelle.konzack/devel/bash/help_version.tmp | /home/michelle.konzack/devel/bash/pid.tmp | /home/michelle.konzack/devel/bash/prog_parts_by_option.tmp | /home/michelle.konzack/devel/bash/read_config.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help_and_pid.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help.tmp | /home/michelle.konzack/devel/bash/SKEL_with_pid.tmp | /home/michelle.konzack/devel/bash/td.tmp Wie erwartet unter de_DE (für ls greift hier deine default locale). | /home/michelle.konzack/devel/bash/[A-Z]*.tmp Wieso wird das nicht expandiert? So können wir es nicht mit der Ausgabe von ls vergleichen. | /home/michelle.konzack/devel/bash/BASE.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help_and_pid.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help.tmp | /home/michelle.konzack/devel/bash/SKEL_with_pid.tmp | /home/michelle.konzack/devel/bash/help_version.tmp | /home/michelle.konzack/devel/bash/pid.tmp | /home/michelle.konzack/devel/bash/prog_parts_by_option.tmp | /home/michelle.konzack/devel/bash/read_config.tmp | /home/michelle.konzack/devel/bash/td.tmp Das sollte nicht sein, da du das Skript mit de_DE aufgerufen hast, was sowieso deiner default locale entspricht. Ein export macht also gar keinen Unterschied. Der Range wird zwar noch richtig von der Shell expandiert (inklusive Kleinbuchstaben), aber ls sortiert gemäß C locale. Ist dein ls veraltet (strcmp statt strcoll für Vergleiche) ? Aber dann sollte es oben ja das gleiche sein, da du ja mit de_DE eigentlich sowieso nichts änderst. Sehr undurchsichtig. Hast du ein LC_COLLATE=C vor das zweite ls gesetzt? Im übrigen wäre der Vergleich mit C ja sowieso das interessante gewesen ... \__ Das ist aber nicht das was ich will, denn ich habe ja [A-Z]* angegeben und nicht [A-Za-z]*. Im Script wird einfach GROS und klein Schreibung ignoriert. LC_COLLATE sortiert zwar richtig, aber 'ls' zeigt falsch an. Ich rede über die Expansion von ranges jetzt nicht nochmal. Wenn du jetzt noch nicht verstanden hast daß [A-Z] nicht automatisch 'nur Großbuchstaben' heißt kann ich auch nichts mehr dazu sagen. Also ich habe hier eine Develststion mit POTATO, WOODY, SARGE und SID chroots... Ich habe überall den gleichen Fehler... (i386 + amd64) Auf 68k und powerpc habe ich das ergebnis wie bei Dir. Wenn der
