Shapeshifter schrieb:
Hi,
Also wenn ich diese kleine bash Datei ausführe passiert einfach gar nichts, er beschwert sich nicht mit einer Fehlermeldung o.ä., führt die beiden Zeilen aber auch nicht aus.
Ich kenn mich nicht allzu gut mit diesen Scripts aus; ich dachte bisher ich kann da alle möglichen commands reinpacken die ich sonst auch in der shell manuell ausführe.
Ich probiere die letzte gepostete Variante mal aus, danke für den Tipp.
Das script wird erfolgreich ausgeführt. Nur das problem ist, wenn du ein script-file ausführst wird das script in einer subshell ausgeführt.
Um in der aktuellen shell die ENV-Variable zu ändern musst du entweder, wie schon gesagt den inhalt des scripts in die .bashrc einfügen. Oder per source <script-file> den Inhalt in die aktuelle shell zu exportieren.
$CC enthält den Pfad zur Executable des Compilers, also zB CC=/home/test/gcc-4.1.2/bin/gcc . Da nur den Pfad zu einem Verzeichnis reinzupacken, hilft Dir wohl nicht. Und im Makefile musst Du natürlich auch CC verwenden, statt einfach gcc.
Zu Fortran: http://gcc.gnu.org/wiki/GFortran#manuals
Sorry, ich habe im Inet, auf diversen Seiten und Tutorials geschaut, und da stand das nicht, auf die naheliegenden man-Pages bin ich nicht gekommen.
MEA CULPA ... tut mir leid.
Danke für die Antwort
Gruss Alex
Für alle die Lösung:
Das Problem nennt sich Most Significant Byte first. Eine Bestimmung in der Netzwerktechnik.
ntohs ist in diesem Falle das Zauberwort!
Besteht ein Wert[*] aus mehreren Bytes, wird auf 80x86 Prozessoren das niederwertige Byte vorangestellt (Least Significant Byte first), während man sich im Internet auf die umgekehrte Byteordnung geeinigt hat (Most Significant Byte first). Um von Rechner- auf Netzwerk-Ordnung zu konvertieren, benutzt man die htons() bzw. htonl() Funktionen; umgekehrt benutzt man die ntohs() bzw. ntohl() Funktionen.
htons() und ntohs() konvertieren short integer, die beiden anderen Funktionen konvertieren long integer.
unsigned long int htonl( unsigned long int hostlong );
unsigned short int htons( unsigned short int hostshort );
unsigned long int ntohl( unsigned long int netlong );
unsigned short int ntohs( unsigned short int netshort );
unter linux im header netinet/in.h
// base pointer
const u_char *packet = (const u_char*)ppacket;
// ehternet-pointer
//ether_header *eptr = (ether_header *) packet;
// compute ip-header
sniff_ip *ip = (sniff_ip*) (packet + SIZE_ETHERNET );
u_int size_ip = IP_HL(ip)*4;
// compute tcp-header data
sniff_tcp *tcp = (sniff_tcp*)( packet + SIZE_ETHERNET + size_ip );
u_int size_tcp = TH_OFF(tcp)*4;
long data_length = (ntohs(ip->ip_len) - ( size_ip + size_tcp ));
printf("\nProcess (new) tcp/ip package %i, length %i", (int)packet_counter, (int)data_length);
PS: Für den Port braucht ihr das Ebenfalls. ntohs(tcp->th_sport) / ntohs(tcp->th_dport).
Gruß jayjay
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
was du in einen socket reinschreibst, kommt ja nicht wieder heraus, wenn du davon liest. das mit dem select sollte egal sein. mit select erkennst du im prinzip nur, ob du daten schreiben oder lesen kannst. wenn du daten schreibst, obwohl select das im einen thread noch nicht "erlaubt" hat, wird write wohl lange blockieren, nehm ich an. aber ich muss gestehen, dass ich sowas noch nie ausprobiert habe. wenn du mit select auf daten wartest, ist das komplett egal, wenn du währenddessen daten reinscheibst. lesen und schreiben hat im prinzip auf einem socket nichts miteinander zu tun.
http://gcc.gnu.org/onlinedocs/libstdc++/27_io/howto.html#11
Droogandleader schrieb:
strcpy(m_cam_file,"/dev/video0");
m_cam_stream = new std::ifstream( m_cam_file);
Was machst du da mit new und strcpy? Schaut ja schrecklich aus.
./ schrieb:
nun wie gesagt mbmon war eigentlich bei Freebsd 6.2 und mein rechner das beste progi was brauchbare und vergleichbare daten ausgegeben hat, wie die vom Bios.
ksenors usw ging damals nicht wo ich das schon mal probiert hatte.
sorry hatte Nick vergessen
Weder X noch OGL sind von sich aus Threadsafe X bietet nach XInitThreads() allerdings einen eigenen Locking-Support.
Von OpenAL kann ich's nicht sage, sollte aber hier keine Rolle Spielen, RakNet verwendet selbst Threads und hat nur die Einschränkung, dass man den zugriff Locken muss.
An sich kann es kaum zu races kommen, höchstens wenn ich irgendeinen X / OGL Buffer nicht rechtzeitig geflusht habe
Nun habe jetzt was im netz gefunden da soll man mit
box(fenster, 0, 0) auch eine Linie umherziehen.
Geht auch und die warung ist nun weg.
Gebe aber zu das ich nicht ganz verstehe warum er nun mit 0, 0 auch die linie zieht
Inzwischen hat sich doch eine Loesung gefunden
http://www.easysw.com/~mike/serial/serial.html#5_1_1
Weiter unten wird das bei "Chapter 4, Advanced Serial Programming" erklaert. Naja ist bestimm nicht fuer sowas gedacht wie ich es benutze aber es funktioniert immerhin.
Gr4n@ttr
ºgrimmsenº schrieb:
Also wenn ich meine CPU-Frequenz zur Laufzeit ändere, sehe ich das auch in cpuinfo - sofort.
Ja, weil /proc als Interface zum Kernel fungiert. Die Daten werden eben abgefragt, wenn Du die Dateien dort öffnest. Dazu müssen nicht ständig vom Kernel irgendwelche echten Dateien auf der Festplatte aktualisiert werden.
Selber compilieren ist die beste Methode. Achte darauf, dass du die richtige Version nimmst und folge den Anweisungen im ebuild.
BTW: Falsches Forum! Konfigurationsfragen etc bitte ab jetzt nach "Themen rund um den PC"!
Eine weitere Möglichkeit ist die Verwendung von D-Bus. Damit könntest du dann auch gleich mit dem bereits laufendem Prozess kommunizieren, damit er die Aufgabe macht, die der neue Prozess eigentlich machen sollte (z.B. eine Datei öffnen).