info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Variable statt Datei
1 view
Skip to first unread message
Alexander Goetzenstein
Jul 31, 2023, 4:05:08 AM7/31/23
to
Hallo,
in einem Script wird ein Programm aufgerufen, das als Ausgabeziel eine
Datei als Parameter verlangt, etwa so:
prog <Param1> [Param2] <Ausgabedatei>
Die Ausgabe soll jedoch statt in eine Datei direkt in eine Variable
geschrieben werden. Wie erreiche ich das?
--
Gruß
Alex
in einem Script wird ein Programm aufgerufen, das als Ausgabeziel eine
Datei als Parameter verlangt, etwa so:
prog <Param1> [Param2] <Ausgabedatei>
Die Ausgabe soll jedoch statt in eine Datei direkt in eine Variable
geschrieben werden. Wie erreiche ich das?
--
Gruß
Alex
Ulli Horlacher
Jul 31, 2023, 5:52:59 AM7/31/23
to
- ist prog von dir selber geschrieben oder liegt der Sourcecode vor?
- erlaubt prog Ausgabe nach STDOUT oder ist <Ausgabedatei> ein zwingendes
Argument?
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Alexander Goetzenstein
Jul 31, 2023, 7:09:59 AM7/31/23
to
Hallo,
Am 31.07.23 um 11:52 schrieb Ulli Horlacher:
> - erlaubt prog Ausgabe nach STDOUT oder ist <Ausgabedatei> ein zwingendes
> Argument?
Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich nach einer
Möglichkeit, es umzuleiten, so dass nicht auf die Platte geschrieben
wird. Wenn das nicht geht, muss ich mir etwas anderes einfallen lassen.
--
Gruß
Alex
Am 31.07.23 um 11:52 schrieb Ulli Horlacher:
> Alexander Goetzenstein <alexander_g...@web.de> wrote:
>> Hallo,
>> in einem Script wird ein Programm aufgerufen, das als Ausgabeziel eine
>> Datei als Parameter verlangt, etwa so:
>>
>> prog <Param1> [Param2] <Ausgabedatei>
>>
>> Die Ausgabe soll jedoch statt in eine Datei direkt in eine Variable
>> geschrieben werden. Wie erreiche ich das?
>
> Dazu musst du erst klaeren:
>
> - ist prog von dir selber geschrieben oder liegt der Sourcecode vor?
nein.
>> Hallo,
>> in einem Script wird ein Programm aufgerufen, das als Ausgabeziel eine
>> Datei als Parameter verlangt, etwa so:
>>
>> prog <Param1> [Param2] <Ausgabedatei>
>>
>> Die Ausgabe soll jedoch statt in eine Datei direkt in eine Variable
>> geschrieben werden. Wie erreiche ich das?
>
> Dazu musst du erst klaeren:
>
> - ist prog von dir selber geschrieben oder liegt der Sourcecode vor?
> - erlaubt prog Ausgabe nach STDOUT oder ist <Ausgabedatei> ein zwingendes
> Argument?
Möglichkeit, es umzuleiten, so dass nicht auf die Platte geschrieben
wird. Wenn das nicht geht, muss ich mir etwas anderes einfallen lassen.
--
Gruß
Alex
Christian Weisgerber
Jul 31, 2023, 9:30:05 AM7/31/23
to
On 2023-07-31, Alexander Goetzenstein <alexander_g...@web.de> wrote:
> Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich nach einer
> Möglichkeit, es umzuleiten, so dass nicht auf die Platte geschrieben
> wird. Wenn das nicht geht, muss ich mir etwas anderes einfallen lassen.
Man kann dazu das magische Device /dev/stdout als Dateinamen angeben,
> Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich nach einer
> Möglichkeit, es umzuleiten, so dass nicht auf die Platte geschrieben
> wird. Wenn das nicht geht, muss ich mir etwas anderes einfallen lassen.
das heute wohl jedes Unix hat. Das liefert dann die Ausgabe an die
Standardausgabe des Prozesses, wo auch immer sie gerade hinzeigt:
TTY, Pipe, ...
Das funktioniert aber nur, wenn das Programm eine lineare Ausgabe
produziert. Will es innerhalb einer Datei mit lseek(2) hin- und
herspringen, dann scheitert das, wenn die Standardausgabe eben keine
Datei ist, also z.B. eine Pipe bei var=$(prog foo /dev/stdout).
--
Christian "naddy" Weisgerber na...@mips.inka.de
Ulli Horlacher
Jul 31, 2023, 7:40:14 PM7/31/23
to
Alexander Goetzenstein <alexander_g...@web.de> wrote:
>>> in einem Script wird ein Programm aufgerufen, das als Ausgabeziel eine
>>> Datei als Parameter verlangt, etwa so:
>>>
>>> prog <Param1> [Param2] <Ausgabedatei>
>>>
>>> Die Ausgabe soll jedoch statt in eine Datei direkt in eine Variable
>>> geschrieben werden. Wie erreiche ich das?
>>
>>> in einem Script wird ein Programm aufgerufen, das als Ausgabeziel eine
>>> Datei als Parameter verlangt, etwa so:
>>>
>>> prog <Param1> [Param2] <Ausgabedatei>
>>>
>>> Die Ausgabe soll jedoch statt in eine Datei direkt in eine Variable
>>> geschrieben werden. Wie erreiche ich das?
>>
>> - erlaubt prog Ausgabe nach STDOUT oder ist <Ausgabedatei> ein zwingendes
>> Argument?
>
> Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich nach einer
> Möglichkeit, es umzuleiten, so dass nicht auf die Platte geschrieben
> wird.
Da prog das nicht vorsieht, geht es nicht.
>> Argument?
>
> Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich nach einer
> Möglichkeit, es umzuleiten, so dass nicht auf die Platte geschrieben
> wird.
Ende. Aus.
Ulli Horlacher
Jul 31, 2023, 7:52:41 PM7/31/23
to
Christian Weisgerber <na...@mips.inka.de> wrote:
> Man kann dazu das magische Device /dev/stdout als Dateinamen angeben,
> das heute wohl jedes Unix hat. Das liefert dann die Ausgabe an die
> Standardausgabe des Prozesses, wo auch immer sie gerade hinzeigt:
> TTY, Pipe, ...
framstag@wupp:/tmp: cat 123.pl
> Man kann dazu das magische Device /dev/stdout als Dateinamen angeben,
> das heute wohl jedes Unix hat. Das liefert dann die Ausgabe an die
> Standardausgabe des Prozesses, wo auch immer sie gerade hinzeigt:
> TTY, Pipe, ...
#!/usr/bin/perl -w
open X,">",$ARGV[0] or die $!;
print X "123...\n";
framstag@wupp:/tmp: XXX=$(./123.pl /dev/stdout)
framstag@wupp:/tmp: echo $XXX
123...
framstag@wupp:/tmp: ./123.pl /dev/stdout | wc
1 1 7
Funktioniert tatsaechlich!
Kannte ich auch noch nicht!
Helmut Waitzmann
Jul 31, 2023, 9:11:20 PM7/31/23
to
Christian Weisgerber <na...@mips.inka.de>:
ganz problemlos: Bei Linux führt das dazu, dass der Prozess,
indem er „/dev/stdout“ öffnet, in Wirklichkeit die Datei, TTY,
Pipe, … öffnet, auf die auch die Standardausgabe (file descriptor
Nummer 1) geöffnet ist. Es findet also nicht eine
Ausgabumlenkung (file descriptor duplication) sondern ein
(erneutes) Öffnen statt. Und wie bei jedem Öffnen gibt es auch
hier eine Rechteprüfung.
Falls nun das Ziel der Standardausgabe aber vom Prozess mangels
Zugriffsrechten nicht geöffnet werden kann, scheitert das Öffnen
von „/dev/stdout“, obwohl der Zugriff mittels des bereits
vorhandenen file descriptors Nummer 1 weiterhin funktioniert.
Für das folgende Beispiel zur Verdeutlichung braucht man zwei
Benutzerkonten, die nicht allmächtig („root“) sind,
beispielsweise „Benutzer_1“ und „Benutzer_2“.
Benutzer_1 legt in seinem HOME‐Verzeichnis ein Verzeichnis
„~/Spielwiese“ mit Zugriffsrechten, die Benutzer_2 keinen Zugriff
erlauben, an, etwa mit folgendem Shell‐Kommando:
( umask -- go= && mkdir -- ~/Spielwiese )
Dann startet er das folgende Kommando (das nach dem
Login‐Passwort für Benutzer_2 fragt):
su -- - Benutzer_2 -c -- \
'
printf %s\\n direkt
printf %s\\n /dev/stdout |
cp -- /dev/stdin /dev/stdout
' -su \
>> ~/Spielwiese/Hallo.txt
=> Das interaktive Shell läuft unter Benutzer_1 und öffnet die
Datei „~/Spielwiese/Hallo.txt“ zum (anhängenden) Schreiben und
reicht den dabei erhaltenen file descriptor mittels
Ausgabeumlenkung an das unter Benutzer_2 laufende Shell weiter,
das ihn zur Ausgabe verwendet. Das erste „echo“‐Kommando gibt
dabei den Text „direkt“ auf die Standardausgabe aus. Das zweite
„echo“‐Kommando gibt den Text „/dev/stdout“ in ein Pipe zu „cp“,
das die Datei „/dev/stdin“, also das Lese‐Ende des Pipes, zum
Lesen öffnet und die Datei „/dev/stdout“, also die Datei
„~/Spielwiese/Hallo.txt“ zum Schreiben zu öffnen versucht und
dabei, weil die Zugriffserlaubnisse der Datei
„~/Spielwiese/Hallo.txt“ das nicht hergeben, scheitert.
Kontrolle: Das Kommando
ls -ld -- ~/Spielwiese/Hallo.txt &&
cat -- ~/Spielwiese/Hallo.txt
zeigt die Datei und ihren Inhalt: Die Ausgabe „direkt“ ist
angekommen, während die Ausgabe „/dev/stdout“ auf der Strecke
geblieben ist.
Gerüchten zufolge soll es andere Unixe geben, bei denen das
Öffnen von „/dev/stdout“ wirklich einer Ausgabeumleitung
entspricht.
> On 2023-07-31, Alexander Goetzenstein <alexander_g...@web.de> wrote:
>
>> Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich
>> nach einer Möglichkeit, es umzuleiten, so dass nicht auf die
>> Platte geschrieben wird. Wenn das nicht geht, muss ich mir
>> etwas anderes einfallen lassen.
>>
>
> Man kann dazu das magische Device /dev/stdout als Dateinamen
> angeben, das heute wohl jedes Unix hat. Das liefert dann die
> Ausgabe an die Standardausgabe des Prozesses, wo auch immer sie
> gerade hinzeigt: TTY, Pipe, ...
>
Das „wo immer sie gerade hinzeigt“ ist bei Linux leider nicht
>
>> Die Angabe der Ausgabedatei ist zwingend. Deswegen suche ich
>> nach einer Möglichkeit, es umzuleiten, so dass nicht auf die
>> Platte geschrieben wird. Wenn das nicht geht, muss ich mir
>> etwas anderes einfallen lassen.
>>
>
> Man kann dazu das magische Device /dev/stdout als Dateinamen
> angeben, das heute wohl jedes Unix hat. Das liefert dann die
> Ausgabe an die Standardausgabe des Prozesses, wo auch immer sie
> gerade hinzeigt: TTY, Pipe, ...
>
ganz problemlos: Bei Linux führt das dazu, dass der Prozess,
indem er „/dev/stdout“ öffnet, in Wirklichkeit die Datei, TTY,
Pipe, … öffnet, auf die auch die Standardausgabe (file descriptor
Nummer 1) geöffnet ist. Es findet also nicht eine
Ausgabumlenkung (file descriptor duplication) sondern ein
(erneutes) Öffnen statt. Und wie bei jedem Öffnen gibt es auch
hier eine Rechteprüfung.
Falls nun das Ziel der Standardausgabe aber vom Prozess mangels
Zugriffsrechten nicht geöffnet werden kann, scheitert das Öffnen
von „/dev/stdout“, obwohl der Zugriff mittels des bereits
vorhandenen file descriptors Nummer 1 weiterhin funktioniert.
Für das folgende Beispiel zur Verdeutlichung braucht man zwei
Benutzerkonten, die nicht allmächtig („root“) sind,
beispielsweise „Benutzer_1“ und „Benutzer_2“.
Benutzer_1 legt in seinem HOME‐Verzeichnis ein Verzeichnis
„~/Spielwiese“ mit Zugriffsrechten, die Benutzer_2 keinen Zugriff
erlauben, an, etwa mit folgendem Shell‐Kommando:
( umask -- go= && mkdir -- ~/Spielwiese )
Dann startet er das folgende Kommando (das nach dem
Login‐Passwort für Benutzer_2 fragt):
su -- - Benutzer_2 -c -- \
'
printf %s\\n direkt
printf %s\\n /dev/stdout |
cp -- /dev/stdin /dev/stdout
' -su \
>> ~/Spielwiese/Hallo.txt
=> Das interaktive Shell läuft unter Benutzer_1 und öffnet die
Datei „~/Spielwiese/Hallo.txt“ zum (anhängenden) Schreiben und
reicht den dabei erhaltenen file descriptor mittels
Ausgabeumlenkung an das unter Benutzer_2 laufende Shell weiter,
das ihn zur Ausgabe verwendet. Das erste „echo“‐Kommando gibt
dabei den Text „direkt“ auf die Standardausgabe aus. Das zweite
„echo“‐Kommando gibt den Text „/dev/stdout“ in ein Pipe zu „cp“,
das die Datei „/dev/stdin“, also das Lese‐Ende des Pipes, zum
Lesen öffnet und die Datei „/dev/stdout“, also die Datei
„~/Spielwiese/Hallo.txt“ zum Schreiben zu öffnen versucht und
dabei, weil die Zugriffserlaubnisse der Datei
„~/Spielwiese/Hallo.txt“ das nicht hergeben, scheitert.
Kontrolle: Das Kommando
ls -ld -- ~/Spielwiese/Hallo.txt &&
cat -- ~/Spielwiese/Hallo.txt
zeigt die Datei und ihren Inhalt: Die Ausgabe „direkt“ ist
angekommen, während die Ausgabe „/dev/stdout“ auf der Strecke
geblieben ist.
Gerüchten zufolge soll es andere Unixe geben, bei denen das
Öffnen von „/dev/stdout“ wirklich einer Ausgabeumleitung
entspricht.
Friedhelm Waitzmann
Sep 6, 2023, 6:41:11 AM9/6/23
to
Helmut Waitzmann <nn.th...@xoxy.net>:
geöffnete Kanal eine Schreib‐/Lese‐Position hat, wird sie auf
Position 0 gesetzt.
>Das „wo immer sie gerade hinzeigt“ ist bei Linux leider nicht
>ganz problemlos: Bei Linux führt das dazu, dass der Prozess,
>indem er „/dev/stdout“ öffnet, in Wirklichkeit die Datei, TTY,
>Pipe, … öffnet, auf die auch die Standardausgabe (file
>descriptor Nummer 1) geöffnet ist. Es findet also nicht eine
>Ausgabumlenkung (file descriptor duplication) sondern ein
>(erneutes) Öffnen statt. Und wie bei jedem Öffnen gibt es auch
>hier eine Rechteprüfung.
Eine weitere Folge dieser Vorgehensweise: Falls der neu
>ganz problemlos: Bei Linux führt das dazu, dass der Prozess,
>indem er „/dev/stdout“ öffnet, in Wirklichkeit die Datei, TTY,
>Pipe, … öffnet, auf die auch die Standardausgabe (file
>descriptor Nummer 1) geöffnet ist. Es findet also nicht eine
>Ausgabumlenkung (file descriptor duplication) sondern ein
>(erneutes) Öffnen statt. Und wie bei jedem Öffnen gibt es auch
>hier eine Rechteprüfung.
geöffnete Kanal eine Schreib‐/Lese‐Position hat, wird sie auf
Position 0 gesetzt.
0 new messages