Bash Lesen/schreiben der Datei-Deskriptoren — seek zum Anfang der Datei

Ich versuchte, verwenden Sie die read - /write-Datei-Deskriptor in der bash, damit ich die Datei löschen, die den file-Deskriptor bezeichnet, danach als solche:

F=$(mktemp)
exec 3<> "$F"
rm -f "$F"

echo "Hello world" >&3
cat <&3

aber die cat Befehl gibt keine Ausgabe. Ich kann erreichen, was ich will, wenn ich separate Datei-Deskriptoren zum schreiben und Lesen:

F=$(mktemp)
exec 3> "$F"
exec 4< "$F"
rm -f "$F"

echo "Hello world" >&3
cat <&4

dem Drucke Hello world.

Ich vermutete, dass bash nicht automatisch, suchen Sie den Anfang der file-Deskriptor, wenn Sie wechseln von schreiben zu Lesen, und die folgende Kombination von bash-und python-code bestätigt dies:

fdrw.sh

exec 3<> tmp
rm tmp

echo "Hello world" >&3
exec python fdrw.py

fdrw.py

import os  

f = os.fdopen(3)
print f.tell()
print f.read()

gibt:

$ bash fdrw.sh
12

$ # This is the prompt reappearing

Gibt es eine Möglichkeit, das zu erreichen, was ich will, nur mit bash?

  • warum würden Sie wollen, um die Datei zu löschen, bevor Sie Lesen/schreiben?
  • In Unix -, wenn Sie eine Datei entfernen, wird die Datei nicht wirklich gelöscht, bis alle offenen Datei-Deskriptoren werden geschlossen. So, das löschen einer temporären Datei direkt nach dem öffnen ist gängige Praxis, da es garantiert, dass kein anderer Prozess kann in böser Absicht ändern der Datei und dass die Datei geschlossen ist, nachdem Sie Ihren Prozess die Datei schließt oder beendet.
  • Warum magst du deine eigene Methode, für die man separate lese-und schreib-Deskriptoren? Das scheint die einfachste Möglichkeit.
InformationsquelleAutor telotortium | 2010-10-01
  1. 4

    Nicht. bash keine Vorstellung von "suchen" mit seiner Umleitung. Es liest/schreibt (meist) von Anfang bis Ende in einem langen Strom.

    • Grundsätzlich dann, der einzige Grund für das Lesen/schreiben von Deskriptoren in der bash ist, geben Sie eine exec ' ed Prozess?
    • Um mehr Kanäle als nur stdin, stdout und sterr, ja.
    InformationsquelleAutor Ignacio Vazquez-Abrams
  2. 5

    Versuchen, das ändern der Reihenfolge der Befehle:

    F=$(mktemp tmp.XXXXXX)
exec 3<> "$F"
echo "Hello world" > "$F"
rm -f "$F"

#echo "Hello world" >&3
cat <&3
    • Also in die Datei schreiben, dann löschen es dann gelesen?
    • diese Lösung funktioniert tatsächlich. Die Katze ist nicht das Lesen von der scheinbar gelöschten Datei. Es Lesen aus dem Deskriptor, ist noch offen. Sie können immer noch Zugriff auf den Inhalt einer Datei mit diesem Deskriptor, obwohl die letzten (hard) link wurde entfernt.
    InformationsquelleAutor yabt
  3. 4

    Beim öffnen einer Datei-Deskriptor in der bash wie, dass, wird es zugänglich, wie eine Datei in /dev/fd/.
    Auf, die Sie tun können cat und werde es Lesen, von Anfang an, oder Anhängen (echo "something" >> /dev/fd/3), und es werde es zu Ende.
    Zumindest auf meinem system verhält es sich so. (Auf der anderen Seite, ich kann nicht scheinen im Stande zu sein, "Katze" < "&3" zu arbeiten, auch wenn ich nicht jedem schreiben auf den Deskriptor).

    InformationsquelleAutor PSkocik
  4. 2
    #!/bin/bash
F=$(mktemp tmp.XXXXXX)
exec 3<> $F
rm $F

echo "Hello world" >&3
cat /dev/fd/3

    Wie vorgeschlagen in der anderen Antwort, cat wird zum Anfang der Datei-Deskriptor für Sie vor dem Lesen aus, da es denkt, dass es nur eine normale Datei.

    InformationsquelleAutor sanmai
  5. 0

    Zu "rewind" der file-Deskriptor, können Sie einfach /proc/self/fd/3

    Test-Skript :

    #!/bin/bash

# Fill data
FILE=test
date +%FT%T >$FILE

# Open the file descriptor and delete the file
exec 5<>$FILE
rm -rf $FILE

# Check state of the file
# should return an error as the file has been deleted
file $FILE

# Check that you still can do multiple reads or additions
for i in {0..5}; do
    echo ----- $i -----

    echo . >>/proc/self/fd/5
    cat /proc/self/fd/5

    echo
    sleep 1
done

    Versuchen Sie kill -9 das Skript, während es läuft, werden Sie sehen, dass im Gegensatz zu dem, was passiert mit der trap-Methode, wird die Datei tatsächlich gelöscht wird.

    InformationsquelleAutor Hexdump
Schreibe einen Kommentar