Zitat von hal

Nichts gegen eine Krankheit tun zu wollen, die definitiv nachweisbar ist und auch nachweisbar eine hohe Todesrate hat, ist aber ebenfalls nicht intelligent.

das ist nun mal das bloede an einer sucht, die man nicht mit einer normalen krankheit gleichsetzen kann. denk an jemanden der gerne sport macht, aber probleme mit dem knie bekommt. natuerlich wuerde dieser jemand aber weiterhin gerne sport machen, somit geht er zum arzt, laeszt sich heilen, und macht dann wieder die beschaeftigung die ihm spasz macht. beim rauchen ist das komplett anders. man muss sich etwas heilen lassen, das man ansich gerne macht. man mueszte sich, um bei dem vorigen beispiel zu bleiben, den sport abgewoehnen nicht die krankheit. dazu kommt noch, dass man bei einer normalen krankheit nach der heilung wieder das machen kann was einem spasz macht. raucher, auch wenn es falsch ist, sehen rauchen nun mal als spasz/genuss, und wenn du damit aufhoerst, ist das etwas das nur funktioniert hat, wenn du es dein restliches leben durchhaeltst. es ist also nicht -- wie eine "normale" krankheit -- etwas das man temporaer aussitzen kann um nachher wieder wie gewohnt weiter zu machen.
im uebrigen ist es meist eine frage des "koennens", und der damit verbunden motivation, und nicht eine frage des "wollens".

Zitat von pernhard

wtf?

-v bitte!

Paulchens loesung war in brainfuck, "meine" war in whitespace. ich hoffe das ist verbose genug.

Paulchen, seit wann ist brainfuck C?
C ist aber manchmal brainfuck.
whitespace darf nicht fehlen!

und so iterativ:

int erg=1;
int zahl=5;
int i;


for(i = 2; i <= zahl; i++)
   erg *= i;

Zitat von hagbardceline

Unterste Schicht ist vielleicht leicht missverständlich - du verwendest mit nslookup "reines" DNS, und das ist ein Anwendungsschichtprotokoll d.h. mit nslookup verwendest du die alle Schichten des Netzwerkschichtmodells. deshalb fängt man ja auch mit ping an, das testet nur die ersten 3 Schichten

"unterste ebene" war eher auf auf den programmablauf bezogen. zuerst ("unten") dns eintrag suchen, dann ("oben") das service anbieten. dass man mit nslookup nicht direkt am physical layer aufsetzt habe ich schon vermutet

ich wuerde so lange rum spielen, bis eine adresse scheinbar nicht aufgeloest werden kann und dann mein glueck mit 'nslookup' versuchen. dann weiszt du ob es am DNS liegt, oder doch an der applikation. aber du deckst mit nslookup mal die unterste ebene ab.

Zitat von mtintel

192.168.1.101 Win Notebook (zu dem ich mich verbinden möchte)
192.168.142.128 MacBook Win (virtuell) (das ist irgendwie ne komische IP, scheinbar weil es virtuell läuft)
192.168.1.113 MacBook OS X (auf dem ich bin und zum Win Notebook conecten möchte)

Da das mit dem virtuellen Windows zum überprüfen nicht hin haut da der scheinbar eine nicht geeignete IP hat, bleibt mir nur weiter der Versuch mit Mac OS.

a geh, das wird schon so passen. die VM NATet das interface schon durch... kannst vom macos die richtige windosn pingen? vom virtuellen xp den mac? kannst vom virtuellen xp die windosn pingen? so wuerd ich mal anfangen. dann nmapen auf den port, dann vlt noch ein telnet auf den rdp port.

Zitat von hal

es arbeitet sich wie lokal (nur Computer ausschalten geht nicht).

warum nicht? geht das nur bei den terminal services der MS server, aber nicht bei den desktop betriebssystemen? musst zum abdrehen immer eine VNC verbindung aufbauen

Zitat von Rizzit

Also die Basis-Tutorials hab ich mal durchgenommen und mich gestern insgesamt 6 Stunden damit befasst.

natuerlich viel zu wenig um eine sprache wirklich zu kennen/koennen, aber das ist dir sicher selbst klar

Zitat von Rizzit

