Ich würde alle Ausgaben des Skripts in eine "Logdatei" umleiten. Die "Logdatei" kannst du dann in dein $HOME verschieben und mit chown anpassen.

Oder du schickst dir die "Logdatei" per Email.

Oder du logst alle Meldungen unter /var/log. Du kannst dir auch eine systemd-Unit basteln und das Skript dann mit systemctl start skript.service starten.

Es gibt auch die Möglichkeit, zuerst eine tmux-Sitzung zu öffnen und das Skript darin aufzurufen. Dann sollten die Ausgaben erhalten bleiben, solange die tmux-Sitzung erhalten bleibt.

Es gibt viele Möglichkeiten, das "professionell" anzupacken. Nur ein paar Ideen für die kommenden Festtage.

fdell damit ich eventuelle Meldungen sehe?

su
<passwort>
echo "Meldung"

Meldung

Auch eingeloggt als root zeigt das terminal die Befehlsausgaben an.

ich überlege ob es grundsätzlich eine gute Idee ist, soviel Aufwand zu betreiben um den normalen USER mit extra Privilegien auszustatten, stattdessen ein "su -l" in der Konsole eingeben und ich bin da wo ich hin will.

Die Frage ist jetzt, kann ich meine gewohnten aliases der "~/.bash_aliases" weiter verwenden?
Ich habe zwar die Syntax der grundlegenden Programme (pacman, systemctl usw.) basal gespeichert, jedoch bin ich auch bequem und möchte nicht jedes mal den ganzen Aufruf/Befehl eintippen müssen...

Kann ich für root eine bash_aliases schreiben und diese in "/etc/bash.bashrc" verlinken?

if [ -f /root/.bash_aliases ]; then
    . /root/.bashrc
fi

Oder ist das sicherheitstechnisch weniger sinnvoll?

Ich persönlich habe keinen einzigen alias und rede mich selbst immer noch mit eigenem Namen an. 😉
Die drei Befehle sind schneller in die Konsole getippt, als darüber nachzudenken welche Abkürzung man für was, wann eingerichtet hat. Meine 1,5 Cent.

Ich verzichte auf sudo und nutze su -l.
Im root Ordner habe ich nun eine .profile und eine .bash_aliases erstellt und alles funktioniert soweit.
Die NOPASSWD Zeile in /etc/sudoers ist leer und eigentlich könnte ich sudo jetzt deinstallieren.

Ich lasse das Thema offen, da mir (und anderen) bestimmt noch ein paar Anfängerfragen zu bashskripten einfallen werden. Ich finde es z.B. immernoch eine gute Idee, Start und Ausgaben eines root-skripts per notify-send an den normalen USER zu senden bzw. einzublenden. Da muss ich noch einiges lesen...

Das war eine Menge input zu bashskripten in den letzten Tagen und ich bin immer noch am nachlesen was @GerBra und @Gerry_Ghetto mir vermitteln wollten. Danke an alle, die so nett unterstützt haben :-)

4 Tage später

Hallo zusammen,
ich nutze ein etc-hosts file um Werbung heraus zu filtern.
Die Datei lade ich von dieser URL https://hosts.ubuntu101.co.za/hosts
Ein systemd *.timer startet einen *.service mit dem skript zum herunterladen der hosts-datei.

Das Problem ist, das Skript bricht ab, wenn dieser Verbindungsfehler kommt:

--2024-01-04 10:56:13--  https://hosts.ubuntu101.co.za/hosts
CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Auflösen des Hostnamens hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)… 2a01:4f8:140:5021::5, 2a01:4f8:140:5021::39, 88.198.70.39
Verbindungsaufbau zu hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)|2a01:4f8:140:5021::5|:443 … fehlgeschlagen: Keine Route zum Zielrechner.
Verbindungsaufbau zu hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)|2a01:4f8:140:5021::39|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 19505850 (19M) [application/octet-stream]
Wird in »hosts.2« gespeichert.

Hat jemand eine Idee, wie ich das Skript anpassen kann,
damit es nicht nach diesem Verbindungsfehler abbricht?

Das download skript:

#!/bin/sh

# Make sure we're running as root
if 
(( `id -u` != 0 )); then { echo "Sie haben keine Root Rechte, beende..."; exit; } 
fi

cd /tmp
wget https://hosts.ubuntu101.co.za/hosts

head -400 hosts | grep --quiet ^127.0.0.1
if (( $? != 0 )); then
   echo "Error: Falsche hosts Download-Liste"
   exit 1
