read in einer while-Schleife
Jan Harnisch
zuerst mal Entschuldigung, weil zu diesem Thema hier erst kürzlich ein
Thread lief, aber mein Newsserver hat den blöderweise schon entsorgt :-(
Zum Problem:
ich lese eine Datei zeilenweise mit read ein:
while read line; do
...irgendwas...
done < ~/meine/Datei
Zu einigen der Zeilen in der Datei sind jetzt Fragen an den Benutzer
nötig, aber wenn ich jetzt sowas mache wie
while read line; do
...
echo "Diese Zeile bearbeiten?"
read editline
...
done < ~/meine/Datei
dann liest auch das read innerhalb der Schleife aus der Datei und man
kann keine händischen Eingaben machen. Nun könnte man zwar zuerst mit
einer while-Schleife die Datei einlesen, dabei fortlaufend jede Zeile in
einer Variablen speichern und anschließend diese Variablen nacheinander
durchgehen und dem Benutzer die Fragen stellen, aber das erscheint mir
recht unelegant.
Ich hoffe, jemandem fällt dazu noch was besseres ein.
Danke für alle Tips,
Jan
Lars Klemstein
> Zum Problem:
> ich lese eine Datei zeilenweise mit read ein:
> while read line; do
> ...irgendwas...
> done < ~/meine/Datei
>
> Zu einigen der Zeilen in der Datei sind jetzt Fragen an den Benutzer
> nötig, aber wenn ich jetzt sowas mache wie
#!/bin/sh
file=/etc/passwd # Beispiel
while read line ; do
echo "Zeile: $line"
echo -n "Bearbeiten? "
read answer < /dev/tty
echo "Antwort war: $answer"
done < $file
Gruß,
Lars
Gunnar Ritter
>> Zu einigen der Zeilen in der Datei sind jetzt Fragen an den Benutzer
>> nötig, aber wenn ich jetzt sowas mache wie
>
> file=/etc/passwd # Beispiel
>
> while read line ; do
> echo "Zeile: $line"
> echo -n "Bearbeiten? "
> read answer < /dev/tty
> echo "Antwort war: $answer"
> done < $file
Das hat den Nachteil, daß man die Eingabe an das Skript nicht ohne
weiteres umlenken kann. Solange kein zwingender Grund vorliegt, vom
Terminal selbst zu lesen, ist
file=/etc/passwd
exec 3<&0
while read line
do
echo "Zeile: $line"
printf %s 'Bearbeiten? '
read answer <&3
echo "Antwort war: $answer"
done < $file
exec 3<&-
vorzuziehen. Zu »echo -n« konsultiere groups.google.com.
Grüße,
Gunnar
Patrick Schaaf
>Hallo,
>ich lese eine Datei zeilenweise mit read ein:
>while read line; do
> ...irgendwas...
>done < ~/meine/Datei
>Zu einigen der Zeilen in der Datei sind jetzt Fragen an den Benutzer
>nötig,
Versuch mal:
exec 3<&0
while read line; do
echo -n "Zeile '$line'. Na? "
antwort=`(read x; echo $x) 0<&3`
echo "Zeile '$line', Antwort '$antwort'"
done <./testfeil
Hat gerade zu funktionieren behauptet. Das 'echo $x' und die Backticks
koennen Dich natuerlich beliebig stoeren... Wenn Du read nicht brauchst,
sondern einfach eine Zeile willst, wie waere statt dessen
exec 3<&0
while read line; do
echo -n "Zeile '$line'. Na? "
antwort=`head -1 0<&3`
echo "Zeile '$line', Antwort '$antwort'"
done <./testfeil
Sind damit noch irgendwelche Quotenprobleme zu erwarten? Mir scheint's sauber.
Gruss
Patrick
Gunnar Ritter
> exec 3<&0
> while read line; do
> echo -n "Zeile '$line'. Na? "
»echo -n« ist nicht portabel. Die Ausgabe von '$line' erscheint mir
einigermaßen sinnfrei.
> antwort=`head -1 0<&3`
Für ein einfaches yes/no ist das sicher Overkill, oder erwartest
Du Backslashes in der Antwort?
> echo "Zeile '$line', Antwort '$antwort'"
S.o.
> done <./testfeil
^^
Wozu diese beiden Zeichen dienen sollen, mußt Du mir mal erklären.
> Mir scheint's sauber.
Naja.
Grüße,
Gunnar
Tino Schwarze
Gunnar Ritter <g...@bigfoot.de> wrote:
>> file=/etc/passwd # Beispiel
>>
>> while read line ; do
>> echo "Zeile: $line"
>> echo -n "Bearbeiten? "
>> read answer < /dev/tty
>> echo "Antwort war: $answer"
>> done < $file
> Das hat den Nachteil, daß man die Eingabe an das Skript nicht ohne
> weiteres umlenken kann. Solange kein zwingender Grund vorliegt, vom
> Terminal selbst zu lesen, ist
> file=/etc/passwd
> exec 3<&0
Zitiere "configure":
# File descriptor usage:
# 0 standard input
# 1 file creation
# 2 errors and warnings
# 3 some systems may open it to /dev/tty
# 4 used on the Kubota Titan
-> lieber erst FD 5 benutzen?
> while read line
> do
> echo "Zeile: $line"
> printf %s 'Bearbeiten? '
> read answer <&3
Spricht etwas gegen
read -p 'Bearbeiten? ' answer <&5
?
> echo "Antwort war: $answer"
> done < $file
> exec 3<&-
Tschau. Tino.
--
* LINUX - Where do you want to be tomorrow? *
http://www.tu-chemnitz.de/linux/tag/
Gunnar Ritter
>> exec 3<&0
> Zitiere "configure":
> # File descriptor usage:
> # 0 standard input
> # 1 file creation
> # 2 errors and warnings
Soweit klar.
> # 3 some systems may open it to /dev/tty
Kennt jemand eines dieser »some systems«?
> # 4 used on the Kubota Titan
Was zur Hölle ist das denn?
> -> lieber erst FD 5 benutzen?
An Tips aus autoconf ist oft etwas dran, für configure und Skripte mit
ähnlichem Portabilitätsanspruch sollte man das wohl im Hinterkopf
behalten. Allerdings würde ich trotzdem gerne mal wissen, welche
Systeme derart broken sind - wenn die älter als ~10 Jahre sind, wäre
es mir persönlich egal.
> Spricht etwas gegen
> read -p 'Bearbeiten? ' answer <&5
> ?
Ja. Es ist eine komplett nutzlose bash-Erweiterung, da es keinen
irgendwie gearteten Vorteil gegen printf (ggf. in Kombination
mit »test -t 5«) bietet. Typisch GNU-Bloat eben. Besonders dumm
ist, daß »read -p« in der ksh etwas völlig anderes tut.
Grüße,
Gunnar
Jan Harnisch
Ihr seid klasse. Danke an alle!
Tschüß,
Jan
Celal Dikici
> Ja. Es ist eine komplett nutzlose bash-Erweiterung, da es keinen
> irgendwie gearteten Vorteil gegen printf (ggf. in Kombination
> mit »test -t 5«) bietet. Typisch GNU-Bloat eben. Besonders dumm
> ist, daß »read -p« in der ksh etwas völlig anderes tut.
ob du dir das hier mal anschauen könntest:
https://groups.google.com/d/msg/de.comp.os.unix.shell/rUO-kT4M72Q/ZoLQTGmNAAAJ
Andreas Kohlbach
>
> Am Dienstag, 5. Juni 2001 15:10:03 UTC+2 schrieb Gunnar Ritter:
>> irgendwie gearteten Vorteil gegen printf (ggf. in Kombination
>> mit »test -t 5«) bietet. Typisch GNU-Bloat eben. Besonders dumm
>> ist, daß »read -p« in der ksh etwas völlig anderes tut.
>
>
> Da ich gerade mit dieser »read -p« hadere, wollte ich dich bitten,
> ob du dir das hier mal anschauen könntest:
>
> https://groups.google.com/d/msg/de.comp.os.unix.shell/rUO-kT4M72Q/ZoLQTGmNAAAJ
20 Jahre voll zu machen. ;-)
--
Andreas
Joerg.S...@fokus.fraunhofer.de
>Du hättest mit dem Antworten wirklich noch zwei Jahre warten können, um
>20 Jahre voll zu machen. ;-)
Lebenszeichen von Gunnar Ritter gesehen hat.
Ich glaube, der war seit Ende 2006 nirgendwo mehr gesehen.
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Christian Schneider
> Andreas Kohlbach <a...@spamfence.net> wrote:
>
>>Du hättest mit dem Antworten wirklich noch zwei Jahre warten können, um
>>20 Jahre voll zu machen. ;-)
>
> Naja, was mich interessieren würde ist ob jemand in den letzten 10 Jahren ein
> Lebenszeichen von Gunnar Ritter gesehen hat.
>
> Ich glaube, der war seit Ende 2006 nirgendwo mehr gesehen.
jetzt von Carsten Kunze betreut. Auf der Homepage[1] steht allerdings
eine *@acm.org Adresse von Gunnar. Wahrscheinlich f0rken er und Robin
grad das Darknet.
[1] <http://heirloom.sourceforge.net/index.html>
--
{ \|/ ______ \|/ Access denieded | Christian 'strcat' Schneider }
{ "@' / , . \ `@" Nah Nah Nah :p | http://www.strcat.de/ }
{ /__| \____/ |__\ | http://www.strcat.de/blog/ }
{ \___U__/ | http://strcat.de/chris.gpg }
Christian Weisgerber
> Naja, was mich interessieren würde ist ob jemand in den letzten 10 Jahren ein
> Lebenszeichen von Gunnar Ritter gesehen hat.
>
> Ich glaube, der war seit Ende 2006 nirgendwo mehr gesehen.
2007.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Joerg.S...@fokus.fraunhofer.de
Christian Schneider <str...@gmx.net> wrote:
>Thus spake Joerg.S...@fokus.fraunhofer.de (Joerg.S...@fokus.fraunhofer.de):
>> Naja, was mich interessieren würde ist ob jemand in den letzten 10 Jahren ein
>>
>> Ich glaube, der war seit Ende 2006 nirgendwo mehr gesehen.
>
>eine *@acm.org Adresse von Gunnar. Wahrscheinlich f0rken er und Robin
>grad das Darknet.
Von den ganzen Dingen, die man in "heiloom" findet sind ja eigentlich nur 2
wirklich von Interesse:
- "nail", das wird seit einiger Zeit an anderer Stelle von
Steffen Nurpmeso bearbeitet
- "troff", da weiß ich nicht was da läuft. Hier wäre ich an einer
Weiterentwicklung (für SchilliX) interessiert, habe aber aktuell keine
Zeit.
Kannst Du sagen, woran Carsten Kunze arbeitet?
Ansonsten ist mein Eindruck, daß schon nach Mitte 2006 eigentlich nichts mehr
wirklich passierte und viele der Programme wurden auch nur 1-2 Monate
bearbeitet wurden, nachdem sie von OpenSolaris (oder teilweise von Caldera)
übernommen wurden.
Generell fällt mir ein:
- Der Bourne Shell ist nicht wirklich portabel, ist nicht mehr Original
und kann daher auch nicht als Referenz verwendet werden, wird aber auch
nicht sinnvoll weiterentwickelt.
Mein Bourne Shell Projekt läuft seit Dezember 2006 und hat neben der
POSIX Unterstützung, einer massiven Geschwindigkeitssteigerung, die ihn
bis auf unter 5% an den schnellsten Shell (die ksh93 Variante, die in
OpenSolaris integriert ist) herankommt und vielen Bugfixes (teilweise
zu Bugs, die seit 1979 drin waren) eine Kompilationsvariante (obosh),
die 100% kompatibel zu der letzten OpenSolaris Version ist. Die
Codebasis hat sich seit dem mehr als vervierfacht.
- Mit seiner Version von SunPro Make hat er zwar belegt, daß der Code
dabei war, mit dem man parallele Kompilation durchführen kann, wenn man
diverse #ifdefs modifiziert, aber seine Version von SunPro Make ist so
fehlerhaft, daß damit die OpenSolaris Kompilation nach weniger als
5 Minuten komplett abbricht.
Mein SunPro Make ist (mit Ausnahme der Unterstützung der Sun Grid
Engine) voll funktionsfähig und wird bei SchilliX-ON als Ersatz
des Closed Source SunPro Make binaries aus dem Sun Kompiler verwendet.
Die portable Variante in den Schilytools geht fast überall und kann
daher vermeiden, daß wieder jemand der OpenSolaris Cross-kompilieren
will (wie es bei der ARM Variante für den Odroid C2 passierte) die
Makefiles alle auf gmake umstellt und dann die Rück-Integration in die
Hauptentwicklung verhindert.
Hier gab es auch Bug-Fixes zu Dingen, die seit 20 Jahren in der
Sun Variante als ärgerlich bekannt sind.
- SCCS ist nie ausreichend an die Eigenheiten der glibc auf Linux
angepaßt worden und hat mindestens dort daher Probleme.
Mein SCCS wird seit 13 Jahren ständig weiterentwickelt, also seit dem
ich Anfang Dezember 2006 erreicht hatte, daß Sun es unter OSS stellt.
Die Codebasis hat sich seit dem fast vervierfacht, die Geschwindigkeit
hat sich seit dem verdreifacht.
Christian Schneider
> Christian Schneider <str...@gmx.net> wrote:
>>Thus spake Joerg.S...@fokus.fraunhofer.de (Joerg.S...@fokus.fraunhofer.de):
>
>>> Naja, was mich interessieren würde ist ob jemand in den letzten 10 Jahren ein
>>> Lebenszeichen von Gunnar Ritter gesehen hat.
>>>
>>> Ich glaube, der war seit Ende 2006 nirgendwo mehr gesehen.
>>
>>Die letzte Aktivität von ihm war das Heirloom Project, aber das wird
>>jetzt von Carsten Kunze betreut. Auf der Homepage[1] steht allerdings
>>eine *@acm.org Adresse von Gunnar. Wahrscheinlich f0rken er und Robin
>>grad das Darknet.
>
> Hast Du für die Aussage mit Carsten Kunze einen Beleg?
und er ist ebenfalls als Maintainer bei den PKGs von NetBSD[1]
angegeben. In <https://fossies.org/linux/mandoc/NEWS> taucht sein Name
im Release 1.14.2 auf (Juli 2017).
Ob - und wenn ja an was - er aktiv arbeitet, weiß nur er. Ich habe weder
von ihm, noch von Gunnar und auch von Robin schon seit Jahren nichts
mehr gehört.
[1] <http://pkgsrc.se/textproc/heirloom-doctools>
Joerg.S...@fokus.fraunhofer.de
>Auf <https://utroff.org/> steht das es einige Zeit von ihm betreut wurde
>und er ist ebenfalls als Maintainer bei den PKGs von NetBSD[1]
ich mit ihm mal vor 2 Jahren in Chemnitz auf dem Linux Tag gesprochen.
>angegeben. In <https://fossies.org/linux/mandoc/NEWS> taucht sein Name
>im Release 1.14.2 auf (Juli 2017).
Konkurrent, denn die Software ist mahr als 3x größer als das komplette UNIX
Text-Subsystem, kann aber viel weniger als troff.
>Ob - und wenn ja an was - er aktiv arbeitet, weiß nur er. Ich habe weder
>
>[1] <http://pkgsrc.se/textproc/heirloom-doctools>
Also ich werde vielleicht mal versuchen ihn zu kontaktieren.
Christian Schneider
> Christian Schneider <str...@gmx.net> wrote:
>
>>> Hast Du für die Aussage mit Carsten Kunze einen Beleg?
>>im Release 1.14.2 auf (Juli 2017).
>
> jetzt bin ich aber verwirrt. Mandoc ist doch ein aus meiner Sicht unsinniger
> Konkurrent, denn die Software ist mahr als 3x größer als das komplette UNIX
> Text-Subsystem, kann aber viel weniger als troff.
diverse andere Applikationen (die 23. Shell, der 42. Editor, die 728.
Linuxdistribution, .. ): "Weil ich das will und because fuck you.. thats
why!". In manchen Sachen sind Developer wie Katzen.
Joerg.S...@fokus.fraunhofer.de
>Linuxdistribution, .. ): "Weil ich das will und because fuck you.. thats
>why!". In manchen Sachen sind Developer wie Katzen.
gesetzte Tagesziel (eine Maus) geschafft hat...
Celal Dikici
>den (die 23. Shell, der 42. Editor, die
und workaholic Katzen, aber könnt ihr eine Aussage treffen, wo das mit read -p so funktioniert (auf Linux), wie es auf ksh88 auf SunOS 5.10 normal funktioniert?
Auf https://github.com/att/ast/blob/master/CHANGELOG.md sehen wir, dass eine Aktualisierung ("14.05.25 +Replaces the -p option..., -p causes the read from a pipe.") gibt, was mein Problem lösen könnte, aber ich kann dem nicht so ganz trauen. Klappt das damit tatsächlich?
Grüße,
Celal