sh: sql code will nicht in die Datenbank

[Sholvar]

Ich versuche gerade seit geschlagenen anderthalbstunden nen ziemlich langes sql script in meine Datenbank zu kriegen.
Das mit dem LOAD DATA kann ich scheinbar nicht machen, weil der demon keine --infile Freigabe hat (soll er auch nicht erhalten). Über google bekomme ich nur solche Sachen oder umfangreiche PHP Scripts die das zu umgehen versuchen. Ich bin aber zu stur das über PHP zu machen. Solche Sachen müssen in einer Zeile mit der Shell gehen, verdammich!

Also hab ich halt probiert mir was zurecht zu tricksen:

egrep '.*' scriptfile.sql | mysql -u root -p -e

darauf bekomme ich die Fehlermeldung "-e braucht ein Argument" ich hab aber keine Ahnung wie ich das bei ner pipe zuweisen kann.
Wie mach ich denn so eine pipe richtig?

Also hab ich es mit ner Liste probiert:

mysql -u root -p -e `egrep '.*' scriptfile.sql`

hat er wieder ein problem mit, denn die Liste ist ihm zu lang.
Gibts denn keine Möglichkeit die Liste zu erweitern?

Ich bin jetzt am Ende von meinem Latein. *weiße Fahne* Bitte Hilfe!

 

[drwilly]

Kann mangels sql installation nix testen, aber pack die befehle doch inne tempdatei und dann

source    (\.) Execute an SQL script file. Takes a file name as an argument.

 

[Sholvar]

sorry hab deine Antwort nicht gleich lesen können.

hab jetzt folgendes probiert und das ging:

mysql -u root -p db_name < scriptname.sql

Trotzdem würde ich gern noch ne grep variante hinbekommen (mit ner pipe).
Ich denke ich werde die Pipes nur mit Beispielen kapieren. Manchmal ruft man
a | b
auf und b bekommt das ergebnis von a als parameter und manchmal wieder nicht (wie in dem beispiel oben). Und ich versteh die Ursache dafür nicht. Deshalb kann ich nicht selbst erkennen, wann warum ein Pipe nicht geht.

 

[voelkerballtier]

also ich bin auch kein experte auf der shell, aber so wie ich pipes verstanden habe, sollte wenn das geht

mysql -u root -p db_name < scriptname.sql

auch das gehen:

cat scriptname.sql | mysql -u root -p db_name

 

[Whcttyh]

p1 | p2 bedeutet doch nur stdout von p1 wird stdin von p2?

 

[HERR 2FICKENDEHUNDE]

das problem ist der punkt in dem ausdruck bei egrep:

man egrep:

. ein Punkt passt auf jeden Buchstaben außer auf das Zeilenende


das heisst er setzt die zeilen deines skripts hinterneinander.

aus

1.
2.
3.
4.
5.


wird

1.2.3.4.5.

weil egrep alle treffer AUSSER zeilenende findet und somit jeden treffer hinten dranhängt ohne newline. deshalb meckert er auch, dass die übergebene parameter liste zu lang ist

 

[Sholvar]

hab den Fehler begangen es aufm Mac nachzuschlagen.
Da liest man sich durch 100 Seiten bla bis man endlich da is:

The period . matches any single character.

was nicht unbedingt die gleiche Aussage ist. Aufm SuSE hab ich aber auch die Aussage gefinden, dass es auf alles außer Zeilenende zutrifft.

Ich bin aber nicht der Meinung, dass grep deshalb alles in eine Zeile packt. Wenn man einfach "egrep '.*' bla.sql" eingibt kommt jede Zeile für sich raus. Interpretieren würde ich das Ergebnis eher so, dass grep jede Zeile durchsucht, dort einen Match auf .* findet, die Zeile ausspuckt + NEWLINE, und dann in der nächsten Zeile weitersucht und wieder fündig wird. Wenn er nicht selbst ein NEWLINE an seinen Match anfügt, dann würdest du, wenn du nach "egrep 'function' *.php" suchst, ja auch alle while-Zeilen in eine Zeile zusammengepappt bekommen. Die gibt er aber auch schön untereinander aus.

 

[HERR 2FICKENDEHUNDE]

jo hast recht, grep such zeilenweise und gibt dann als treffer die gesamte zeile aus.

versch mal bitte nur den punkt:

grep '.' skript.sql


€: das ist auch unfug, weil kommt aufs selbe raus.

 

[drwilly]

egrep 'function' *.php

Das hat mit egrep nix zu tun. An der Stelle übernimmt Bash das vervollständigen der Dateinamen und Bash verwendet nur wildcards, keine extended regexps.
Darum: Augen auf beim Eierkauf