filesize fehlerhaft
Hallo, da wundert man sich, warum ein Shellscript ploetzlich komische Fehler bringt: " [: too many arguments" und was ist die Ursache? filesize liefert zwei (!) Argumente zurueck. Aber nur, wenn der Benutzername, dem die betreffende Datei gehoert, 8 Zeichen hat. (mit mehr als 8 nicht getestet) Das ganze unter SuSE 6.4 und 7.0, andere nicht getestet. Problem und Loesung: ersetze in /usr/bin/filesize die Zeile SIZE=`ls -l -d -G "$1" | cut -b23-32` durch SIZE=`ls -l -d -G "$1" | cut -b24-32` eigentlich gefaellt mir das aber nicht, da ja beim naechsten Systemupdate die Datei ja wieder ueberschrieben werden koennte, oder? Gibt es evtl. noch einen anderen Befehl, mit dem ich die Dateigroesse bestimmen kann? viele Gruesse, Knut
* Knut Pfefferkorn schrieb am 07.Feb.2001:
und was ist die Ursache? filesize liefert zwei (!) Argumente zurueck. Aber nur, wenn der Benutzername, dem die betreffende Datei gehoert, 8 Zeichen hat. (mit mehr als 8 nicht getestet) Das ganze unter SuSE 6.4 und 7.0, andere nicht getestet.
Problem und Loesung: ersetze in /usr/bin/filesize die Zeile SIZE=`ls -l -d -G "$1" | cut -b23-32` durch SIZE=`ls -l -d -G "$1" | cut -b24-32`
eigentlich gefaellt mir das aber nicht, da ja beim naechsten Systemupdate die Datei ja wieder ueberschrieben werden koennte, oder? Gibt es evtl. noch einen anderen Befehl, mit dem ich die Dateigroesse bestimmen kann?
Verwende diese Zeile doch direkt in Deinem Shellskript. Mehr steht in filesize doch auch nicht drin, dann hast Du noch einen Prozessaufruf gespart. Ansonsten gibt es wc. Bernd -- Welches Buch ist zu empfehlen? Schon mal bei SuSE vorbeigesehen? http://www.suse.de/de/produkte/buecher/index.html oder die Empfehlungen der SuSE-Entwickler auf dem eigenen Rechner? file:///usr/shar/doc/sdb/de/html/literatur.html |Zufallssignatur 5
Hallo, On Mit, 07 Feb 2001, Knut Pfefferkorn wrote:
ersetze in /usr/bin/filesize die Zeile SIZE=`ls -l -d -G "$1" | cut -b23-32` durch SIZE=`ls -l -d -G "$1" | cut -b24-32`
Robuster, da nicht von irgendwelchen Byte-Positionen abhaengig, aber auch langsamer: echo -n `ls -l -d -G "$1" | awk '{print $4}'`
eigentlich gefaellt mir das aber nicht, da ja beim naechsten Systemupdate die Datei ja wieder ueberschrieben werden koennte, oder?
chmod a-w /usr/bin/filesize chattr +i /usr/bin/filesize
Gibt es evtl. noch einen anderen Befehl, mit dem ich die Dateigroesse bestimmen kann?
Man koennte einen kleinen C-Wrapper um lstat() (siehe man 2 lstat)
verwenden:
==== filesize.c ====
#include
Hallo, On Mit, 07 Feb 2001, Jan Trippler wrote:
On Mit, Feb 07, 2001 at 05:36:41 +0100, David Haller wrote: [...]
echo -n `ls -l -d -G "$1" | awk '{print $4}'`
Oder (wie Bernd schon nannte): wc -c "$1" | sed "s/^ *//" | cut -f1 -d" "
Oder: wc -c "$1" | sed 's/^ *\([0-9]*\).*/\1/' *g* CU David -- Braucht Ihr ab oder zunehmen ??? Ich benutze zur Zeit ein total tolles Zeug um abzunehmen. Es geht irre schnell und ist wunderbar. Es ist auch gebrauchlich zum zunehmen. Ihr koenntet auch business tun.....interestan nicht war ??? ['disa_linn@my-deja.com spammt mit viel Hirn in dag°]
On Don, Feb 08, 2001 at 07:55:06 +0100, David Haller wrote:
On Mit, 07 Feb 2001, Jan Trippler wrote:
On Mit, Feb 07, 2001 at 05:36:41 +0100, David Haller wrote: [...]
echo -n `ls -l -d -G "$1" | awk '{print $4}'`
Oder (wie Bernd schon nannte): wc -c "$1" | sed "s/^ *//" | cut -f1 -d" "
Oder: wc -c "$1" | sed 's/^ *\([0-9]*\).*/\1/' *g*
Oder: wc -c "$1" | sed 's/^ *//;s/ .*$//' Dann sind wir wieder kompatibel ;-) David: Rundenzeiten? :-) Jan
Hallo, On Fre, 09 Feb 2001, Jan Trippler wrote:
On Don, Feb 08, 2001 at 07:55:06 +0100, David Haller wrote:
On Mit, 07 Feb 2001, Jan Trippler wrote:
On Mit, Feb 07, 2001 at 05:36:41 +0100, David Haller wrote: [...]
echo -n `ls -l -d -G "$1" | awk '{print $4}'`
Oder (wie Bernd schon nannte): wc -c "$1" | sed "s/^ *//" | cut -f1 -d" "
Oder: wc -c "$1" | sed 's/^ *\([0-9]*\).*/\1/' *g*
Oder: wc -c "$1" | sed 's/^ *//;s/ .*$//' Dann sind wir wieder kompatibel ;-)
David: Rundenzeiten? :-)
*immerich* *bg* Aber mir macht das ja auch Spass und dieses Mal lag ich mit meinen Prognosen sogar richtig ;) Die "wcbash" Variante ist mir (komischerweise) erst jetzt eingefallen... /usr/local/bin/filesize ist dabei die 2te Version (von heute) des wrappers um lstat. /usr/bin/filesize das script von suse ('ls ... | cut -b..'). Das "Testfile" in $1 war ca. 100MB gross. Korrekte Ergebnisse liefern alle Varianten, 'wcbash' habe ich aber nicht weiter ausgetestet, entspricht aber einem 'cut -d" " -f1'. Das Ganze "wie immer" nur als Anregung fuer eigene Test. ;) Plattform: AMD K7/500, 196 MB RAM, ~80 MB "cached". Im unten gemessenen Durchgang fand nicht ein HD-Zugriff statt. ==== test-filesizes.sh ==== #!/bin/bash its=`seq 99` lsawk() { for i in $its; do; echo `ls -l -d -G "$1" | awk '{print $4}'` >/dev/null done } wcsedcut() { for i in $its; do wc -c "$1" | sed "s/^ *//" | cut -f1 -d" " >/dev/null done } wcsed() { for i in $its; do wc -c "$1" | sed 's/^ *\([0-9]*\).*/\1/' >/dev/null done } wcbash() { for i in $its; do s=`wc -c "$1"`; echo ${s% *} >/dev/null done } filsize() { for i in $its; do /usr/bin/filesize "$1" >/dev/null done } fsize() { for i in $its; do /usr/local/bin/filesize "$1" >/dev/null done } init() { for i in $its; do ls "$1" >/dev/null done } for m in init filsize wcsedcut lsawk wcsed wcbash fsize; do echo -n "$m:" time $m $1 done ======== real user sys init: 0m0.580s 0m0.280s 0m0.300s filsize: 0m2.713s 0m1.480s 0m1.220s wcsedcut: 0m1.556s 0m0.770s 0m0.790s lsawk: 0m1.387s 0m0.620s 0m0.720s wcsed: 0m0.974s 0m0.500s 0m0.480s wcbash: 0m0.613s 0m0.320s 0m0.290s fsize: 0m0.341s 0m0.150s 0m0.190s CU David, moege jeder sein Schluesse ziehen :) P.S: ich hoffe das C-Proggie (das hier in fsize aufgerufen wird) von heute funzt sicher... :) Empfehlen wuerde ich aber, wenn man nicht selbst das Proggie verifizieren kann, die wcbash Variante. Hm. Dabei faellt mir auf, eine lsbash Variante fehlt! Ah, z.B: lsbash() { for i in $its; do s=`ls -s --block-size=1 "$1"`; echo ${s% *} >/dev/null done } lsbash: 0m0.610s 0m0.270s 0m0.340s Die Zahlen der anderen Varianten waren dabei aehnlich wie oben, bes. fsize: 0m0.340s, wcbash 0m0.612s, wcsed 0m0.971s Also durchaus vergleichbar. Mich duenkt, als wuerde wc -c schlicht und einfach ebenfalls (wie ls und mein fsize/filesize) auf stat() zurueckgreifen. -- 5: Breitbandkommunikation Porno MPEGs mit Ton (Kristian Köhntopp)
Hi, On Wed, Feb 07 2001 at 17:36 +0100, David Haller wrote:
Man koennte einen kleinen C-Wrapper um lstat() (siehe man 2 lstat) verwenden:
Günstiger wäre meiner Meinung nach stat, denn wer will schon die Größe von Symlinks wissen?
==== filesize.c ==== #include
#include #include #include #include int main(int argc, char** argv) { struct stat *buf = malloc (sizeof(stat)); ^^^^^^^^^^^^
Das muss sizeof(struct stat) heißen. Wenn Du gcc mit der Option -pedantic aufrufst, kriegst Du auch eine Warnung: [sttr]/home/sttr/1> gcc -pedantic ttt.c ttt.c: In function `main': ttt.c:8: warning: sizeof applied to a function type
const char* fn = argv[1]; /* Aufpassen!!! Kann hier ein Buffer-Overflow * auftreten? Nein, oder?? Wolfgang? */
Nein.
if ( lstat(fn, buf)) {
Dafür aber hier, da oben mit malloc zu wenig Speicher reserviert wurde. Ciao, Stefan -- Stefan Troeger o _ _ _ stefan@troeger.st __o __o /\_ _ \\o (_)\__/o (_) _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/ (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
Hallo, On Fre, 09 Feb 2001, Stefan Troeger wrote:
On Wed, Feb 07 2001 at 17:36 +0100, David Haller wrote:
Man koennte einen kleinen C-Wrapper um lstat() (siehe man 2 lstat) verwenden:
Günstiger wäre meiner Meinung nach stat, denn wer will schon die Größe von Symlinks wissen?
Ich. :) Naja, das einzige das sich aendert waere das wegfallende 'l', ist also leicht anzupassen. Oder man baut's als Option ein ;) Oder macht ein "filesize `readlink foo`" ;)
struct stat *buf = malloc (sizeof(stat)); ^^^^^^^^^^^^ Das muss sizeof(struct stat) heißen. Wenn Du gcc mit der Option -pedantic aufrufst, kriegst Du auch eine Warnung:
Autsch. Danke!
Also, die korrigierte Version (hoffe, ich habe keinen neuen
Fehler eingebaut, ggfs. lstat einfach durch stat ersetzen):
==== filesize.c ====
#include
Hi, On Fri, Feb 09 2001 at 18:05 +0100, David Haller wrote:
Also, die korrigierte Version (hoffe, ich habe keinen neuen Fehler eingebaut, ggfs. lstat einfach durch stat ersetzen):
==== filesize.c ==== #include
#include #include #include #include extern int lstat(const char *file_name, struct stat *buf);
int main(int argc, char** argv) { struct stat *buf; const char* fn = argv[1]; if (!fn) { fprintf(stderr,"No filename given.\nUsage: %s FILE\n",argv[0]); return 1; } if ( (buf = malloc (sizeof(struct stat))) == NULL) { fprintf(stderr, "%s\n", strerror(ENOMEM)); /* das geht doch, oder? */
Ja. perror("") tut's aber auch. Man könnte sich noch die ganze malloc-Geschichte schenken, indem man buf als struct stat buf definiert. Ciao, Stefan -- Stefan Troeger o _ _ _ stefan@troeger.st __o __o /\_ _ \\o (_)\__/o (_) _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/ (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
Hallo Stefan, On Sam, 10 Feb 2001, Stefan Troeger wrote:
On Fri, Feb 09 2001 at 18:05 +0100, David Haller wrote: [..]
struct stat *buf; [..] if ( (buf = malloc (sizeof(struct stat))) == NULL) { fprintf(stderr, "%s\n", strerror(ENOMEM)); /* das geht doch, oder? */
Ja. perror("") tut's aber auch.
Hmja. Nur macht das mit leerem Argument nicht viel Sinn. Ich hab' hier grad die Quellen der glibc-2.2 ausgepackt rumfahren und gleich mal in perror.c geschaut (Schreibweise komprimiert): void perror (const char *s) { char buf[1024]; int errnum = errno; const char *colon; if (s == NULL || *s == '\0') s = colon = ""; else colon = ": "; (void) fprintf (stderr, "%s%s%s\n", s, colon, __strerror_r (errnum, buf, sizeof buf)); } Und strerror.c: char *strerror (errnum) int errnum; { static char buf[1024]; return __strerror_r (errnum, buf, sizeof buf); } Ist also wohl gehupft wie gesprungen ;)
Man könnte sich noch die ganze malloc-Geschichte schenken, indem man buf als struct stat buf definiert.
Stimmt. Nochmal danke fuer die Tips und die Korrekturen! CU David -- Das wird aber etwas dauern, denn das, was da prophezeit worden ist, wird einige Zeit brauchen, um erst einmal herauszubekommen, was es denn eigentlich bedeuten soll, damit es dann schließlich eintreten kann. Falls es danach überhaupt noch Lust verspürt, einzutreten. Die Frage wird dann immer noch sein, was das Prophezeite eintreten wird. Eine Tür vielleicht? [Hilko Bengen in dag°]
David Haller wrote:
Hallo,
[Programmcode]
Kompilieren mit:
gcc $CFLAGS -O2 -Wall -ansi -pedantic \ -I/usr/include -o filesize filesize.c
Wenn wir schon pedantisch, dann auch richtig: <pendantic> * Die Angabe von -I/usr/include ist nur in ganz, ganz seltenen Fällen wirklich notwendig, kann aber zu bösen Seiteneffekten [1] führen und wird deshalb generell als schlechter Stil betrachtet. Pedantisch betrachtet, ist es ein Fehler. * -O2 gehört definitiv zu den CFLAGS. Ob -Wall, -ansi, -pedantic auch zu den CFLAGS gehören, darüber kann man sich streiten. Viel Entwickler zählen sie dazu (Ich auch), andere wiederum nicht. * CFLAGS aus Environmentvariablen heraus zu exportieren (export CFLAGS=..) und auf der Command-Line zu verwenden (gcc $CFLAGS) ist eine reichlich fragwürdige Geschichte und sollte man sich besser nicht angewöhnen. [1] Auf allen Systemen ausser glibc und newlib-basierten Betriebssystemen bewirkt gcc -I/usr/include, das die System-includes (/usr/include) Vorrang vor den gcc-eigenen Headern bekommen. Führt auf praktisch allen nicht derartigen Systemen zu Übersetzungsfehlern. </pedantic> Ralf
Hallo, On Sam, 10 Feb 2001, Ralf Corsepius wrote:
Wenn wir schon pedantisch, dann auch richtig:
*g*
* -O2 gehört definitiv zu den CFLAGS. Ob -Wall, -ansi, -pedantic auch zu den CFLAGS gehören, darüber kann man sich streiten. Viel Entwickler zählen sie dazu (Ich auch), andere wiederum nicht.
Klar gehoeren die dazu. Nur mehrfach-Angabe schadet nix. (s.u.)
* CFLAGS aus Environmentvariablen heraus zu exportieren (export CFLAGS=..) und auf der Command-Line zu verwenden (gcc $CFLAGS) ist eine reichlich fragwürdige Geschichte und sollte man sich besser nicht angewöhnen.
Wieso? Der Grund ist, ich habe halt keine Lust immer: "-Wall -O2 -march=i686 -mcpu=athlon -fno-strict-aliasing -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -mwide-multiply" einzugeben ;). Das -O2 usw. schrieb ich dahinter, damit mindestens diese Optionen gesetzt werden, falls jemand keine CFLAGS exportiert hat. Ausserdem erleichtert das (mir) das kompilieren generell sehr, es reicht ein ./configure ... statt einem CFLAGS="[s.o]" ./configure ... Zusaetzlich war die Angabe auch im Sinne eines Platzhalters oder von mir aus auch einer Metasyntaktischen Variablen gemeint, d.h. dass andere dort "ihre" Optionen wie z.B. -march=i586 o.ae. einfuegen. Ansonsten und generell ACK. CU David --
Zusatzfrage: Wo ist der Urschleim, dem das WoKo seine Existenz zu verdanken hat? ||| Der bildet sich allwinterlich in seinen eigenen Bronchien. Das Woko ist also ein biologisches Perpetuum-Mobile. [Dieter Bruegmann und Jürgen Bödecker in dag°]
David Haller wrote:
Hallo,
On Sam, 10 Feb 2001, Ralf Corsepius wrote:
Wenn wir schon pedantisch, dann auch richtig:
*g*
* -O2 gehört definitiv zu den CFLAGS. Ob -Wall, -ansi, -pedantic auch zu den CFLAGS gehören, darüber kann man sich streiten. Viel Entwickler zählen sie dazu (Ich auch), andere wiederum nicht.
Klar gehoeren die dazu. Nur mehrfach-Angabe schadet nix. (s.u.)
<Pendantik-Modus> Mehrfach-Angaben von echten CFLAGS schaden nicht, doch sollten gcc-Driver- (z.B. -B..), Linker- oder Präprozessorflags hineingeraten, .. </Pedantik-Modus>
* CFLAGS aus Environmentvariablen heraus zu exportieren (export CFLAGS=..) und auf der Command-Line zu verwenden (gcc $CFLAGS) ist eine reichlich fragwürdige Geschichte und sollte man sich besser nicht angewöhnen.
Wieso? Es ist extrem fehlerträchtig, da Du die Kontrolle darüber verlierst und es nicht unwahrscheinlich ist, dass Du Dich in einem halben Jahr nur noch diffus daran erinnern wirst, wenn Du nach einem Systemwechsel oder nach einem Login auf einer Sparc/Alpha/Mips/m68k/ix86 plötzlich mit merkwürdigen Übersetzungsproblemen zu kämpfen hast.
Der Grund ist, ich habe halt keine Lust immer:
"-Wall -O2 -march=i686 -mcpu=athlon -fno-strict-aliasing -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -mwide-multiply" Auch über den Sinn dieser Flags kann man streiten. .. werde ich jetzt aber nicht :)
einzugeben ;). Das -O2 usw. schrieb ich dahinter, damit mindestens diese Optionen gesetzt werden, falls jemand keine CFLAGS exportiert hat. Und genau das ist das Hauptproblem: Manchmal werden gewisse CFLAGS bewusst nicht gesetzt. In der Regel wissen die Entwickler eines Paketes besser als der "Casual Installer" warum sie gewisse Flags setzen und warum nicht. So wissen auch die gcc-Entwickler ziemlich genau warum sie gewisse Flags als Default setzen und welche nicht.
Ein weiteres Problem sind Konflikte zwischen deinen exportierten Shell-Variablen und Makefile/configure-Script Shell- bzw. Make-Variablen, z.B.: * Beim Übersetzen/Verwenden von Cross-Compilern/Toolchains: CFLAGS ist nach autoconf/automake Konventionen host-Architektur abhängig (bei Dir offensichtlich Athlon). Solange Du nur für eine Plattform übersetzt, wirst Du kaum Probleme haben, sonst aber ... * Viele Pakete unterscheiden nicht zwischen Präprozessorflags (z.B. -I..), Linkerflags (z.B. -L..) und Compilerflags (z.B. -O2), sondern packen alle Flags in eine Shell- oder Makefile-Variable. Oft wird CFLAGS dazu verwendet. Du wunderest Dich dann später nur darüber, dass irgendetwas nicht so tut wie es sollte, weil Deine Shell-Variable CFLAGS mit den Variablen des Paketes in Konflikt gerät. * Deine CFLAGS sind gcc-spezifisch. Solltest Du sie in ~/profile o.ä. setzen, bekommst Du Probleme wenn Du in einem Netz arbeiten oder auch verschiedene Compiler verwenden solltest.
Ausserdem erleichtert das (mir) das kompilieren generell sehr, es reicht ein ./configure ... statt einem CFLAGS="[s.o]" ./configure ... Ja, beides ist nahezu gleichbedeutend und hat entsprechend auch die gleichen generellen Probleme. Nur, im letzteren Fall gibst Du sie in jedem Einzelfall explizit an und läufst weniger Gefahr in oben erwähnte Probleme zu geraten.
Im Übrigen spielt dies auf einem Einzelplatzsystem so gut wie keine Rolle, in einem (heterogenen) Netz wird es allerdings relevant. Derartige Dinge sind oft die Ursache für "Bei mir daheim tuts, am Arbeitsplatz, an der Uni, beim Kunden, bei meinen Kumpel plötzlich nicht mehr" Fälle :). Ralf
Hallo Ralf, On Son, 11 Feb 2001, Ralf Corsepius wrote:
David Haller wrote: [.. ack soweit..]
* CFLAGS aus Environmentvariablen heraus zu exportieren (export CFLAGS=..) und auf der Command-Line zu verwenden (gcc $CFLAGS) ist eine reichlich fragwürdige Geschichte und sollte man sich besser nicht angewöhnen.
Wieso? Es ist extrem fehlerträchtig, da Du die Kontrolle darüber verlierst und es nicht unwahrscheinlich ist, dass Du Dich in einem halben Jahr nur noch diffus daran erinnern wirst,
Woran? an die gesetzen CFLAGS? echo $CFLAGS...
wenn Du nach einem Systemwechsel oder nach einem Login auf einer Sparc/Alpha/Mips/m68k/ix86 plötzlich mit merkwürdigen Übersetzungsproblemen zu kämpfen hast.
1. habe ich ein Einzelplatzsystem... Und das haben wohl die meisten hier, die dieses Problem nicht (sofort) erkennen wuerden ;)) 2. ist auf der sparc/sunos auf der ich mich machmal einlogge kein CFLAGS in der ~/.bashrc (procmail und wget liessen sich problemlos uebersetzen).
Der Grund ist, ich habe halt keine Lust immer:
"-Wall -O2 -march=i686 -mcpu=athlon -fno-strict-aliasing -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -mwide-multiply" Auch über den Sinn dieser Flags kann man streiten. .. werde ich jetzt aber nicht :)
Das sind (ausser dem fehlenden -fomit-frame-pointers und dem zusaetzlichen, da ich den athlon-patch des pgcc verwende, -mcpu=athlon) genau die, die von den 2.4.x Kernels bei Auswahl von "Athlon/K7" in der Kernel- config gesetzt werden... Und solche, Plattform/CPU-spezifischen Flags sind IMHO doch recht gut in der _Maschinen_-spezifisch gesetzen Variable CFLAGS aufgehoben... Weshalb sonst wuerden soviele Programme mit halbwegs ordentlichen Makefiles diese Umgebungsvariable beachten? Und ggfs. kann sie ja einfach vom Makefile ignoriert werden... Fuer mich ist $CFLAGS genau fuer diesen Zweck gedacht und ideal geeignet. Und ich selbst habe schon Makefiles geschrieben, die die eventuell gesetzte Umgebungsvariable CFLAGS hernehmen, eine kritische oder andere Option (z.B. -fomit-frame-pointers beim kompilieren im debug- Modus mit -g) herausnehmen (mit sed/bash, je nach gewuenschter Plattform/Portabilitaet) aber ansonsten die prozessorspezifischen Flags beachten / drinlassen...
einzugeben ;). Das -O2 usw. schrieb ich dahinter, damit mindestens diese Optionen gesetzt werden, falls jemand keine CFLAGS exportiert hat. Und genau das ist das Hauptproblem: Manchmal werden gewisse CFLAGS bewusst nicht gesetzt. In der Regel wissen die Entwickler eines Paketes besser als der "Casual Installer" warum sie gewisse Flags setzen und warum nicht. So wissen auch die gcc-Entwickler ziemlich genau warum sie gewisse Flags als Default setzen und welche nicht.
Generell, im Prinzip Ack, nur eben bei den Prozessorspezifischen nicht. Es macht einen deutlichen Unterschied, ob ich eine App mit den Default-flags (fuer i386) oder mit o.g. Athlon oder auch nur mit den 'Pentium >= 2'-Flags durch den Kompiler jage. Und diese Flags kann und IMHO sollte ein Entwickler nicht vorgeben. Konflikte lassen sich durch das erwaehnte Uebernehmen + sed usw. oder ein passendes ./configure umgehen. Zudem war der Quelltext um den es ging ein in 5min hingeschluderter, als Anregung gedachter Mehrzeiler (den ich dann in noch ein paar Minute hoffentlich brauchbar gemacht habe ;), fuer den vieles, was du richtigerweise _fuer den generellen Fall_ schreibst, einfach nur totaler Overkill waere... Eigentlich war auch schon die von dir aufgegriffene Zeile Overkill, ein einfaches 'gcc -o foo foo.c' haette auch gelangt...
Ein weiteres Problem sind Konflikte zwischen deinen exportierten Shell-Variablen und Makefile/configure-Script Shell- bzw. Make-Variablen, z.B.: [..]
s.o. Generell ACK, bis auf den "plattform-spezifische Flags"-Fall... (und LDFLAGS habe ich z.B. keine gesetzt)
Ausserdem erleichtert das (mir) das kompilieren generell sehr, es reicht ein ./configure ... statt einem CFLAGS="[s.o]" ./configure ... Ja, beides ist nahezu gleichbedeutend und hat entsprechend auch die gleichen generellen Probleme. Nur, im letzteren Fall gibst Du sie in jedem Einzelfall explizit an und läufst weniger Gefahr in oben erwähnte Probleme zu geraten.
Ack. Beziehe meine Situation (s.o.) ein und du wuerdest sicher auch ein CFLAGS mit _plattformspezifischen_ Flags exportieren ;) Besonders wenn du oefter mal ein Paket kompilierst, das keinerlei optimierende Flags setzt (was ich uebrigens gut finde) aber dennoch eine evtl. gesetze Variable CFLAGS beachtet. Ggfs. setze ich natuerlich ein CFLAGS="" vor den ./configure oder make Aufruf, was wesentlich leichter zu merken ist, als die oben zitierte von mir exportierte Variable ;)
Im Übrigen spielt dies auf einem Einzelplatzsystem so gut wie keine Rolle,
Eben! (scnr)
in einem (heterogenen) Netz wird es allerdings relevant.
ACK. Bis auf die _plattformspezifischen_ Flags! (scnr2)
Derartige Dinge sind oft die Ursache für "Bei mir daheim tuts, am Arbeitsplatz, an der Uni, beim Kunden, bei meinen Kumpel plötzlich nicht mehr" Fälle :).
Ouh. Damit habe ich (zum Glueck?) noch keine Erfahrungen (ausser bei WinDoSxx (siehe Zufallssig *bg*))... Wie gesagt, IMHO setzt derjenige $CFLAGS, der weiss, dass dies evtl. Konflikte verursachen kann... Mag sein, dass ich damit naiv bin... Aber wenn ich nur mal anschaue, was mir beim kompilieren der glibc, der bash, der stdlibc++, ganz zu schweigen von KDE oder GNOME (such dir weitere "Standards" ausser dem Kernel aus) mit einem einfachen -Wall und ggfs. einem Hack des/der Makefiles um eben _nicht_ alle Fehlermeldungen des gcc nach /dev/null umzuleiten, alles an Kompiler-"Warning"s um die Ohren gebretzelt wird, dann kommt mir die von dir angesprochene Problematik wahrlich trivial, oder besser, "ignorierbar" vor... *sad grin* Ein "Compiler-Warnings-Abstell-und-ein-ganz-klein-wenig-aus-anderen-patches- uebernommenes"-patch[1] der bash 2.04 von mir hat schlappe 2421 Zeilen, zugegebenerweise als 'diff -u'... [1] IIRC 2 Stellen aus dem security-patch, den Rest des sec-patches muss ich noch durchgehen. CU David, der dir aber nach wie vor _generell_ Recht gibt! :) P.S: fup2me/suse-talk da OT? PPS: Lather, Rinse... Repeat....... Flush! PPPS: Danke! --
The three "R"s of Microsoft support: Retry, Reboot, Reinstall You forgot one: Repeat -- Mark Atwood, Lars Balker Rasmussen
participants (6)
-
Bernd Brodesser -
David Haller -
Jan.Trippler＠t-online.de -
Knut Pfefferkorn -
Ralf Corsepius -
Stefan Troeger