Ich würd mal gerne wissen welche Schritt erforderlich sind um mit Python ein einfaches Program zu schreiben (.exe) das nacher ein normales jpg Bild aufmacht mit einem begrüßungs text und eventuell noch eine mp3 dazu abspielt.

haengt mit meiner ersten antwort zusammen. lern zuerst mal wirklich nur die sprache selbst. schau dass du mit listen, dicts, python spezifischen nettigkeiten umgehen kannst. dann zu funktionen, dann zu klassen. erst wenn du das wirklich verstehst, macht es sinn den schritt zu grafischen anwendungen zu gehen.
.exe brauchst du nicht, kannst aber wenn dein projekt fertig ist ein package baun. fuer windows gibt es py2exe um so etwas zu machen. das packt dir all das was dein programm benoetigt in ein verzeichnis. interpreter, libs,...

wenn du GUIs schreiben willst, dann musst du dich zuerst mal fuer ein widget toolkit entscheiden. python hat zb guten support fuer gtk und qt.

Zitat von Rizzit

So Schwer dürfte das doch nicht sein oder? bin ein sehr lern motivierter Mensch, allerdings lern ich meistens schneller wenn ich eine Vorlage hab die ich mit verständlicher Erklärung nachbauen kann (Visual-Spatial Thinking).

ich hab vor kurzem ein imo recht gutes buch dazu gelesen: rapid gui programming with python and qt. auf dieser seite kann man sich den code zu den programmen im buch runter laden. vlt. hilft ja auch das schon weiter. das buch gibt einen guten ueberblick ueber python und grafische programmierung. es wird zwar dazu geraten, dass man programmiererfahrung haben sollte um das buch zu verstehen, aber ich denke mit ein wenig motivation gehts auch so.
auf dieser seite findest du auch ein paar einfache howtos zu pyqt.

na da herrscht ja ziemlich grosze einigkeit. vba wuerde ich nicht angreifen, C/C++ finde ich etwas stressig fuer den anfang. ich wuerde auch zu python raten. eine wirklich schoene sprache mit der man schnell und einfach etwas umsetzen kann. auch grafische anwendungen hat man in kuerze mit hilfe von pygtk bzw pyqt (was ich bevorzuge) recht schnell gebaut. fuer alles gibt es bindings und berge an libs.
frueher habe ich perl ganz gerne genommen wenn es um dateiverarbeitung/strings/regex ging, aber so wirklich gern hab ich perl nie angegriffen. php und ruby sind auch gute einstiegspunkte. ruby zieht den objektorientierten ansatz wirklich durch, ich fuehle mich bei python aber wohler (vlt. weil ich sonst ziemlich viel C programmiere?).
kurzum: nimm python und du wirst gluecklich werden

bei mir ging das mit der mac version vom rdp client immer problemlos. vnc ist sonst eine gute moeglichkeit, wenn auch arsch langsam.

Zitat von davewood

das nervige is halt dass ich immer osx booten und dann rebooten muss weil er mich nicht in die Bootauswahl vom Bootcamp lasst, USB Keyboard no ned initialisiert oder sowas ähnliches vermute ich.

ich habe zwar noch einen alten ppc mini, aber das mit der tastatur kommt mir bekannt vor. bei mir reagiert das ding nur wenn die tastatur am richtigen usb haengt. mein mini hat 2 usb anschluesse und nur auf einem reagiert er von anfang an auf die tastatur (zb wenn ich 'c' druecke um von der cd zu starten). er reagiert auch nicht wenn ich zwar am richtigen eingang haenge aber ein usb-hub dazwischen ist. probier mal die tastatur an einen anderen usb eingang zu haengen.

Zitat von michi204

wieso schließt du den schon vor dem fork()? das parent soll ihn ja weiter erwenden, es würde also reichen, die fds im kind zu schließen, oder habe ich da jetzt was übersehen?

berechtigte frage, aber im wirklichen programm gehts imho nicht anders. in dem beispielcode schaut das ganze ziemlich ungeschickt aus, keine frage, aber im richtigen programm "muss" ich schon vorher die deskriptoren zu machen. ich parse am anfang die optionen/argumente mit getopt und sobald "--daemon" daher kommt forke ich das erste mal in den background (insgesamt sind es 3 forks die daherkommen). und erst viel viel spaeter kommt dann die geschichte mit dem lesen eines anderen programms. somit ist es keine option einfach mal zu warten bis ich etwas lesen mag und dann schlau zu forken und dann schlau zu schlieszen. zu dem zeitpunkt hat das programm schon lange als daemon zu laufen, da es zb auch ueber startup-skripte gestarte werden kann. aber wie gesagt, ich werde einfach in daemonize() die notwendigen deskriptoren aurecht erhalten und alles ist im lot.

