Datei auslesen: while-Schleife lässt keine Eingaben zu

[munchkinnlade]

Erstmal ein herzliches Hallo an alle,

auf der Suche nach einer Lösung für eine Frage zur Shellprogrammierung fand ich euer Forum und hoffe, dass ihr einen Rat wisst.

Also, ich habe folgendes kleine Skript zum Zeilenweise auslesen einer Datei erstellt:

#!/bin/bash

clear

while read -r file
do
        echo $file
        read -p "Ihre Eingabe" eingabe
        echo "Eingabe war $eingabe"
done < text.txt

Die Datei wird tatsächlich auch zeilenweise ausgelesen, aber ich werde nicht nach jeder Zeile nach einer Eingabe gefragt, sondern der Variable $eingabe wird automatisch ein Wert zugewiesen.
Mache ich da was falsch? Und warum geht das nicht?

Über Hilfe würde ich mich sehr freuen. Vielen Dank und einen schönen Tag an alle

 

[framp]

Herzlich willkommen im Forum

Du hast read geschachtelt. D.h. der zweite read innerhalb der while Schleife liest den Inhalt von text.txt.

Eine moegliche Loesung Deines Problems waere

#!/bin/bash

clear

files=( $(<text.txt) )

for file in ${files[@]}; do
        echo $file
        read -p "Ihre Eingabe" eingabe
        echo "Eingabe war $eingabe"
done

 

[framp]

Eine andere Loesung ist einfach fuer die aeussere Schleife nicht den Standardfiledescriptor fuer stdin (0) zu nehmen sondern z.B. 3 und von dort zu lesen.

!/bin/bash

clear

exec 3<text.txt

while read -r -u 3 file; do
        echo $file
        read -p "Ihre Eingabe" eingabe
        echo "Eingabe war $eingabe"
done

 

[framp]

Oder das Ganze umgedreht

#!/bin/bash

clear

while read -r -u 3 file; do
        echo $file
        read -p "Ihre Eingabe" eingabe
        echo "Eingabe war $eingabe"
done 3<text.txt

 

[munchkinnlade]

Ich danke dir für deine Antwort. Offenbar habe ich das "3" vergessen. Was genau bewirkt das? Sorry für die blöde Frage, aber ich möchte gerne auch lernen, was ich so tue und bin noch völliger Anfänger. Habe vor 3 Tagen mit shellskript angefangen.

 

[framp]

read liesst standardmaessig von stdin und das von dem Filedescriptior 0. Somit liest Deine innere Schleife das was in der aeusseren Schleife auch in den Filedescriptor 0 eingelesen wird und erzeugt Dein Problem.
Wenn Du in der aeusseren Schleife den Filedescriptor 3 statt 0 nutzt kommen sich die beiden reads nicht ins Gehege. Damit liest die aeussere Schleiche mit read von Descriptor 3 und der Datei und der read innerhalb der Schleife von Descriptor 0 von der Konsole und somit kommen sich beide nicht ins Gehege

Dein Problem resultiert nur aus der Tatsachen dass beide reads vom selben Filedescriptor lesen. Einfach trennen und gut ist

 

[abgdf]

Ich kann das schon wieder gar nicht mit ansehen.
Einlesen und Bearbeiten einer Textdatei kann in bash meiner Meinung nach ziemlich kompliziert und ggf. sogar tückisch werden.
Auf den allermeisten Linux-Systemen befindet sich eine interpretierte und ziemlich mächtige Sprache namens "Perl", deren Code zuerst vielleicht etwas merkwürdig aussieht, die sich aber bei solchen Aufgaben wesentlich vorhersehbarer verhält, und in der das daher letztlich einfacher ist, wenn man sich ein bißchen damit auskennt.
In Perl würde man eine Textdatei z.B. so zeilenweise einlesen (einschließlich der Eingaben nach jeder Zeile):

#!/usr/bin/perl

use warnings;
use strict;

my $filename = "text.txt";

