Ich sehe das genauso wie cj@work; was willst Du daran noch groß vereinfachen?
Vielleicht noch irgendwo SOURCE_DIR und TARGET_DIR definieren und eine Liste von zu kopierenden Verzeichnissen, über die Du dann drüber iterierst.
Naja, dass man Backticks nicht so gut verschachteln kann ist klar.
Aber offen gestanden halte ich linu(x)bies ganzes Script für eher blödsinnig; $HOME wird immerhin bereits von man: login(1) gesetzt.
ah jetzt hab ichs :"WNOHANG - der aufrufende Prozess wird nicht blockiert, falls der Kindprozess mit der PID nicht sofort verfügbar ist. waitpid liefert 0 als Rückgabewert."
Da der Prozess beim fork im Speicher geklont wird (ok, mit COW funktioniert das nicht mehr so, aber für die Vorstellung), werden eben auch bereits alles erstellten Variablen und der Stack kopiert. Die Filedeskriptortabelle im Kernel wird natürlich auch mit kopiert.
Hi,
Danke für den guten Hinweis DrGreenthumb. Und wie immer gleich die Lösung für die Suchfunktion.
Quelle test.c:
#include <unistd.h>
#include <stdio.h>
int main()
{
printf("Farben: %d\n",isatty (STDOUT_FILENO));
}
Ausgabe:
~$ ./test
Farben: 1
~$ ./test | less
Farben: 0
linu(x)bie schrieb:
Gibt es da nicht noch einen anderen weg?
nein, darum kommt sowas normalerweise in die ~/.bashrc o.ä., die wird beim einloggen gesourced.
Ansonsten musst du statt aliase kleine einzeiler-scripte verwenden.
ich glaube ich hab eine bessere lösung gefunden...
also die lib liegt jetzt in lib/
so und dann kompilier ich mit:
g++ -o db src/main.cpp -l sqlite3 -L ./lib -Xlinker -rpath ./lib
durch -L findet der linker die lib beim linken und mit -Xlinker gebe ich weitere anweisungen an die linker... -rpath ist der pfad wo das programm beim starten nach den libs suchen soll... in diesem fall aus in dem unterordner lib des ordner wo die executable drin ist.
funzt auch...
trotzdem danke an euch...
bis dann
blaxx
Es ist die Frage, ob da überhaupt brauchbare Werte rauskommen, wenn das Programm nur eine simple rechnung macht.
Was du aber noch bedenken solltest ist, dass Ausgaben meist am längsten brauchen, also, wenn dir es um einen Algorithmus geht, vermeide sämtliche Ausgaben, und lass nur den Code durchlaufen.
Was vielleicht auch möglich wär, einfach intern die Zeit zunehmen und dann einen Aktion 1000 mal aufführen zu lassen, und dann die vergannge Zeit durch 1000 zu nehmen. Dadurch verringert sich auch die Ungenauigkeit durch die Zeitmessung selbst.
rkasel schrieb:
Hat jemand von euch ne Ahnung, wie ich die Kapazität/Anzahl der zu puffernden Messages vergrößern kann?
Ja nach Betriebssystem.
Linux: /proc, oder sysctl
*BSD: sysctl oder kernelconfiguration
Kommerzielle Unixe: sysctl oder kernelconfiguration
Am Beispiel von FreeBSD:
$ sysctl kern.ipc | grep msg
kern.ipc.msgseg: 2048
kern.ipc.msgssz: 8
kern.ipc.msgtql: 40
kern.ipc.msgmnb: 2048
kern.ipc.msgmni: 40
kern.ipc.msgmax: 16384
Die Wertnamen und Bedeutungen selber sind auf den anderen Systemen sehr aehnlich.
--
Andreas
Nehmen wir an du hast die position.txt mit den ORT_XXXX, dann ginge zum Beispiel sowas:
#/bin/sh
while read LOC; do
echo $LOC;
done <position.txt
Andere Variante, die dein grep nutzt:
LOC=`grep ORT_A position.txt`
Ich nehme mal an es hat nen Grund warum du standort.txt erst nach position.txt transformierst, falls das aber nur ein Workaround war, was haelst du hiervon:
#!/bin/sh
save_IFS=$IFS
IFS=:
while read l loc; do
echo $loc;
done <standort.txt
IFS=$save_IFS
(IFS ist der feldtrenner, normalerweise is er space,tab,newline, aber man kann ihn natuerlich auch mal auf ':' setzen).
HTH,
Andreas
Devender schrieb:
Das mit der Umleitung war Zufall - und weil es geklappt hatte hab ich es so gelassen .Aber lasse mir gerne bessere Varianten zeigen.
Bessere Varianten...nuja:
command <in >out 2>error_out
Das is nicht "besser" (es is genau das gleiche von der Wirkung her), aber ueblicher und weniger verwirrend
ProgChild schrieb:
Aber devfs wurde entfehrnt und das ist dynamisch...
Ja, das war aber auch ziemlich mies designed. Richard Gooch dachte ja, dass das irgendwie im Laufe der Zeit aufgeräumter werden würde, dem war aber nicht so, weswegen es entfernt wurde.
also der showkey source sieht schonmal nicht schlecht aus und "laeuft" auch unterm xterm und co. werde mich da mal einarbeiten ^^ ist der code denn auch portabel? also wuerde der auch unter BSD oder anderen POSIX/UNIX systemen laufen?
unter xterm hat der code jedoch nen haken: ich bekomme zig "neuzeilen" ausgegeben, zur laufzeit und auch NACH dem beenden des programms, also muss ich unter X, DrGreenthumb hat es ja schon gesagt, wohl einen anderen ansatz finden...
hat in diese richtung noch jemand einen tipp/hinweis/link/...? vielleicht koennte man ja auch den showkey code so aendern, dass das nicht mehr so ist... ^^
Ist der vor dem Aufruf von newwin() abgeschmiert oder darin?
Wenn es darin ist, wie ist der Code? Wie sehen die übergebenen Werte aus?
Wenn es davor ist, wie ist der Wert von this?
Wie ist der genaue Traceback beim Absturz?