erstmal danke fuer die antwort.

Zitat von michi204

ich fürchte, auch mit guten heuristiken würde es die von dir gesuchte magische get_stdout()-funktion nicht schaffen zu eruieren, was du denn gerne als neuen stdout hättest (den alten gibts ja dann nicht mehr).

sehe ich genau so. es wuerde mich wundern wenn es die magie gaebe, aber ich habe gehofft es kennt vlt. jemand einen C-trick, der mir noch nicht unter gekommen ist.

Zitat von michi204

i
schau dir mal

Code

ls -l /dev/stdout

an, das erklärt, warum freopen() nicht geht.

jop, hab ich gemacht und es ist mir auch vollkommen klar warum es so nicht funktioniert. das einzige was geht ist ein backup machen, dann bis aufs backup closen, mir "/dev/fd/$BACKUP" zusammenbaun und ein freopen machen. aber das waer ja unlustig, ich will ja alle schlieszen, auch das backup

Zitat von michi204

und wie liest du dann von deinem dämon aus über stdin/out von einem anderen prozess daten ein? bzw. wozu brauchst du da stdin/stdout, du kannst ja einfach so ein(e) datei/pipe/socket öffnen. oder anders gefragt, was ist denn bei dir stdin und stdout für den dämon?

ich denke das funktioniert nicht so einfach. bitte korrigiert mich wenn ich in sysprog nicht gut aufgepasst habe, aber ich lege die pipe an, forke meinen daemon und rufe dann im parent ein exec auf. ueber das aufgerufene parent programm habe ich nicht wirklich kontrolle, dem kann ich auch nicht sagen dass es auf pfd (den ich durch pipe() erzeugt habe) schreiben soll. dieses programm schreibt einfach auf "seinen" stdout. den hab ich aber vorher geschlossen (weit vor dem fork).

ich zeigs dir anhand folgendem test-code.
dummy.c: ueber das programm habe ich keine keine kontrolle, das ist einfach so vorhanden:

#include <stdio.h>


int main(int argc, char **argv)
{
    printf("%s spricht\n", argv[0]);


    return 0;
}

daemon.c: so ist ca mein daemon aufgebaut. das daemonize() wird einfach durch das schlieszen der deskriptoren 0-9 simuliert:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <strings.h>


#define SIZE 1024


int main(int argc, char **argv)
{
    int pfd[2];
    int pid,i;
    int nread;
    char buf[SIZE];


    /* SIMULATE daemonize() */
    /* for(i = 0; i < 10; i++) */
    /*    close(i); */


    if (pipe(pfd) == -1)
    {
        perror("pipe failed");
        exit(EXIT_FAILURE);
    }


    if ((pid = fork()) < 0)
    {
        perror("fork failed");
        exit(EXIT_FAILURE);
    }
    if (pid == 0) /* child */
    {
        close(pfd[1]);
        dup2(pfd[0], STDIN_FILENO);
        bzero(buf, SIZE);
        while ((nread = read(pfd[0], buf, SIZE)) != 0)
        {
            printf("got input:%s",buf);
        }
        exit(EXIT_SUCCESS);
    } 
    else /* parent */
    {
        close(pfd[0]);
        dup2(pfd[1], STDOUT_FILENO);
        close(pfd[1]);
        execlp("./dummy", "dummy",
                (char *) 0);
        exit(EXIT_SUCCESS);
    }
    return EXIT_SUCCESS;
}

das funktioniert so auch ganz gut wenn man "daemon" startet, nur sobald man die die zwei zeilen fuer das simulierte daemonize auskommentiert spricht gar nix mehr.

