ubuntuusers.de

Hallo, wie der Titel schon sagt habe ich ein Problem mit dem mySQL query, das in diesen meine variablen nicht als solche erkannt werden, sprich ich habe $variablenname Ich habe ein BashScript was mir einen CSV Datein einlist was auch hinhaut hier mal der CODE

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#!/bin/bash
PWD=`pwd`

while IFS="|" read linkhash link text1 text2 datum rubid
	do
	echo "Daten gelanden";

	#echo $link
	#echo $text1
	#echo $text2
	#echo $datum
	#echo $rubid


mysql --user=root --password=123456789 << 'EOF'
use joomla_db;
INSERT INTO `xd5vq_content` (`id`, `asset_id`, `title`, `linkhash`, `alias`, `introtext`, `fulltext`, `state`, `catid`, `created`, `created_by`, `created_by_alias`, `modified`, `modified_by`, `checked_out`, `checked_out_time`, \
 													`publish_up`, `publish_down`, `images`, `urls`, `attribs`, `version`, `ordering`, `metakey`, `metadesc`, `access`, `hits`, `metadata`, `featured`, `language`, `xreference`) \
													VALUES (NULL, '99', '$link', '$linkhash', NULL, '$text1', NULL, '1', '8', NULL, NULL, NULL, NULL, NULL, NULL, \
													NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, '*', NULL);
EOF

done < $PWD/data/temp_sql.csv

???

@Pythonator Du hast das EOF in Zeile 15 in Anführungsstriche gesetzt, dann werden keine Variablen ersetzt.

achso hmmm, aber wenn ich die Anführungszeichen nicht setze, funktioniert mein Query nicht und ich bekomme ich einen Syntax ERROR 1064 und für jede spalte die Meldung "Kommando nicht gefunden."