my ($fh, $line, $inp);
system("clear");
open($fh, "<", $filename) || die;
while ($line = <$fh>) {
    chomp($line);
    print "$line\n";
    print "Ihre Eingabe ";
    $inp = <STDIN>;
    chomp($inp);
    print "Eingabe war $inp.\n";
    if ($inp eq "q") {
        print "Received \"q\": Bye!\n";
        last;
    }
}
close($fh);

Wenn ich manchmal bash-Themen auf diese Weise "kapere", ist das keine böse Absicht, sondern ich bin wirklich der Meinung, daß man sich das Leben wesentlich leichter macht, wenn man solche Aufgaben in Perl angeht statt in bash.
bash verwende ich für die Arbeit "mit Dateien", also für das Hin- und Herkopieren und solche Sachen. Dafür ist bash gemacht, und darin ist es auch gut. Für die Arbeiten "in Dateien" meiner Meinung nach nicht so sehr.

 

[framp]

Einlesen und Bearbeiten einer Textdatei kann in bash meiner Meinung nach ziemlich kompliziert und ggf. sogar tückisch werden.

Was hast Du da konkret im Hinterkopf?

Wenn ich manchmal bash-Themen auf diese Weise "kapere", ist das keine böse Absicht, sondern ich bin wirklich der Meinung, daß man sich das Leben wesentlich leichter macht, wenn man solche Aufgaben in Perl angeht statt in bash.

Der TE hat sich fuer bash entschieden und gefragt. Vielleicht nimmt er ja Dein Beispiel als Anstoss sich mal mit Perl zu beschaeftigen

bash verwende ich für die Arbeit "mit Dateien", also für das Hin- und Herkopieren und solche Sachen. Dafür ist bash gemacht, und darin ist es auch gut. Für die Arbeiten "in Dateien" meiner Meinung nach nicht so sehr.

Ich nutze bash sehr oft um mit Dateien zu arbeiten und habe da keine Probleme. Probleme hatte ich als ich mich mal mit Perl beschaeftigt hatte Perl ist nicht meine Scriptsprache. Aber ein jeder hat ja so seine Praeferenzen

 

[abgdf]

@framp: Ja, ich weiß ja, daß Du Dich auch mit Python sehr gut auskennst. (Ich wähle Python im Forum gegenüber Anfängern lieber nicht, weil man ihnen dann erst die Sache mit den Einrückungen erklären müßte, die zuerst bestimmt schiefgeht, so daß dann nichts läuft - sowie das leidige Thema von Python 3 vs. Python 2.7, bei dem ich auf der Seite von 2.7 stehe, solange das dämlich "print()" nicht rückgängig gemacht wird - Guido van Rossum selbst war bereit, es rückgängig zu machen oder (noch besser) beide Alternativen zuzulassen, nur die bei Python extrem dogmatische und betonköpfige Community nicht).

Über die Tücken von bash haben wir auch schon mehrfach gesprochen:

- Unerwartet aufgehende Subshells, die plötzlich Variablen verschwinden lassen - was nur sehr schwer zu korrigieren ist,
- Mangelhafter Array-Support: ("${files[@]}" ist ja nun auch nicht sehr intuitiv, und ich bin mir gar nicht so sicher, ob das in so einer Konstruktion immer zuverlässig funktioniert). An sowas wie "Array of Array" ist gar nicht zu denken (vielleicht gibt es das sogar, aber wenn, dann nur schlecht und rudimentär).
- Nur schwache Funktionalität zum Verarbeiten von Strings: Am Ende ist man bei awk und sed, da kann man auch gleich alles in Perl schreiben und hat insgesamt weniger Probleme (s.o.),
- Hintergrundwissen erforderlich, wie das mit der "3" hier,
- Am besten alle Variablen in Anführungszeichen setzen, sonst ist da irgendwo ein Leerzeichen im String, und alles geht schief: Da sollte der OP hier auch noch mehr Anführungszeichen setzen;
- Selbst die umfangreichste Dokumentation, nämlich diese, konnte mir manches Verhalten von bash nicht erklären und trotz vieler Beispiele keines geben, wie man die Probleme los wird.