else
   cp hosts /etc/hosts
fi
  • Martin-MS hat auf diesen Beitrag geantwortet.

    fdell Das Problem ist, das Skript bricht ab, wenn dieser Verbindungsfehler kommt:

    Ich sehe da noch keinen Verbindungsfehler. Die Anfrage wird in zwei IPv6- und einer IPv4-Adresse(n) aufgelöst. Die Verbindung nach ::5 schägt zwar fehl, aber nach ::39 ist erfolgreich, es wird "verbunden" mit Status 200 gemeldet und der Download findet statt.

    An welcher Stelle bricht das Skript denn ab?

    fdell Hat jemand eine Idee, wie ich das Skript anpassen kann,
    damit es nicht nach diesem Verbindungsfehler abbricht?

    Du könntest den resultcode von wget mit $? abfragen; wenn der <> 0 ist, war die Verarbeitung nicht erfolgreich und du könntest darauf entsprechend reagieren.

    Außerdem würde ich wget noch die Downloadoption -O hostsübergeben, damit sowas

    Wird in »hosts.2« gespeichert.

    nicht passiert.

    • fdell hat auf diesen Beitrag geantwortet.

      Martin-MS Der Fehler tritt nicht immer auf, aktuell tritt er nicht auf.
      Aber zur vorgesehenen Uhrzeit (06:00Uhr) tritt dieser Fehler auf
      wenn das Skript per *.service oder *.timer getriggert wird:

      [root@arch1 ~]# ctlstat upd_hosts.service
      × upd_hosts.service - update etc-hosts file daily at 06:00 CET
           Loaded: loaded (/etc/systemd/system/upd_hosts.service; static)
           Active: failed (Result: exit-code) since Tue 2024-01-02 09:33:02 CET; 28min ago
         Duration: 153ms
      TriggeredBy: ● upd_hosts.timer
          Process: 517 ExecStart=/usr/local/bin/upd_hosts.sh (code=exited, status=1/FAILURE)
         Main PID: 517 (code=exited, status=1/FAILURE)
              CPU: 90ms
      
      Jan 02 09:33:02 arch1 systemd[1]: Started update etc-hosts file daily at 06:00 CET.
      Jan 02 09:33:02 arch1 upd_hosts.sh[522]: --2024-01-02 09:33:02--  https://hosts.ubuntu101.co.za/hosts
      Jan 02 09:33:02 arch1 upd_hosts.sh[522]: CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
      Jan 02 09:33:02 arch1 upd_hosts.sh[522]: Auflösen des Hostnamens hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)… fehlgeschlagen: Temporärer Fehler bei der Namensauflösung.
      Jan 02 09:33:02 arch1 upd_hosts.sh[522]: wget: Host-Adresse »hosts.ubuntu101.co.za« kann nicht aufgelöst werden
      Jan 02 09:33:02 arch1 upd_hosts.sh[534]: head: 'hosts' kann nicht zum Lesen geöffnet werden: Datei oder Verzeichnis nicht gefunden
      Jan 02 09:33:02 arch1 upd_hosts.sh[517]: Error: Falsche hosts Download-Liste
      Jan 02 09:33:02 arch1 systemd[1]: upd_hosts.service: Main process exited, code=exited, status=1/FAILURE
      Jan 02 09:33:02 arch1 systemd[1]: upd_hosts.service: Failed with result 'exit-code'.

      Aha, also wenn das Skript manuell aufgerufen wird tritt der Fehler nicht auf, aber wenn er als systemd.service gestartet wird.

      Ich habe beides, Skript und Unit mal in einer VM installiert und ausgeführt, da lief es auch als systemd.service problemlos.

      wget soll allerdings Probleme mit rekursiven Namensauflösungen haben. Das erklärt aber noch nicht, warum es beim manuellen Aufruf funktioniert und aus einem systemd.service nicht; eigentlich müsste es immer laufen oder nie.

      Du kannst es mal statt wget mit curl versuchen, das läuft ähnlich, da musst du aber explizit die -o-Option setzen, damit der Output in eine Datei und nicht im Terminal ausgegeben wird. Möglicherweise kommt systemd damit besser zurecht.

      da der Fehler

      Jan 02 09:33:02 arch1 upd_hosts.sh[522]: Auflösen des Hostnamens hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)… fehlgeschlagen: Temporärer Fehler bei der Namensauflösung.
      Jan 02 09:33:02 arch1 upd_hosts.sh[522]: wget: Host-Adresse »hosts.ubuntu101.co.za« kann nicht aufgelöst werden
      Jan 02 09:33:02 arch1 upd_hosts.sh[534]: head: 'hosts' kann nicht zum Lesen geöffnet werden: Datei oder Verzeichnis nicht gefunden

      Morgens um 6 Uhr bzw. gehäuft vormittags auftritt, könnte es doch auch am Server liegen der nicht antwortet oder? Der Server ist ziemlich langsam, Downloadspeed ist unter 500kb/s. Vielleicht kommen vormittags zuviele Anfragen an der ipv4 Adresse an?

      Gegen Mittag hin funktioniert es häufiger ohne Verbindungsfehler. Die Option -O hosts habe ich eingefügt (wget). Es wurde aber auch ohne diese immer in die /etc/hosts geschrieben, egal was im Terminal angezeigt wurde. Eine "hosts.2" o.ä. wurde nie angelegt.

      • Martin-MS hat auf diesen Beitrag geantwortet.

        fdell Morgens um 6 Uhr bzw. gehäuft vormittags auftritt, könnte es doch auch am Server liegen der nicht antwortet oder?

        Die Verbindung zum Server kommt wegen der fehlgeschlagenen Namensauflösung gar nicht erst zustande. Wenn er nicht erreichbar wäre, sähe der Fehler je nach Ursache anders aus.

        fdell Eine "hosts.2" o.ä. wurde nie angelegt.

        In deinem Beispiel weiter oben aber schon. Die Dateien werden von wget mit Zahlen erweitert, wenn mehr als eine Datei im Zielverzeichnis existiert. Wenn also aus irgendeinem Grund die Verarbeitung abbricht oder wiederholt wird, steht die letzte gültige Datei wie in diesem Fall in hosts.2. Nach einem Abbruch und Wiederholung würde eine unvollständige Datei nach /etc/hosts geschrieben, deswegen ist es sicherer, die Ausgabedatei ausdrücklich als Option dem Aufruf zu übergeben.

        • fdell hat auf diesen Beitrag geantwortet.

          Martin-MS Sorry, ich muss das immer erst nachlesen...
          Das hatte ich garnicht verstanden, weil ich nur die /etc/hosts monitored hatte. Da das Skript zuerst nach /tmp und dann nach /etc/hosts kopiert ist mir nicht aufgefallen, das wohl tatsächlich eine "hosts2" angelegt wurde. Die Option -O hosts habe ich eingefügt (wget) und das Skript abgeändert:

          #!/bin/sh
          
          # Make sure we're running as root
          if 
          (( `id -u` != 0 )); then { echo "Sie haben keine Root Rechte, beende..."; exit; } 
          fi
          
          cd /tmp
          wget -O hosts https://hosts.ubuntu101.co.za/hosts
          head -400 hosts | grep --quiet ^127.0.0.1
          if (( $? != 0 )); then
             echo "Error: Falsche hosts Download-Liste"
             exit 1
          else
             mv hosts /etc/hosts
          fi

          Das Problem liegt leider am DNS Server. Ich habe in meiner Fritzbox den DNS-Server von "Cloudflare" und "DNS over TLS (DoT)" eingerichtet. Dies führt dazu, dass die Namensauflösung temporär nicht funktioniert.

          Wenn ich das Skript oder den *.service manuell starte, funktioniert es komischerweise fehlerfrei bei der Namensauflösung. Wenn ich in der Fritzbox-config den DNS-Server auf "Vom Internetanbieter zugewiesene DNSv4-Server verwenden (empfohlen)" ändere, funktioniert das ganze per *.timer oder *.service ebenfalls problemlos.

          Ich lasse den *.timer & *.service jetzt weg und starte das Skript manuell, da ich nicht auf den DNS-Server und "DNS over TLS (DoT)" verzichten möchte.

          • GerBra hat auf diesen Beitrag geantwortet.

            Hast du es denn auch mal mit curl versucht? Da die vorhandenen Inhalte von /etc/hosts sowieso überschrieben werden, könnte man die Aufgabe auch mit einem Einzeiler erledigen:

            curl https://hosts.ubuntu101.co.za/hosts | grep '^127.0.0.1\|^255.255.255.255\|^::1\|^fe80\|^0.0.0.0' >/etc/hosts

            Die Überprüfung auf den root-Benutzer ist bei Ausführung als system unit entbehrlich, und auf die Plausibilitätsprüfung kann wegen des grep-Filters eigentlich auch verzichtet werden.

            Was mir bei meinen Tests allerdings auffiel war, dass systemd-resolved Hostnamen mit Unterstrich als ungültig zurück weist und für jeden dieser Hostnamen (wovon es aktuell 856 gibt) zwei Zeilen im journal ablegt. Das passiert bei jeder DNS-Anfrage und dürfte so das Journal ziemlich zumüllen. Wenn du einen anderen Resolver verwendest, ist das vielleicht egal, aber ein Blick dazu ins journal wäre trotzdem angezeigt.

            Außerdem dürfte ein solcher Eintrag dann auch nicht auf 0.0.0.0umgeleitet werden, was dann den eigentlichen Nutzen der Liste zweifelhaft erscheinen lässt, denn für diese Einträge wird der Hostname dann doch in seine eigentlich Adresse aufgelöst und die Verbindung hergestellt.

            • GerBra hat auf diesen Beitrag geantwortet.

              fdell Das Problem liegt leider am DNS Server. Ich habe in meiner Fritzbox den DNS-Server von "Cloudflare" und "DNS over TLS (DoT)" eingerichtet. Dies führt dazu, dass die Namensauflösung temporär nicht funktioniert.

              Wenn ich das Skript oder den *.service manuell starte, funktioniert es komischerweise fehlerfrei bei der Namensauflösung. Wenn ich in der Fritzbox-config den DNS-Server auf "Vom Internetanbieter zugewiesene DNSv4-Server verwenden (empfohlen)" ändere, funktioniert das ganze per *.timer oder *.service ebenfalls problemlos.

              Es könnte einfach sein, daß die TLS-Session zu deinem Nameserver abgelaufen wäre zu diesem Zeitpunkt. Und wget/curl versuchen dann nur einmal, eine IP-Adresse für den Download zu erhalten.
              Möglichkeiten:
              a) Den wget-Aufruf mehrmals zu starten, z.B. in einer for-Schleife dreimal mit 1 Sekunde Pause. Die Schleife kann abgebrochen werden wenn der Return-Wert von wget 0/erfolgreich ist.
              b) Evtl. reicht schon ein vorheriger DNS-Request um die Session zum DNS-Server zu initiieren. Z.B. durch ein vorangehendes:

              ping -c 3 hosts.ubuntu101.co.za
              sleep 1

              (Die ping-Ausgabe kann - wenn es so klappt - komplett nach /dev/null umgeleitet werden.)

              Fakt ist auf jedenfall: Da das Downloaden der Liste ja der zentrale Vorgang des Skripts ist, bedarf dieser eine eigene "Fehler"-Behandlung und sollte nur dann abbrechen(nichts tun), wenn der User bestimmte Kriterien als nicht möglich ersieht.

              Leider (aber in punkto Sicherheit zum Glück) erlauben weder wget noch curl andere DNS-Server für die Aktion zu verwenden, beide Tools sind ohne die entsprechende Option kompiliert. Dann könnte z.B. für diesen Aufruf dein Provider DNS verwendet werden anstatt des System-DNS. Es wäre allerdings möglich sich bei Bedarf ein eigenes (ggf. statisch gelinktes) wget/curl zu bauen und z.B. nach /usr/local abzulegen. Das wäre aber IMHO mit "Kanonen auf Spatzen" gefeuert und bedarf auch einiger Sicherheitsvor-/nachkehrungen.

              Martin-MS Außerdem dürfte ein solcher Eintrag dann auch nicht auf 0.0.0.0umgeleitet werden, was dann den eigentlichen Nutzen der Liste zweifelhaft erscheinen lässt, denn für diese Einträge wird der Hostname dann doch in seine eigentlich Adresse aufgelöst und die Verbindung hergestellt.

              Das stimmt nicht. Solange die hosts-Datei primär für DNS-Resolv genutzt wird werden diese Adressen zu 127.0.0.1/localhost umgesetzt.
              Kannst du testen mit z.B.

              [root@ws01 ~]# dig zzzzzz.petrodollar.org && ping -c 2 zzzzzz.petrodollar.org
              ...
              ;; ANSWER SECTION:
              zzzzzz.petrodollar.org.	3213	IN	A	103.224.182.253
              ...
              PING zzzzzz.petrodollar.org (103.224.182.253) 56(84) Bytes an Daten.
              64 Bytes von lb-182-253.above.com (103.224.182.253): icmp_seq=1 ttl=55 Zeit=165 ms
              64 Bytes von lb-182-253.above.com (103.224.182.253): icmp_seq=2 ttl=55 Zeit=165 ms
              
              [root@ws01 ~]# echo "0.0.0.0 zzzzzz.petrodollar.org" >> /etc/hosts
              
              [root@ws01 ~]# dig zzzzzz.petrodollar.org && ping -c 2 zzzzzz.petrodollar.org
              ...
              ;; ANSWER SECTION:
              zzzzzz.petrodollar.org.	3111	IN	A	103.224.182.253
              ...
              PING zzzzzz.petrodollar.org (127.0.0.1) 56(84) Bytes an Daten.
              64 Bytes von localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 Zeit=0.012 ms
              64 Bytes von localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 Zeit=0.023 ms
              
              [ich@ws01 ~]$ wget zzzzzz.petrodollar.org
              --2024-01-07 09:38:39--  http://zzzzzz.petrodollar.org/
              Auflösen des Hostnamens zzzzzz.petrodollar.org (zzzzzz.petrodollar.org)… 0.0.0.0
              Verbindungsaufbau zu zzzzzz.petrodollar.org (zzzzzz.petrodollar.org)|0.0.0.0|:80 … fehlgeschlagen: Verbindungsaufbau abgelehnt.

              Besser wäre so eine hosts-(Block)-Liste natürlich auf dem lokalen Router/DNS-Server aufgehoben.

              • Martin-MS hat auf diesen Beitrag geantwortet.

                GerBra Das stimmt nicht. Solange die hosts-Datei primär für DNS-Resolv genutzt wird werden diese Adressen zu 127.0.0.1/localhost umgesetzt.

                …solange der Hostname keine Unterstriche enthält und nicht systemd als Resolver verwendet wird. Wenn hosts z. B. so aussieht

                [root@archlinux ~]# cat /etc/hosts
                # Static table lookup for hostnames.
                # See hosts(5) for details.
                
                0.0.0.0 1.03rid7_easycoops.filter.clickbank.net
                0.0.0.0 google.de

                dann gehen sowohl ping als auch wget für das erst Ziel durch und für das zweite Ziel nicht:

                [root@archlinux ~]# ping -c1 google.de
                ping: google.de: Zu diesem Hostnamen gehört keine Adresse
                [root@archlinux ~]# ping -c1 1.03rid7_easycoops.filter.clickbank.net
                PING clickbank-apache-54377296.us-west-2.elb.amazonaws.com (35.167.122.11) 56(84) Bytes an Daten.
                ^C
                --- clickbank-apache-54377296.us-west-2.elb.amazonaws.com ping-Statistik ---
                1 Pakete übertragen, 0 empfangen, 100% packet loss, time 0ms
                
                [root@archlinux ~]# wget google.de
                --2024-01-07 10:59:02--  http://google.de/
                Auflösen des Hostnamens google.de (google.de)… fehlgeschlagen: Zu diesem Hostnamen gehört keine Adresse.
                wget: Host-Adresse »google.de« kann nicht aufgelöst werden
                [root@archlinux ~]# wget 1.03rid7_easycoops.filter.clickbank.net
                --2024-01-07 10:59:15--  http://1.03rid7_easycoops.filter.clickbank.net/
                Auflösen des Hostnamens 1.03rid7_easycoops.filter.clickbank.net (1.03rid7_easycoops.filter.clickbank.net)… 35.167.122.11, 54.191.88.1
                Verbindungsaufbau zu 1.03rid7_easycoops.filter.clickbank.net (1.03rid7_easycoops.filter.clickbank.net)|35.167.122.11|:80 … verbunden.
                HTTP-Anforderung gesendet, auf Antwort wird gewartet … 400 400
                2024-01-07 10:59:16 FEHLER 400: 400.

                und das journal meldet (abweichender Zeitstempel wegen früherem Versuch)

                Jan 07 10:46:47 archlinux systemd-resolved[269]: /etc/hosts:4: hostname "1.03rid7_easycoops.filter.clickbank.net" is not valid, ignoring.
                Jan 07 10:46:47 archlinux systemd-resolved[269]: /etc/hosts:4: line is missing any valid hostnames

                GerBra Besser wäre so eine hosts-(Block)-Liste natürlich auf dem lokalen Router/DNS-Server aufgehoben.

                Fände ich auch, weil man damit das gesamte Netzwerk und nicht nur ein Gerät schützen würde. Mir ist aber aus dem SoHo-Bereich kein Router bekannt, der >600.000 Ziele in einer Sperrliste verwalten könnte. Die Liste ließe sich aber auch deutlich ausdünnen, wenn man die Sperren z.B. auf die ganze Domain clickbank.net beschränken und nicht jeden einzelnen Host aufführen würde.

                • GerBra hat auf diesen Beitrag geantwortet.

                  Martin-MS …solange der Hostname keine Unterstriche enthält und nicht systemd als Resolver verwendet wird.

                  Ups. Da hält sich der systemd-resolved wohl strikt an RFC 952, obwohl die "reale" Welt anders aussieht. Mit dem glibc-resolver gibt es das Problem nicht.
                  Ich habe auf die Schnelle auch nichts in den manpages gesehen daß man systemd-resolver entsprechend konfigurieren könnte.

                  Martin-MS Mir ist aber aus dem SoHo-Bereich kein Router bekannt, der >600.000 Ziele in einer Sperrliste verwalten könnte.

                  dnsmasq kann es wohl, ist halt kein Hardware-Blob:

                  It is possible to use dnsmasq to block Web advertising  by  using  a  list  of  known  banner-ad servers,
                  all  resolving to 127.0.0.1 or 0.0.0.0, in /etc/hosts or an additional hosts file. The list can be very long,
                  dnsmasq has been tested successfully with one million  names.  That  size file needs a 1GHz processor and
                  about 60Mb of RAM.

                  Martin-MS Die Liste ließe sich aber auch deutlich ausdünnen

                  OnTopic: Wäre ja eine kleine "Hausaufgabe" so ein Parser-Skript zu schreiben... <g>

                    GerBra OnTopic: Wäre ja eine kleine "Hausaufgabe" so ein Parser-Skript zu schreiben... <g>

                    Ähm... also ich würde da lieber etwas anderes schreiben wollen.

                    Habe herausgefunden, dass "ublock Origin" (eine Firefox Erweiterung) deutlich mehr Werbeinhalte blockiert als eine "/etc/hosts" (habe mittlerweile diverse getestet). Ich nutze diese Seite für Wettervorhersagen: https://kachelmannwetter.com/de/wetter/2950159-berlin

                    Hier werden die Werbeinhalte nicht von der "/etc/hosts" blockiert, weil die url's der Werbebanner auf dem Server von https://kachelmannwetter.com liegen, also wird die Werbung angezeigt. Die FF Erweiterung filtert das alles raus, auch bei anderen Seiten wie Stern oder Spiegel usw. Der Erste Aufruf einer Webseite dauert zwar etwas länger, aber dafür ist man zuverlässig die Werbung los. Weitere Aufrufe der Seite sind dann deutlich schneller.

                    OnTopic:
                    Ich überlege ein "Ausgabe-Skript" zu schreiben, dass es mir ermöglicht, jede Ausgabe eines Befehl- /Skriptaufrufs in der Konsole zu zeigen und parallel in eine *.log Datei zu schreiben. Man bräuchte dann nur das "Ausgabe-Skript" an einen Befehl oder Skriptaufruf anhängen.

                    Bisher habe ich dafür jedes mal ein >> ${out} oder ein &>> $out geschrieben. Das funktioniert auch, aber wenn die Ausgabe umgeleitet ist, wird leider in der Konsole nichts angezeigt. Schöner wäre es, die Ausgabe in der Konsole zu sehen und bei Bedarf, eine *.log zu haben, in der man später in Ruhe etwas nachlesen kann.

                    Da es die "log Funktion" und vor allem "Journald" bereits gibt, werde ich erstmal die manpages dazu lesen und versuchen zu verstehen.

                    • Martin-MS hat auf diesen Beitrag geantwortet.

                      fdell ch überlege ein "Ausgabe-Skript" zu schreiben, dass es mir ermöglicht, jede Ausgabe eines Befehl- /Skriptaufrufs in der Konsole zu zeigen und parallel in eine *.log Datei zu schreiben.

                      Das kann tee

                      • fdell hat auf diesen Beitrag geantwortet.

                        Martin-MS Danke, sowas habe ich gesucht.
                        Das funktioniert bei Aufrufen wiedf | tee ~/test.log

                        Aber bei:
                        wget -O hosts https://someonewhocares.org/hosts/zero/ | tee test.log
                        Bleibt die "test.log" leer, Konsolenausgabe und Download erfolgen jedoch.

                        • Martin-MS hat auf diesen Beitrag geantwortet.