@Pythonator Die Backticks (`) haben für die Shell auch eine besondere Bedeutung. Die würde ich durch " ersetzen, denn das ist letztendlich auch Standard-SQL im Gegensatz zu den Backticks die soweit ich weiss nur MySQL so verwendet. Man muss MySQL dann eventuell in der Konfiguration noch sagen das es die " standardkonform verwenden soll und nicht als Zeichenkettenbegrenzer. Andernfalls müsstest Du alle ` vor der Shell durch jeweils einen \\ schützen.

bj@god:~$ echo `pwd`
/home/bj
bj@god:~$ echo \`pwd\`
`pwd` 

also die Variable fuer den Pfad ist nicht das Problem die wird erkannt, das Problem sind die Variabel in dem INSERT QUERY die nicht erkannt werden.

ok hab es jetzt hin bekommen, wenn ich die Kurzschreibweise nutze geht es warum auch immer

1
2

INSERT INTO xd5vq_content VALUES (NULL, '99', '$var', '$linkhash', '', '$var', NULL, '1', '$rubid', '$datum', NULL, NULL, '$datum', '43', NULL, \
													NULL, '$datum', NULL, NULL, NULL, NULL, '1', NULL, NULL, NULL, '1', NULL, NULL, NULL, '*', NULL);

irgendwie ist doch mySQL/SQL gewöhnungsbedürftig was die befehle angeht, würde gerne mal wissen ob ein query in der länge beschränkt ist.

Pythonator schrieb:

also die Variable fuer den Pfad ist nicht das Problem die wird erkannt, das Problem sind die Variabel in dem INSERT QUERY die nicht erkannt werden.

Ich hatte pwd nur als Beispiel genommen. Das illustriert doch genau Dein Problem, egal was Du zwischen die ` schreibst, die Shell wird versuchen es auszuführen und das Ergebnis zu verwenden, Du möchtest aber das mit den ` nichts passiert. Also mal mit einem Beispiel aus Deinem Code anstelle von pwd:

bj@god:~$ echo `xd5vq_content`
xd5vq_content: command not found

bj@god:~$ echo \`xd5vq_content\`
`xd5vq_content` 

Der Grund warum es in der Kurzschreibweise funktioniert ist nicht die Kurzschreibweise, sondern das Du dort nichts mehr mit ` maskierst und das es auch sehr unwahrscheinlich ist, dass xd5vq_content irgendwann einmal ein reserviertes Schlüsselwort von MySQL werden wird.

Anstelle der Backticks im Bash-Skript selbst würde ich übrigens $(…) verwenden. Das ist POSIX-Standard, leichter lesbar, und kann wenn es sein muss auch verschachtelt werden. Also in Zeile 2:

1

PWD=$(pwd)

Marc_BlackJack_Rintsch schrieb:

Anstelle der Backticks im Bash-Skript selbst würde ich übrigens $(…) verwenden. Das ist POSIX-Standard, leichter lesbar, und kann wenn es sein muss auch verschachtelt werden. Also in Zeile 2:

1	PWD=$(pwd)

Ich würde die Zuweisung ganz weglassen, weil die Shell eh $PWD kennt.

Neben der Backticksänderung würde ich die ganzen NULL-Spalten weglassen, oder habe ich was verpasst?

user_unknown schrieb:

Marc_BlackJack_Rintsch schrieb:

1	PWD=$(pwd)

Ich würde die Zuweisung ganz weglassen, weil die Shell eh $PWD kennt.

Es kann aber sinnvoll sein, sich darauf nicht zu verlassen und den Wert noch einmal zu ermitteln. PWD ist ja eine ganz normale Shell-Variable, die man auch einfach umsetzen kann. Ähnliches gilt für USER - vielleicht ist es da sogar noch wichtiger.

rklm schrieb:

user_unknown schrieb:

Marc_BlackJack_Rintsch schrieb:

1	PWD=$(pwd)

Ich würde die Zuweisung ganz weglassen, weil die Shell eh $PWD kennt.

Es kann aber sinnvoll sein, sich darauf nicht zu verlassen und den Wert noch einmal zu ermitteln. PWD ist ja eine ganz normale Shell-Variable, die man auch einfach umsetzen kann. Ähnliches gilt für USER - vielleicht ist es da sogar noch wichtiger.

Die Manpage von bash sagt:

1

PWD    The current working directory as set by the cd command.

und type pwd:

1
2

type pwd
pwd ist eine von der Shell mitgelieferte Funktion.

und man bash /pwd:

1
2
3
4

       pwd [-LP]
              Print  the absolute pathname of the current working directory.  The pathname printed contains no symbolic links if the -P option is supplied
              or the -o physical option to the set builtin command is enabled.  If the -L option is used, the pathname printed may contain symbolic links.
              The return status is 0 unless an error occurs while reading the name of the current directory or an invalid option is supplied.

Das ist also alles dasselbe. PWD mit pwd zu setzen ist wahrscheinlich ein Zirkelschluss, weil pwd sein Wissen aus PWD bezieht. Einer Systemvariablen selbst Werte zuzuweisen sollte man grundsätzlich unterlassen, wenn man nicht dringende Gründe hat, das zu tun.

Die Bedeutung der Feststellung, PWD sei eine normale Shell-Variable, erschließt sich mir nicht, insbesondere nicht deren Relevanz für das vorliegende Problem.

Es ist kein Zirkelschluss, pwd bekommt den Wert nicht von $PWD:

bj@god:~$ PWD=foobar
bj@god:foobar$ pwd
/home/bj
bj@god:foobar$ echo $PWD
foobar 

Ich denke genau das war mit „normale Shellvariable“ gemeint: Die kann beliebig geändert werden und muss nicht zwangsläufig dem aktuellen Arbeitsverzeichnis des Prozesses entsprechen. Wenn man also irgendetwas aufgerufen hat (ausser cd) kann man sich hinterher nicht 100%ig sicher sein was $PWD für einen Wert enthält. Am Anfang eines Skriptes allerdings schon, sofern sich die Shell an POSIX hält.

Marc_BlackJack_Rintsch schrieb:

Es ist kein Zirkelschluss, pwd bekommt den Wert nicht von $PWD:

... sondern von getcwd().

bj@god:~$ PWD=foobar
bj@god:foobar$ pwd
/home/bj
bj@god:foobar$ echo $PWD
foobar 

Genau.

Ich denke genau das war mit „normale Shellvariable“ gemeint: Die kann beliebig geändert werden und muss nicht zwangsläufig dem aktuellen Arbeitsverzeichnis des Prozesses entsprechen.

Genau das war gemeint.

Wenn man also irgendetwas aufgerufen hat (ausser cd) kann man sich hinterher nicht 100%ig sicher sein was $PWD für einen Wert enthält.

Wenn Du mit "irgendetwas" beliebige Prozesse meinst, ist das falsch, denn die können ja nicht die Umgebung der aufrufenden Shell ändern. Letztlich können nur Aliase, Funktionen und irgendwelche Tricks mit eval den Wert ändern.

Am Anfang eines Skriptes allerdings schon, sofern sich die Shell an POSIX hält.

1
2
3
4

$ pwd
/tmp
$ PWD=foo sh -c 'echo $PWD'
/tmp

Guter Punkt! Das entschärft die Sache natürlich deutlich. Bei $USER und $HOME ist das nicht so und da ist es auch schlimmer:

1
2
3
4

$ echo "$USER - $HOME"
robert - /home/robert
$ USER=x HOME=/ sh -c 'echo "$USER - $HOME"'
x - /

Wenn man da auf der sicheren Seite sein will, müsste man das so machen:

1
2

USER=$(ud -un)
HOME=$(cd && pwd)

Macht natürlich keiner...

Ja, wenn man sich selbst ins Knie schießen will, dann schafft man das irgendwie.

Wenn ich PWD=foobar eingebe, dann zeigt mir der Prompt an, wie bei Dir, Marc, ich sei in foobar, was natürlich Unfug ist. Natürlich gibt es bei mir foobar-Verzeichnisse, aber

1
2
3
4
5

t201:~/proj/mini/forum > PWD=foobar
t201:foobar > fcd forum 
1) match: /home/stefan/proj/mini/forum
t201:~/proj/mini/forum > echo $PWD 
/home/stefan/proj/mini/forum