Also, es mag objektiv möglich sein, das alles irgendwie zu bewältigen, wenn man sich da sehr intensiv einarbeitet. Schließlich wurden umfangreiche Installationsskripte oder ein (obskures, aber cooles Projekt namens "dvd-wizard") in bash geschrieben, das war offenbar möglich.
Aber ich hab' mir schon so manches Mal an bash die Zähne ausgebissen, und sehe auch nicht ein, da tiefer einzusteigen. Weil das meiste in Perl auch geht, und dann einfacher.
Nicht wenige Leute gehen dazu über, auch Installationsskripte einfach in Perl zu schreiben. Das geht auch.
Wenn mal etwas Spezielles ist, wie hier das "clean", und es dafür kein Perl-Modul gibt (oder man keine Lust hat, es herauszusuchen), macht man halt einen "system"-Call (s.o.).

Jetzt hab' ich schon wieder viel zu viel darüber geschrieben, das ist ja nicht das erste Mal, daß dieses "Programm, Perl zu empfehlen" bei mir abläuft. Aber ich kann's halt nicht mit ansehen, wie Anfänger sich in meinen Augen gänzlich unnötig mit bash herumquälen. Nur weil das die erste Skriptsprache ist, auf die sie stoßen - die aber ausgerechnet eine aus der Unix-Steinzeit * ist, die überhaupt nicht für Anfänger konzipiert ist, und die sich gar nicht zum Einstieg eignet. Das schreckt die Leute natürlich ab, und das finde ich schade. Möchte mal wissen, wie viele potentielle Programmierer der Welt verlorengegangen sind, nur weil bash so'ne Bitch ist (wie man heute vielleicht sagen würde).

* Kompatibel zu der Unix-Shell "sh" von 1977.

 

[framp]

@abgdf Ich wollte hier jetzt keine Diskussion bzgl bash und Perl anzetteln. Das bash nicht die ideale Sprache ist um das Programmieren zu lernen - da stimme ich Dir zu. Perl aber auch nicht Du magst Perl - ich mag bash . Dein Hinweis ist valide und der TE kann sich ja seine eigene Meinung bilden.

Anyhow war meine Frage nur wo und wie Du schlechter Erfahrungen mit bash und Dateininhaltverarbeitung gemacht hast

 

[munchkinnlade]

Danke euch beiden für euren Input. Es ging mir jetzt auch mehr ums Lernen, da ich, wie gesagt, gerade dabei bin mein Linux Wissen zu erweitern und auch etwas über die Shellprogrammierung zu lernen.
Ein paar Programmierkenntnisse habe ich schon (php, python), aber jetzt ist eben mal die bash dran

Nochmals danke für eure Hilfe und guten Erläuterungen.

 

[abgdf]

Ein paar Programmierkenntnisse habe ich schon (php, python)

Wenn das so ist, und Du ein bestimmtes Problem mit der Fragestellung lösen willst, dann könntest Du so ein Skript ja auch mal in Python schreiben (hat im Grunde dieselben Vorteile wie Perl).
Wenn es Dir darum geht, bash zu lernen, dann muß es natürlich bash sein.
Worum geht es Dir denn?

 

[munchkinnlade]

Wenn das so ist, und Du ein bestimmtes Problem mit der Fragestellung lösen willst, dann könntest Du so ein Skript ja auch mal in Python schreiben (hat im Grunde dieselben Vorteile wie Perl).
Wenn es Dir darum geht, bash zu lernen, dann muß es natürlich bash sein.
Worum geht es Dir denn?

Mir geht es derzeit tatsächlich nur darum bash zu lernen. Und nebenbei wiederhole ich ein bisschen php

EDIT: Kann man hier auch über php sprechen? Hätte da auch ein kleines Problemchen...
LG und schönen Abend euch noch.

 

[framp]

EDIT: Kann man hier auch über php sprechen?

No Problem. Dann aber bitte in einem separaten Thread