mysql in Bashscript

[Jörg]

Hallo,

mir gelingt es zwar, den Inhalt einer mysql-Query auf der Konsole auszugeben, aber nicht in eine Datei zu schreiben.

Woran liegt das?

#! /bin/bash

host="localhost"
port="3306"
user=""
passwort=""
DBASE="myDB"

Query='SELECT * FROM table'

#mysql -u$user -p$passwort -P$port -h$host -D$DBASE <<EOF 
#$Query
#EOF

mysql  -u$user -p$passwort -P$port -h$host -D$DBASE --default-character-set=utf8 -e $Query > /mypfad/result.txt

Und Zusatzfrage: Wie führe ich eine Query aus, ohne etwas auszugeben bzw. in eine Datei zu schreiben?

Jörg

[MudGuard]

Hi,

mir gelingt es zwar, den Inhalt einer mysql-Query auf der Konsole auszugeben, aber nicht in eine Datei zu schreiben.

hab grad kein mysql zur Verfügung, kann's also nicht testen.

ich sehe 2 Möglichkeiten:

1. mysql schreibt das Ergebnis nicht auf stdout, sondern auf stderr

2. der Query-Parameter braucht evtl. noch escaping (evtl. wird das folgende > /mypfad/result.txt noch als Teil der Query übergeben.

Wie gesagt: Vermutungen, nix getestetes.

cu,
Andreas a/k/a MudGuard

[Jörg]

Hallo Andreas,

danke für Deine Vermutungen. UNd vermutlich bist Du auch auf dem richtrigen Weg, denn nachfolgende Anweisung schreibt mir den Tabelleninhalt in miene Datei:

mysql  -u$user -p$passwort -P$port -h$host -D$DBASE --default-character-set=utf8 -e'SELECT * FROM table' > /mypfad/result.txt

Warum es mit der Variable nicht klappt, keine Ahnung.?

Jörg

[MudGuard]

Hi,

Warum es mit der Variable nicht klappt, keine Ahnung.?

Vermutlich, weil der Variableninhalt
SELECT * FROM table ist, nicht
'SELECT * FROM table'.

cu,
Andreas a/k/a MudGuard

[Jörg]

Warum es mit der Variable nicht klappt, keine Ahnung.?

Vermutlich, weil der Variableninhalt
SELECT * FROM table ist, nicht
'SELECT * FROM table'.

Dachte ich mir auch schon, aber:

Query='"SELECT * FROM table"'

funktioniert nicht,

mysql  -u$user -p$passwort -P$port -h$host -D$DBASE --default-character-set=utf8 -e\'$Query\' > /mypfad/result.txt

funktioniert auch nicht.

Jörg

[Raketenwilli]

Query='SELECT * FROM table'
echo $Query

Folge: Ähnliches bekommt Dein Mysql-Client „zu fressen“:

SELECT armbian_pakete.sqbpro […] Vorlagen FROM table

Klar kommt da nichts raus. Du überlässt es der Shell, den Asterix (*) auszuwerten - und die baut treudoof eine Liste aller nicht versteckten Dateisystem-Objekte im Verzeichnis daraus. Das geht besser:

echo "$Query"

sendet:

SELECT * FROM table

Frage:

mysql […] -e "$Query" > ausgabe.txt 2> errors.txt

hast Du probiert?

Du musst in der Shell Argumente sehr häufig( fast regelmäßig) in Anführungstrichen übergeben. Leerzeichen trennen die Optionsparameter z.B. von Argumenten und diese untereinander. Daran ändert auch nichts, dass „Autoren“ und Youtuber in ihren tollen, optimierten Beispielen diese dummerweise weg lassen.

[Jörg]

Hi Willi,

Frage:

mysql  ... -e "$Query" > ausgabe.txt 2> errors.txt

hast Du probiert?

Jetzt ja. Und jetzt bekomme ich auch eine Ergebnismenge in der result.txt und einen Fehler in der error.txt (Passwörter besser nicht über Konsole schicken).

Mein Fehler war, dass ich $Query nicht in doppelte Anführungszeichen gesetzt hatte.

Noch ne Frage: Was bedeutet die 2 vor dem > ? Denn wenn ich die weglasse, erhalte ich in der result.txt nichts und in der error.txt meine Ergebnismenge.

[Raketenwilli]

Noch ne Frage: Was bedeutet die 2 vor dem > ? Denn wenn ich die weglasse, erhalte ich in der result.txt nichts und in der error.txt meine Ergebnismenge.

• Befehl > DATEI: Normale Ausgaben (<stdout>) landen in der Datei DATEI.

• Befehl 1> DATEI: ebenso.

• Befehl >> DATEI: Normale Ausgaben werden an die Datei DATEI angehangen.

• Befehl 1>> DATEI: ebenso.

• Befehl 2> ERRORS: Fehlermeldungen (<stderr>) landen in der Datei ERRORS

• Befehl 2>> ERRORS: Fehlermeldungen werden an die Datei ERRORS angehangen.

• Befehl > DATEI >2&1<stdout> und <stderr> werden in die Datei DATEI geschrieben.

[Jörg]

Noch ne Frage: Was bedeutet die 2 vor dem > ? Denn wenn ich die weglasse, erhalte ich in der result.txt nichts und in der error.txt meine Ergebnismenge.

• Befehl > DATEI: Normale Ausgaben (<stdout>) landen in der Datei DATEI.

• Befehl 1> DATEI: ebenso.

• Befehl >> DATEI: Normale Ausgaben werden an die Datei DATEI angehangen.

• Befehl 1>> DATEI: ebenso.

• Befehl 2> ERRORS: Fehlermeldungen (<stderr>) landen in der Datei ERRORS

• Befehl 2>> ERRORS: Fehlermeldungen werden an die Datei ERRORS angehangen.

• Befehl > DATEI >2&1<stdout> und <stderr> werden in die Datei DATEI geschrieben.

Auja, heel bedankt! 👍👍
Ich finde Bashscripte mächtig interessant, aber kenne mich gar nicht damit aus. Will ich aber ändern. 😉

[Der Martin]

Hallo Jörg,

Auja, heel bedankt! 👍👍

hey, lekker! Hier praat iemand Nederlands! 😀

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Jörg,

letztlich ist das uraltes Zeugs, das mindestens in die 70er Jahre des letzten Jahrtausends zurückreicht.

Das Betriebssystem verwaltet geöffnete Dateien über Filedeskriptoren (oder Filehandles) und stellt jedem Programm Deskriptoren für die Standardeingabe, -ausgabe und -fehlerausgabe bereit. Diese Deskriptoren stehen in einer Tabelle, und die stdin/out/err Deskriptoren sind die ersten drei darin.

Die Schreibweise n>datei bedeutet: Leite Ausgaben auf Dateideskriptor n in die genannte Datei um. n>>datei ist das gleiche, nur mit Anhängen statt Ersetzen.

Es gibt auch 2>&1. Das & bedeutet: Was folgt, ist kein Dateiname, sondern eine Deskriptornummer. Deswegen leitet diese Notation die Ausgaben auf stderr nach stdout um.

Der Versuch 2>&0 dürfte aber scheitern, weil Deskriptor 0 eine Eingabedatei ist 😀

Dieses Konstrukt ist weit verbreitet. In Unix und seinem Kind Linux, sowie in CP/M und seinen Nachkommen MS-DOS und Windows.

Rolf

[Martl]

Hallo Rolf,

70-er Jahre des letzten Jahrtausends? Echt? So um 1070?

Grüße, Martl

[Rolf B]

Hallo Martl,

ja. Zumindest fühle ich mich heute so alt…

Rolf

[Der Martin]

Hallo,

• Befehl >> DATEI: Normale Ausgaben werden an die Datei DATEI angehangen.

Autsch! Nein!
Wie oft denn noch?

Einen schönen Tag noch
 Martin