ich habe ein programm das sich per commandline-switch auch in einem daemon modus betreiben laeszt. die daemonize() funktion ist nicht sonderlich spannend, im prinzip ein fork() in dem sich der parent prozess verabschiedet und das child weiter laeuft. zusaetzlich noch ein paar signal-handler, chdir, umask usw. wie ich in einem beispielcode gesehen habe werden fuer den daemon auch alle file deskriptoren geschlossen, was mir recht sinnvoll erscheint. wenn schon daemon, dann gscheit. die anzahl der maximalen deskriptoren hole ich mir per sysconf() und mach dann auf jeden einzelnen ein close(). soweit so gut. nur brauche ich zu einem spaeteren zeitpunkt wieder funktionierende 'stdin' und 'stdout', da ich den output von einem anderen prozess lesen will. auch hier wieder die klassiker aus sysprog (pipe, fork, dup2, close, exec). nur wie komme ich zu diesem zeitpunkt wieder an funktionierende 'stdin' und 'stdout'?

prinzipiell gibt es 2 moeglichkeiten die mir eingefallen sind:
*) ich mach alle deskriptoren bis auf stdin/out zu.
*) ich sichere mir die 2 deskriptoren, schliesze alle bis auf die beiden und mache dann ein freopen.

beides, vor allem ersteres, moeglichkeiten die funktionieren und fuer meine zwecke absolut ausreichend sind, aber kann es sein, dass man nach dem schlieszen _aller_ deskriptoren keine moeglichkeit mehr hat wieder an neue stdin/outs zu kommen? da weisz doch sicher jemand eine schoene moeglichkeit. aja, das ganze soll ausschlieszlich unter gnu/linux laufen, also portabilitaet ist nicht so wichtig. und ein freopen("/dev/stdout,"w",stdout) funktioniert nicht.

mfg. kampi

Zitat von Clownfish

weiß aber jetzt nicht wie ich mir den proxy bau.

steht ansich in der docu. den proxy startest du ueber ein perl script:

#!/usr/bin/perl


use HTTP::Proxy;
use HTTP::Recorder;


my $proxy = HTTP::Proxy->new();


# create a new HTTP::Recorder object
my $agent = new HTTP::Recorder;


# set the log file (optional)
$agent->file("/tmp/myfile");


# set HTTP::Recorder as the agent for the proxy
$proxy->agent( $agent );


# start the proxy
$proxy->start();


1;

dann browser starten, dort den proxy einstellen und surfen. dann sollte dir das ding ein www::mechanize perl-script in "/tmp/myfile" ablegen. das startest du dann wie ein ganz normales perl programm. ist aber schon jahre her dass ich das selbst gemacht habe, aber es duerfte so schon ganz stimmig sein.

Zitat von Clownfish

danke danke!!

ja der sack hat sicher son script!!

und ich check ned wie das geht... :wein:

ich hab leider gerade keine zeit, sonst wuerd ich dir das schnell stricken, aber du musst das www::mechanize script nicht selber schreiben. du kannt dir mit http::recorder einen proxy erzeugen, dann surfst du ganz gewoehnlich (zeichnest also deine aktivitaet auf) und der recoder erzeugt dir automatisch ein www::mechanize script, das du dann beliebig abspielen kannst. ich hab wenig damit gemacht, aber ganz gute erfahrungen gesammelt.

hier die docu zu http::recorder:
http://www.perl.com/pub/a/2004/06/04/recorder.html?page=1

hth

ich hab jetzt 3 mal fuer dich gestimmt, die IP wird also anscheinend nicht geloggt. was folgert der informatiker draus? an den editor und WWW:Mechanize angrissn und dein count sollte in die hoehe gehn...

Zitat von Martinez

aber das ist das grosse leid der informatiker; wissen halt nur von einem bescheid, zwar von dem irre viel, aber vom rest gar nix.

echt jetzt? gibt es auszerhalb meines zimmers noch eine welt? ich habe davon gehoert, aber ich dachte bis jetzt immer die realitaet ist nur was fuer leute die im internet keine freunde finden. erleuchte uns!

Zitat von Martinez

der halt noch andere sachen im kopf hat als maschinen.

turing ftw!

Zitat von Paulchen

Dann sabbern die Leute halt der Software hinterher und nicht mehr der Hardware.

und recht haben sie! das macos ist einfach wichtig und toll. ohne haett ich nicht mal den deppadn startup sound bei meinen macs ausschalten koennen. gnu/linux loesung gibt es da leider nicht. mehr verwendung hab ich fuers osx noch nicht gefunden, aber das wird ja wohl reichen!