Zeige Ergebnis 1 bis 17 von 17
  1. #1
    Chawki
    Gast

    cd funktioniert bei angehängtem 2>&1 | tee $LOGFILE nicht

    In einem Skript gebe ich das Meiste auch in ein logfile aus, indem ich 2>&1 | tee $LOGFILE ranhänge.
    Bei cd funktioniert das nicht,

    cd foo 2>&1 | tee $LOGFILE

    wird nicht ausgeführt (kein Eintrag im Logfile, kein cd).
    Wieso und kann man trotztdem die Ausgabe vom cd in's Logfile bekommen?


  2. #2
    cirad
    Gast
    > wird nicht ausgeführt (kein Eintrag im Logfile, kein cd).
    cd funktioniert, wird nur in einem anderen Prozess gestartet. Wechsel in ein Verzeichnis ohne Zugriff und das permission denied sollte im Logfile auftauchen.

  3. #3
    edgewalker
    Gast
    Original erstellt von nobody0
    Bei cd funktioniert das nicht,

    cd foo 2>&1 | tee $LOGFILE

    wird nicht ausgeführt
    Doch, wird es. Was glaubst du wie Pipelines funktionieren? Die Shell forkt einen neuen Prozesse sie auszuführen. Rate mal, was für eine Auswirkung es hat, wenn der cd-Befehl nicht im aktuellen Prozess ausgeführt wird...

    Und überhaupt ist dein Konstrukt höchst verwirrend. Auf den ersten Blick ist nicht klar, ob ein relativer Pfad in $LOGFILE auf vor oder nach dem Verzeichniswechsel bezogen ist. (Auch wenn sich das mit ein bisschen Nachdenken erschliesst, aber mit ein bisschen Nachdenken hätte sich auch erschlossen, warum das Konstrukt nicht funktioniert.)

    Und davon mal abgesehen, wenn du sowieso alles loggen willst, warum schreibst du das hinter jeden Befehl? Drückst du gern die Einfügen-Taste? Pack dein gesamtes Skript in einen { ... ; } 2>&1 | tee $LOGFILE Block.

  4. #4
    cirad
    Gast
    Oder nutz script.

  5. #5
    Chawki
    Gast
    Original erstellt von edgewalker

    Doch, wird es. Was glaubst du wie Pipelines funktionieren? Die Shell forkt einen neuen Prozesse sie auszuführen. Rate mal, was für eine Auswirkung es hat, wenn der cd-Befehl nicht im aktuellen Prozess ausgeführt wird...
    Mir geht es nicht um die Pipe; der nachfolgende Befehl wird im falschen Verzeichnis ausgeführt, obwohl die Pipe da längst beendet ist.

    LOGFILE ist mit einem absoluten Pfad definiert.


    Original erstellt von edgewalker

    Und davon mal abgesehen, wenn du sowieso alles loggen willst, warum schreibst du das hinter jeden Befehl? Drückst du gern die Einfügen-Taste? Pack dein gesamtes Skript in einen { ... ; } 2>&1 | tee $LOGFILE Block.
    Ok, ich probiere das mal aus ...

  6. #6
    cirad
    Gast
    Original erstellt von nobody0
    Mir geht es nicht um die Pipe; der nachfolgende Befehl wird im falschen Verzeichnis ausgeführt, obwohl die Pipe da längst beendet ist.

    LOGFILE ist mit einem absoluten Pfad definiert.
    Davon stand da aber kein einziges Wort.

    Und das zweite Kommando wird nicht nach dem ersten und "nach der Pipe" ausgeführt, sondern zeitgleich gestartet. Wo soll sonst auch stdin hingeschoben werden.

    Was gibt denn "... | echo $LOGFILE" aus?

  7. #7
    Chawki
    Gast
    Original erstellt von cirad

    Was gibt denn "... | echo $LOGFILE" aus?
    Nichts, obwohl das Kommando der nächsten Zeile nicht in dem Verzeichnis ausgeführt wird, in das anscheinend fehlerfrei mit cd gewechselt wurde.
    Deshalb sieht es so aus, als würde cd nicht funktionieren.
    Kann man das störende forken der Shell nicht abstellen?

  8. #8
    edgewalker
    Gast
    Original erstellt von nobody0
    Kann man das störende forken der Shell nicht abstellen?


    Wenn du nicht willst, dass Pipes möglich sind, kannst du das "störende" Forken gern abschalten.

  9. #9
    Chawki
    Gast
    Das meine ich nicht; ich hätte nur gerne ein pthread_create statt fork.

  10. #10
    edgewalker
    Gast
    Und dann, Herr Oberchecker? Wie willst du die anderen Programme ausführen?

  11. #11
    Chawki
    Gast
    Beispielsweise mit system

    Also ich vermisse eine Option mit der man von forken auf threaden umstellen kann.

  12. #12
    edgewalker
    Gast
    Weisst du, was system() tut?

  13. #13
    Chawki
    Gast
    Ja, ist ja im ANSI-Standard spezifiziert, dass die Details implementationsabhängig sind.

  14. #14
    cirad
    Gast
    So unterschiedlich wird es nicht sein, oder? Zumindest nicht in der Linuxwelt.

  15. #15
    edgewalker
    Gast
    Um dir die Mühe des Nachdenkens zu ersparen... system() ist ein Wrapper um fork(), exec() und waitpid().

    Unter Unix werden andere Programme durch exec() ausgeführt. exec() ersetzt dabei das im aktuellen Prozess laufende Programm durch ein anderes.

    Jetzt erklär mir doch bitte, wie du ohne fork() andere Programme aufrufen willst...

  16. #16
    Chawki
    Gast
    Original erstellt von edgewalker
    Jetzt erklär mir doch bitte, wie du ohne fork() andere Programme aufrufen willst...
    Dafür muß man doch nur main der betreffenden Funktion aufrufen, beispielsweise so für void main(void):

    (*(void (*)()) (ADDRESS)) ();

    wobei ADDRESS die Adresse vom betreffenden main ist.

  17. #17
    edgewalker
    Gast
    Ach so, du willst also zwei Prozesse in einem Adressraum betreiben. Die sollen sich gegenseitig in den Speicher und quer über ihre Filehandles schreiben können. Wieso bleibst du nicht bei Windows95?

    Und abgesehen davon müsstest du dafür alles, was exec() tut (also dynamische Links auflösen etc), im Userspace nachprogrammieren (Sourcecode gibt's ja!). Und das in ein Anwendungsprogramm einbauen. Wozu brauchst du dann eigentlich einen Kernel?

Forumregeln

  • Es ist dir nicht erlaubt, neue Themen zu verfassen.
  • Es ist dir nicht erlaubt, auf Beiträge zu antworten.
  • Es ist dir nicht erlaubt, Anhänge hochzuladen.
  • Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
  •