nicht überall. Rufe ich danach ein Programm auf (fcd), welches seinerseits cd aufruft, ist PWD wieder umgesetzt. Gut - das könnte man jetzt spitzfindig dahingehend in die Verteidigung des Vorgehens einbauen, dass man davon ausgeht, dass zwischen der Zuweisung von $PWD und letzter Verwendung kein Verzeichniswechsel mehr stattfinden darf - mehr muss man sich nicht merken.

Nur, wenn man auf die Zuweisung zu PWD generell verzichtet, was meine Empfehlung ist, dann hat man das Problem auch nicht. Man läuft mit der willkürlichen Zuweisung zu PWD ohnehin Gefahr sich in Hudel zu bringen:

1
2
3

t201:~/proj/mini/forum > PWD=foobar
t201:foobar > cd -
bash: cd: foobar: Datei oder Verzeichnis nicht gefunden

Marc_BlackJack_Rintsch schrieb:

Es ist kein Zirkelschluss, pwd bekommt den Wert nicht von $PWD:

bj@god:~$ PWD=foobar
bj@god:foobar$ pwd
/home/bj
bj@god:foobar$ echo $PWD
foobar 

@Marc

Ich denke genau das war mit „normale Shellvariable“ gemeint: Die kann beliebig geändert werden und muss nicht zwangsläufig dem aktuellen Arbeitsverzeichnis des Prozesses entsprechen. Wenn man also irgendetwas aufgerufen hat (ausser cd) kann man sich hinterher nicht 100%ig sicher sein was $PWD für einen Wert enthält. Am Anfang eines Skriptes allerdings schon, sofern sich die Shell an POSIX hält.

Tja - und ein Skript ist ja meist eine recht übersichtliche Sache. Wenn man da also keinen Humbug macht, wie PWD umzudefinieren, muss man es auch nicht zurücksetzen, wie Du richtig feststellst:

1
2
3
4
5
6
7
8
9

t201:~/proj/mini/forum > echo "echo \$PWD" > pwd.sh 
t201:~/proj/mini/forum > cat pwd.sh 
echo $PWD
t201:~/proj/mini/forum > chmod a+x ./pwd.sh 
t201:~/proj/mini/forum > ./pwd.sh 
/home/stefan/proj/mini/forum
t201:~/proj/mini/forum > PWD=foobar
t201:foobar > ./pwd.sh 
/home/stefan/proj/mini/forum

Hier wurde die Variable in Zeile 2 zugewiesen, gleich hinter dem Shebang.

1
2

#!/bin/bash
PWD=`pwd`

Also wo soll die unkonventionelle Zuweisung geschehen sein? Und wenn sie hinterher geschieht, dann ist es auch wurscht, ob man nun in Zeile 2 was geschrieben hat, was ohnehin der Fall war, oder nicht.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

t201:~/proj/mini/forum > cat pwd.sh 
echo $PWD
PWD=/foobar
echo $PWD
cd /tmp
echo $PWD
t201:~/proj/mini/forum > ./pwd.sh 
/home/stefan/proj/mini/forum
/foobar
/tmp

Wenn man PWD auf den Startwert von $(pwd) setzt um dann in ein anderes Verzeichnis zu wechseln, um dort auf $PWD zurückzugreifen, wenn es nicht mehr $(pwd) ist, schießt man sich selbst ins Knie, weil beim Verzeichniswechsel die schöne Arbeit zunichte gemacht wurde.

Außerdem - man soll ja nicht von sich selbst ausgehen, aber vor diesem Thread wusste ich nichts von der Koppelung von cd mit PWD, obwohl das ja sein muss, damit $PWD funktionieren kann. Ja, und dass einem die Shell Murks anzeigt, wenn man $PWD im Prompt hat, war mir auch nicht bewusst.

1
2
3
4
5

t201:~/proj/mini/forum > PWD=/tmp
t201:/tmp > cd -
/tmp
t201:/tmp > cd -
/tmp

Wenn man "ls" macht, und vorher nicht schon in /tmp war, sieht man, dass der Prompt täuscht und man nach wie vor im Startverzeichnis ist.

Normale Shellvariablen ändern nicht den Wert, wenn man ein cd ausführt.

Zirkelschluss war aber falsch, das räume ich ein, und pwd bekommt das aktuelle Verzeichnis nicht von PWD, auch das war falsch. Richtig war aber die Warnung, dass solche Zuweisungen in einem Shellscript nichts verloren haben, dass die Umnutzung von Systemvariablen immer riskant ist, denn der flüchtige Leser rechnet nicht damit, dass man das tut.