Discussion:
jsonlint decode in shell
(zu alt für eine Antwort)
Jan Novak
2021-01-12 11:04:31 UTC
Permalink
Hallo,

ich habe unten stehendes Script, welches mir den json Inhalt der
übergebenen Datei oder des übergebenen Jsons Strings formatiert anzeigen
soll.

Bei der Ünergabe einer Datei klappt das, der gleiche Inhalt als
Parameter endet mit einem

No JSON object could be decoded

Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich
erfolglos versucht.


#!/bin/bash
if [ "$1" ]; then
if [ -e "$1" ]; then
python -m json.tool "$1"
else
echo $1| python -m json.tool
fi
else
echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi




Jan
Helmut Waitzmann
2021-01-12 20:12:14 UTC
Permalink
Post by Jan Novak
ich habe unten stehendes Script, welches mir den json Inhalt der
übergebenen Datei oder des übergebenen Jsons Strings formatiert
anzeigen soll.
Bei der Ünergabe einer Datei klappt das, der gleiche Inhalt als
Parameter endet mit einem
No JSON object could be decoded
Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich
erfolglos versucht.
#!/bin/bash
if [ "$1" ]; then
if [ -e "$1" ]; then
python -m json.tool "$1"
else
echo $1| python -m json.tool
fi
else
echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Du möchtest gerne, dass „echo“ Dir gewisse[1] Parameter nicht so
ausgibt, wie Du sie ihm angibst, sondern sie auf spezielle Weise vor
dem Ausgeben bearbeitet? 

Du möchtest gerne, dass gewisse[1] Parameter nicht so an „echo“
übergeben werden, wie Du sie angibst, sondern, dass sie erst noch
zersägt werden? 

Ich geb' zu, beide Fragen sind rhetorisch gemeint. 


[1] Keiner – weder Du selbst noch jemand anderes – möchte sich im
Vorfeld der Fehlerdiagnose überlegen müssen, ob der übergebene
Parameter so aussehen könnte, dass solche Verhunzungseffekte
auftreten und zu Fehlern führen können. 

Also:  Ersetze bitte alle Variablenexpansionen „$1“ durch die
Variante in Anführungszeichen: „"$1"“. 

Schick „echo“ in den Ruhestand.  „printf“ ist angetreten, die
„echo“‐Misere zu beenden.  Im Einzelnen gehe so vor: 

Ersetze das erste „echo“ durch „printf '%s\n'“. 


Und wenn Du es vollends verbessern willst, ersetze bitte das zweite
gesamte „echo“‐Kommando durch

printf '\n\t%s\n' "${0##*/}"' [fson file] | [json string]'

Dann probiere noch mal, ob der Fehler weiterhin auftritt. 
Jan Novak
2021-01-13 06:46:39 UTC
Permalink
Post by Helmut Waitzmann
Post by Jan Novak
No JSON object could be decoded
Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich
erfolglos versucht.
#!/bin/bash
if [ "$1" ]; then
   if [ -e "$1" ]; then
       python -m json.tool "$1"
   else
       echo $1| python -m json.tool
   fi
else
   echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Du möchtest gerne, dass „echo“ Dir gewisse[1] Parameter nicht so
ausgibt, wie Du sie ihm angibst, sondern sie auf spezielle Weise vor dem
Ausgeben bearbeitet?
Wie kommst du darauf, bw. _wo_ habe ich das geschrieben??
Post by Helmut Waitzmann
Du möchtest gerne, dass gewisse[1] Parameter nicht so an „echo“
übergeben werden, wie Du sie angibst, sondern, dass sie erst noch
zersägt werden?
Siehe oben: Nichts zersägen.
Post by Helmut Waitzmann
Ich geb' zu, beide Fragen sind rhetorisch gemeint.
Kommt nicht wirklich gut und lustig ist es auch nicht.
Post by Helmut Waitzmann
Ersetze das erste „echo“ durch „printf '%s\n'“.
Ein

printf '%s\n' {"test":"bla"}

gibt

{test:bla}


aus. Das ist kein json String mehr. Die doppelten Anführungszeichen fehlen.
Post by Helmut Waitzmann
Und wenn Du es vollends verbessern willst, ersetze bitte das zweite
gesamte „echo“‐Kommando durch
printf '\n\t%s\n' "${0##*/}"' [fson file] | [json string]'
1. ist das doch nur der Hinweise, wie das kleine Script aufgerufen
werden soll und 2. ist

printf '\n\t%s\n' "${0##*/}"'

gegen

echo -e "\n\t$(basename $0)"

weder falsch noch problematisch. Abgesehen davon, dass es einfacher zu
schreiben und verständlicher zu lesen ist.
Aber das geht am Thema vorbei.

Das Scriprt soll entweder den Inhalt einer json Datei anzeigen (das
klappt ja auch) oder das, was über den 1. Parameter übergeben wird.
Nichts soll "zersägt" oder geändert werden.


Jan
Stefan Kanthak
2021-01-13 13:04:41 UTC
Permalink
Post by Jan Novak
Post by Jan Novak
No JSON object could be decoded
Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Post by Jan Novak
Post by Jan Novak
erfolglos versucht.
~~~~~~~~~~~~~~~
Post by Jan Novak
Post by Jan Novak
#!/bin/bash
if [ "$1" ]; then
if [ -e "$1" ]; then
python -m json.tool "$1"
else
echo $1| python -m json.tool
fi
else
echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Du möchtest gerne, dass "echo" Dir gewisse[1] Parameter nicht so
ausgibt, wie Du sie ihm angibst, sondern sie auf spezielle Weise vor dem
Ausgeben bearbeitet?
Wie kommst du darauf, bw. _wo_ habe ich das geschrieben??
Ich hab's Dir unterstrichen!
Post by Jan Novak
Du möchtest gerne, dass gewisse[1] Parameter nicht so an "echo"
übergeben werden, wie Du sie angibst, sondern, dass sie erst noch
zersägt werden?
Siehe oben: Nichts zersägen.
Doch: Deine Anfaengerfehler taugen bestens als abschreckende Beispiele!
Post by Jan Novak
Ich geb' zu, beide Fragen sind rhetorisch gemeint.
Kommt nicht wirklich gut und lustig ist es auch nicht.
Ersetze das erste "echo" durch "printf '%s\n'".
Ein
printf '%s\n' {"test":"bla"}
gibt
{test:bla}
aus. Das ist kein json String mehr. Die doppelten Anführungszeichen fehlen.
ANFAENGERFEHLER: die Shell interpretiert Anfuehrungszeichen ... und
wirft Deine weg!

printf '%s\n' '{"test":"bla"}'

[...]
Post by Jan Novak
Das Scriprt soll entweder den Inhalt einer json Datei anzeigen (das
klappt ja auch) oder das, was über den 1. Parameter übergeben wird.
Nichts soll "zersägt" oder geändert werden.
Dann schliesse den 1. Parameter in Apostrophe ein!

wehret den Anfaengern!
Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>
Jan Novak
2021-01-13 13:43:03 UTC
Permalink
Post by Stefan Kanthak
Post by Jan Novak
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich erfolglos versucht.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Post by Jan Novak
Wie kommst du darauf, bw. _wo_ habe ich das geschrieben??
Abgesehen davon, dass dieses völlig am Thema vorbei geht, möchte ich
dennoch klarstellen:
Da soll nichts _zersägt_ und auch nicht zerschnitten oder manipuliert
werden. Ich habe nur geschrieben, dass ich versucht habe, $1 in
irgendeiner Weise zu quoten, damit dieses vom Script richtig gelesen
werden kann.
Post by Stefan Kanthak
Post by Jan Novak
Siehe oben: Nichts zersägen.
Doch: Deine Anfaengerfehler taugen bestens als abschreckende Beispiele!
Wofür?
Das sich "normale" Menschen hier nicht mehr hintrauen und keine Fragen
mehr stellen. Warum sind die Deutschen Linux Foren so wenig frequentiert
(z.B. im Vergleich zu Deutschen Windows Foren oder im Vergleich zu
englisch sprachigen Foren), obwohl in D so viele Linux einsetzen.
Das einzige wofür dein Satz geeignet ist, ist User ab zu schrecken, hier
eine Frage zu stellen. Das ist doch bestimmt nicht dein Ansatz (sonst
würdest du wohl hier nicht lesen und schreiben).
Um die Sache zu beenden, möchte ich mich für meine nicht 100%ig korrekt
formulierte Frage entschuldigen und würde gerne zum Thema zurück kommen.
Post by Stefan Kanthak
ANFAENGERFEHLER: die Shell interpretiert Anfuehrungszeichen ... und
wirft Deine weg!
printf '%s\n' '{"test":"bla"}'
[...]
Post by Jan Novak
Das Scriprt soll entweder den Inhalt einer json Datei anzeigen (das
klappt ja auch) oder das, was über den 1. Parameter übergeben wird.
Nichts soll "zersägt" oder geändert werden.
Dann schliesse den 1. Parameter in Apostrophe ein!
Ja dann... genau darum geht es doch.
Klar geht es mit '{"test":"bla"}' ... aber genau das erste und das
letzte ' soll das script setzen. WARUM:
Weil der Json String sehr, sehr lang sein kann. Denn will ich einfach
mit C&P an das script übergeben - quick and easy - und nicht nach dem
einfügen am Anfang und Ende ein ' setzen, bevor ich es absende. Dann
barcuej ich das Script auch nicht. Dann kann ich es gleich echo/printf
ausgeben und | python -m json.tool anhängen.
Genau das wollte ich mir ersparen.
Post by Stefan Kanthak
wehret den Anfaengern!
Konntest du dir jetzt nicht ersparen....

_IRONIE_
Nein nicht doch. Verbannt sie und lasst uns in Ruhe. Wir tragen doch
gerne dazu bei, dass die großen immer größer und fetter werden. Es lebe
die Nische!


Jan


Jan
Helmut Waitzmann
2021-01-14 01:31:21 UTC
Permalink
Post by Jan Novak
Post by Stefan Kanthak
Post by Jan Novak
Das Scriprt soll entweder den Inhalt einer json Datei anzeigen
(das klappt ja auch) oder das, was über den 1. Parameter
übergeben wird.
Nichts soll "zersägt" oder geändert werden.
Dann schliesse den 1. Parameter in Apostrophe ein!
Ja dann... genau darum geht es doch.
Klar geht es mit '{"test":"bla"}' ... aber genau das erste und das
Weil der Json String sehr, sehr lang sein kann. Denn will ich
einfach mit C&P an das script übergeben - quick and easy - und nicht
nach dem einfügen am Anfang und Ende ein ' setzen, bevor ich es
absende.
Ich bin mir jetzt nicht sicher, ob ich Dich richtig verstehe – falls
nicht, korrigiere mich bitte. 

Du möchtest also in einem interaktiven Shell in einem Terminal eine
Kommandozeile eintippen, die einen Aufruf des Skripts darstellen
wird. 

Du tippst dazu den Namen des Skripts, ein Leerzeichen und dann
mittels C&P eine Zeichenkette, die Du dem Skript übergeben willst. 
Dann sendest Du die Kommandozeile ab.  Richtig?

Falls die Antwort „Ja“ heißt, heißt meine:  Das geht nicht:  Es gibt
keine Möglichkeit, im Skript Apostrophe, die der Aufrufer weggelassen
hat, weil er bei den übergebenen Parametern beim Quoting sparen
wollte, zu korrigieren. 

Der Grund ist, dass die Kommandozeile vom aufrufenden Shell
(falsch) interpretiert wird; während das Skript von einem neuen, dem
aufgerufenenen Shell, abgearbeitet wird.  Der aufgerufene Shell kommt
an die Kommandozeile des aufrufenden Shells nicht ran; deshalb kann
er auch keine Apostrophe nachträglich vorne und hinten dranhängen.

Er kommt deshalb nicht ran, weil der aufrufende Shell dem
aufgerufenen Shell keine Kommandozeile sondern eine Parameterliste
übergibt.  Ist die aber falsch erstellt, ist es für alle Korrekturen
bereits zu spät. 

Das kommt daher, dass es im Linux‐Betriebssystem keine Kommandozeilen
sondern nur Parameterlisten gibt:  Wenn ein Programm gestartet wird,
erhält es vom Betriebssystemkern eine Parameterliste.  Stell sie Dir
als ein Regal mit mehreren Fächern vor:  Jeder Parameter hat ein
eigenes Fach. 

Shells haben im Gegensatz dazu keine Regalfächer in der
Kommandozeile:  Wenn Du eine Kommandozeile eintippst, gibt es keine
Fächer:  Du tippst einfach ein Zeichen nach dem anderen ein.  Wenn
der Shell ausgehend von der Kommandozeile ein Programm starten soll,
muss er die Fächer aus der eingetippten Kommandozeile selber
„errmitteln“ und damit dann ein Regal füllen, das er dem
Betriebssystemkern zusammen mit der Information, welches Programm
gestartet werden soll, übergibt. 

Natürlich muss die Kommandozeile dem Shell irgendwie anzeigen, wo die
Fächerwände in der Kommandozeile sein sollen, welche Teile der
Kommandozeile also je einen Parameter ausmachen sollen.  Die
Programmiersprache, die der Shell dem Anwender bereitstellt, gibt
dafür bestimmten Zeichen in der Kommandozeile eine Sonderbedeutung,
in Deinem Fall beispielsweise den Anführungszeichen. 

Möchtest Du nun ein Anführungszeichen in einen Parameter
hineinbekommen, musst Du Dich der Quoting‐Mechanismen bedienen (siehe
anderes Posting).  Ohne das bekommt der aufgerufene Shell die
Anführungszeichen nicht zu Gesicht: genau das, was Du beobachtet
hast. 
Post by Jan Novak
Dann barcuej ich das Script auch nicht. Dann kann ich es gleich
echo/printf ausgeben und | python -m json.tool anhängen. Genau das
wollte ich mir ersparen.
Du brauchst es dann in der Tat nicht.  Und jetzt halt Dich fest:  Du
brauchst auch „echo“ oder „printf“ nicht.  Starte einfach in einem
Terminal

python -m json.tool

Das erwartet doch auf seiner Standareingabe die Daten.  Also gib sie
ihm:  Spuck' sie ihm mit C&P ins Terminal, tippe – falls C&P kein
Newline‐Zeichen mitliefert, ein Newline‐Zeichen ein.  Das Programm
erhält vom Terminal die eingetippte Zeile, liest und bearbeitet sie
und – je nachdem, wie es geschrieben ist, beendet sich (eher
unwahrscheinlich) oder wartet auf weitere Zeilen (eher
wahrscheinlich). 

Wenn es so geschrieben ist, dass es auf weitere Daten wartet, tippe
das Zeichen, das eine Zeile abschickt, ohne ein Newline‐Zeichen
dranzuhängen (vermutlich Control-D) ein.  Das bewirkt, dass das
Terminal dem Programm signalisiert, dass 0 Zeichen zum Lesen
bereitstehen.  Das wird vom Programm als Dateiende interpretiert:  Es
weiß, dass es jetzt alle Daten gelesen hat und die Verarbeitung
abschließen kann. 

Ich empfehle Dir wärmstens, mal ein gutes Buch über die
Unix‐Betriebssysteme zu lesen – und damit meine ich kein Buch über
Shells. 

Ich habe mal „Maurice J. Bach: The Design of the UNIX Operating
System“ gelesen.  Das ist inzwischen etwas in die Jahre gekommen. 
Diese darin beschriebenen Grundlagen stimmen aber immer noch.  Ich
meine, es soll auch eine deutsche Übersetzung „So funktioniert das
UNIX‐Betriebssystem“ (oder so ähnlich) geben. 

Wenn Du die Grundlagen verstanden hast, dann kannst Du ein Buch über
Shells oder auch einfach nur

man -- bash

lesen und wirst Dich vor „Ah ja!  So funktioniert das!  Jetzt
fang' ich an, Shells zu verstehen!“ nicht mehr retten können. 
--
Hat man erst verstanden, wie Unix funktioniert, ist auch
das Shell-Handbuch kein Buch mit sieben Siegeln mehr.
Jan Novak
2021-01-14 06:07:10 UTC
Permalink
Post by Helmut Waitzmann
Du möchtest also in einem interaktiven Shell in einem Terminal eine
Kommandozeile eintippen, die einen Aufruf des Skripts darstellen wird.
Du tippst dazu den Namen des Skripts, ein Leerzeichen und dann mittels
C&P eine Zeichenkette, die Du dem Skript übergeben willst. Dann sendest
Du die Kommandozeile ab.  Richtig?
Falls die Antwort „Ja“ heißt, heißt meine:  Das geht nicht:  Es gibt
keine Möglichkeit, im Skript Apostrophe, die der Aufrufer weggelassen
hat, weil er bei den übergebenen Parametern beim Quoting sparen wollte,
zu korrigieren.
Aha. Danke Helmut, das ist eine Antwort die ich hören wollte, bzw. das
ist die Antwort auf meine Frage.
Post by Helmut Waitzmann
Der aufgerufene Shell kommt an
die Kommandozeile des aufrufenden Shells nicht ran; deshalb kann er auch
keine Apostrophe nachträglich vorne und hinten dranhängen.
verstehe. Das war mir nicht beaknnt.
Post by Helmut Waitzmann
Er kommt deshalb nicht ran, weil der aufrufende Shell dem aufgerufenen
Shell keine Kommandozeile sondern eine Parameterliste übergibt.  Ist die
aber falsch erstellt, ist es für alle Korrekturen bereits zu spät.
...
Post by Helmut Waitzmann
Du brauchst es dann in der Tat nicht.  Und jetzt halt Dich fest:  Du
brauchst auch „echo“ oder „printf“ nicht.  Starte einfach in einem Terminal
  python -m json.tool
Ach? Das wäre natürlich ein wunderbare Lösung....
Post by Helmut Waitzmann
Das erwartet doch auf seiner Standareingabe die Daten.  Also gib sie
ihm:  Spuck' sie ihm mit C&P ins Terminal, tippe – falls C&P kein
Newline‐Zeichen mitliefert, ein Newline‐Zeichen ein.  Das Programm
erhält vom Terminal die eingetippte Zeile, liest und bearbeitet sie
und – je nachdem, wie es geschrieben ist, beendet sich (eher
unwahrscheinlich) oder wartet auf weitere Zeilen (eher wahrscheinlich).
Das Problem hier ist aber, dass meine C&P json Strings wie schon gesagt
sehr lang sind - und - Zeilenumbrüche haben.
Solange der json String eine Zeile ist, funktioniert das.
Post by Helmut Waitzmann
Ich empfehle Dir wärmstens, mal ein gutes Buch über die
Unix‐Betriebssysteme zu lesen – und damit meine ich kein Buch über Shells.
:-)
Post by Helmut Waitzmann
Ich habe mal „Maurice J. Bach: The Design of the UNIX Operating System“
gelesen.  Das ist inzwischen etwas in die Jahre gekommen. Diese darin
beschriebenen Grundlagen stimmen aber immer noch.  Ich meine, es soll
auch eine deutsche Übersetzung „So funktioniert das UNIX‐Betriebssystem“
(oder so ähnlich) geben.
Wenn Du die Grundlagen verstanden hast, dann kannst Du ein Buch über
Shells
Danke für den Hinweis.Ich bin nicht mehr der Jüngste, aber ich ziehe das
in Betracht.


Danke für deine Ausführliche Erklärung.


Jan
Helmut Waitzmann
2021-01-14 18:38:14 UTC
Permalink
Post by Jan Novak
Post by Helmut Waitzmann
Du möchtest also in einem interaktiven Shell in einem Terminal
eine Kommandozeile eintippen, die einen Aufruf des Skripts
darstellen wird.
Du tippst dazu den Namen des Skripts, ein Leerzeichen und dann
mittels C&P eine Zeichenkette, die Du dem Skript übergeben willst.
Dann sendest Du die Kommandozeile ab. 
[…]
Post by Jan Novak
Post by Helmut Waitzmann
Starte einfach in einem Terminal
  python -m json.tool
Ach? Das wäre natürlich ein wunderbare Lösung....
Post by Helmut Waitzmann
Das erwartet doch auf seiner Standareingabe die Daten.  Also gib
sie ihm:  Spuck' sie ihm mit C&P ins Terminal, tippe – falls C&P
kein Newline‐Zeichen mitliefert, ein Newline‐Zeichen ein.  Das
Programm erhält vom Terminal die eingetippte Zeile, liest und
bearbeitet sie und – je nachdem, wie es geschrieben ist, beendet
sich (eher unwahrscheinlich) oder wartet auf weitere Zeilen (eher
wahrscheinlich).
Das Problem hier ist aber, dass meine C&P json Strings wie schon
gesagt sehr lang sind - und - Zeilenumbrüche haben.
Solange der json String eine Zeile ist, funktioniert das.
Ich vermute, es funktioniert auch mit mehreren Zeilen.  Schließlich
kann man in einem Terminal üblicherweise mehr als eine Zeile
eintippen. 

Da ist es vielleicht mal Zeit für einen konkreten Versuch: 


Du musst dazu (wie oben) wissen, welches Zeichen Du ins Terminal
eintippen musst, um eine Zeile ohne Newline‐Zeichen am Ende
abzuschicken.  In meinen Terminals ist es Control‐D, bei Dir
vermutlich auch. 

Aber Du kannst das Terminal fragen, welches Zeichen es ist, indem Du
im Terminal das folgende Kommando laufen lässst:

stty -a |
sed -E -ne \
'/(^[[:blank:]]*|.*[[:blank:]])(eof = [[:graph:]]+).*$/s//\2/p'

Bei meinem Terminal kommt da die Ausgabe


eof = ^D;

heraus. 

Wenn Du das Zeichen ermittelt hast, tippe im Terminal das folgende
Kommando ein:

cat > cut_and_pasted.txt

und lasse es loslaufen.  (Du wirst dabei im Terminal nichts „laufen“
sehen, sondern nur bemerken, dass der Shell‐Prompt nicht erscheint.) 
Jetzt gib dem Programm mittels C&P ins Terminal die JSON‐Daten. 

Danach tippe im Terminal ein Newline‐Zeichen und das Zeichen (s. o.),
das eine Zeile ohne Zeilenende abschickt.  Damit sollte sich das
gestartete „cat“ beenden und der Shell‐Prompt erscheinen. 

Schlage jetzt mit irgend einem Text‐Editor die Datei
„cut_and_pasted.txt“ auf.  Sind alle JSON‐Daten darin zu sehen?

Falls das der Fall ist, würde es mich sehr wundern, wenn es mit


python -m json.tool

nicht ebenso funktionieren würde.
Jan Novak
2021-01-19 06:02:58 UTC
Permalink
Aber Du kannst das Terminal fragen, welches Zeichen es ist, indem Du im
  stty -a |
  sed -E -ne \
    '/(^[[:blank:]]*|.*[[:blank:]])(eof = [[:graph:]]+).*$/s//\2/p'
Bei meinem Terminal kommt da die Ausgabe
  eof = ^D;
heraus.
Bei mir nur ein >



Jan
Helmut Waitzmann
2021-01-19 09:34:11 UTC
Permalink
Post by Jan Novak
Post by Helmut Waitzmann
Aber Du kannst das Terminal fragen, welches Zeichen es ist, indem
  stty -a |
  sed -E -ne \
    '/(^[[:blank:]]*|.*[[:blank:]])(eof = [[:graph:]]+).*$/s//\2/p'
Bei meinem Terminal kommt da die Ausgabe
  eof = ^D;
heraus.
Bei mir nur ein >
Sollte sich das Ausgabeformat von „stty“ geändert haben? 


Du kannst auch einfach mal


stty -a

laufen lassen und mit den eigenen Augen nach so etwas wie „eof“
(vielleicht auch in Großbuchstaben) Ausschau halten oder die Ausgabe
einfach mal hier zeigen. 
Jan Novak
2021-01-19 10:15:20 UTC
Permalink
Post by Helmut Waitzmann
Post by Jan Novak
Post by Helmut Waitzmann
Aber Du kannst das Terminal fragen, welches Zeichen es ist, indem Du
   stty -a |
   sed -E -ne \
     '/(^[[:blank:]]*|.*[[:blank:]])(eof = [[:graph:]]+).*$/s//\2/p'
Bei meinem Terminal kommt da die Ausgabe
   eof = ^D;
heraus.
Bei mir nur ein >
Sollte sich das Ausgabeformat von „stty“ geändert haben?
Du kannst auch einfach mal
  stty -a
laufen lassen und mit den eigenen Augen nach so etwas wie „eof“
(vielleicht auch in Großbuchstaben) Ausschau halten oder die Ausgabe
einfach mal hier zeigen.
Dann ist es so wie du schriebst: eof = ^D

OK, soweit so gut. Mal kucken, ob ich das so verwenden kann, wie du
geschrieben hast.
Danke.

Jan
Sieghard Schicktanz
2021-01-14 19:20:34 UTC
Permalink
Hallo Jan,
Post by Jan Novak
Post by Helmut Waitzmann
brauchst auch „echo“ oder „printf“ nicht.  Starte einfach in einem Terminal
  python -m json.tool
Ach? Das wäre natürlich ein wunderbare Lösung....
...
Post by Jan Novak
Das Problem hier ist aber, dass meine C&P json Strings wie schon gesagt
sehr lang sind - und - Zeilenumbrüche haben.
Solange der json String eine Zeile ist, funktioniert das.
Kennt das "python -m json.tool" einen interaktiven Modus? Wenn ja, starte
das halt in dem Modus, dann sollte gleich der eingebaute Interpreter auf
Eingaben warten, und die der Reihe nach - wenn mehrzeilig, dann auch in
mehreren Zeilen - abarbeiten. Um die Geschichte zu beenden, muß dann halt
noch mit einem Aufruf (AFAIR) "quit()" oder einem Ctrl-D die Bearbeitung
beendet werden.
Es ginge wohl auch, den "C&P json String" per Pipe zu übergeben, aber das
braucht wieder Shell-Aktivität und kann zu neuen Verwirrungen führen.

...
Post by Jan Novak
Danke für den Hinweis.Ich bin nicht mehr der Jüngste, aber ich ziehe das
in Betracht.
Man ist nie zu alt zum Lernen.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Jan Novak
2021-01-13 13:46:12 UTC
Permalink
Post by Stefan Kanthak
wehret den Anfaengern!
Du hast bestimmt keine Kinder...
sorry, das konnte ich mir jetzt nicht verkneifen.

Jan
Stefan Reuther
2021-01-13 16:47:47 UTC
Permalink
Post by Jan Novak
Post by Helmut Waitzmann
Post by Jan Novak
#!/bin/bash
if [ "$1" ]; then
   if [ -e "$1" ]; then
       python -m json.tool "$1"
   else
       echo $1| python -m json.tool
   fi
else
   echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Du möchtest gerne, dass „echo“ Dir gewisse[1] Parameter nicht so
ausgibt, wie Du sie ihm angibst, sondern sie auf spezielle Weise vor
dem Ausgeben bearbeitet?
Wie kommst du darauf, bw. _wo_ habe ich das geschrieben??
In deinem Skript.

Mit
echo "$1"
wird da nichts mehr kaputtgemacht. Die printf-Variante kommt dann noch
mit ein paar mehr Sonderfällen klar (also '-n', '\c' usw.).
Post by Jan Novak
Post by Helmut Waitzmann
Ersetze das erste „echo“ durch „printf '%s\n'“.
Ein
printf '%s\n'  {"test":"bla"}
gibt
{test:bla}
aus. Das ist kein json String mehr. Die doppelten Anführungszeichen fehlen.
Natürlich, du hast ja den Text {test:bla} übergeben, nur etwas originell
gequotet.

Gesucht ist
printf '%s\n' '{"test":"bla"}'
Post by Jan Novak
printf '\n\t%s\n' "${0##*/}"'
gegen
echo -e "\n\t$(basename $0)"
weder falsch noch problematisch.
Doch. Die zweite Variante wird $0 in Worte splitten und die Ausgabe des
basename-Kommandos zweimal parsen, einmal beim Einlesen der Ausgabe
durch die Shell und ein weiteres Mal durch 'echo -e'. Für ein
Einmal-Skript vielleicht ok, für was dauerhaftes nicht. Ersteres lässt
sich immerhin mit
echo -e "\n\t$(basename "$0")"
vermeiden, zweiteres nicht ohne Verzicht auf das 'echo'-Kommando dieser
Form.

Shell-Variablen sind eigentlich eine völlig einfache, völlig robuste
Sache, die alles Mögliche inkl. der abgefahrensten Sonderzeichen (außer
NUL) speichern können. Shell macht's einem nur schwerer als andere, sie
konsistent und korrekt zu verwenden.

- immer doppelquoten. Ausnahmen nur, wenn man wirklich sagt: hier will
ich in Worte splitten. Und bei "a=$b" sind die Quotes ebenfalls
entbehrlich.

- niemals irgendwelche Ausgaben parsen. Niemals "for i in $(ls *.x)",
immer "for i in *.x"; niemals "x=$(basename $y)", immer
"x=${y##*/}".

Wenn man das berücksichtigt, kann ein Shellskript genauso robust sein
wie ein Skript in einer anderen Sprache. Für komplexere Dinge dann auch
gerne mal in Array-Variablen einlesen: Dateinamenslisten niemals in
einer normalen String-Variable zusammenbauen, immer in einer
Array-Variablen.


Stefan
Jan Novak
2021-01-14 06:13:16 UTC
Permalink
Post by Stefan Reuther
In deinem Skript.
Mit
echo "$1"
wird da nichts mehr kaputtgemacht. Die printf-Variante kommt dann noch
mit ein paar mehr Sonderfällen klar (also '-n', '\c' usw.).
Das ist schon klar, allerdings ändert das nichts daran, dass die
doppleten Anführungszeichen innerhalb der spitzen Klammern verloren
gehen - und _das_ ist ja das eigentliche Problem.
Helmut hat das ja in seinm Post ausführlich erklärt - das es nicht geht.
Post by Stefan Reuther
Post by Helmut Waitzmann
printf '\n\t%s\n' "${0##*/}"'
gegen
echo -e "\n\t$(basename $0)"
weder falsch noch problematisch.
Doch. Die zweite Variante wird $0 in Worte splitten und die Ausgabe des
basename-Kommandos zweimal parsen, einmal beim Einlesen der Ausgabe
durch die Shell und ein weiteres Mal durch 'echo -e'. Für ein
Einmal-Skript vielleicht ok, für was dauerhaftes nicht. Ersteres lässt
sich immerhin mit
echo -e "\n\t$(basename "$0")"
vermeiden, zweiteres nicht ohne Verzicht auf das 'echo'-Kommando dieser
Form.
Richtig.
Falls dich das so sehr stört, dann lasse ich die Zeile komplett weg :-)
Ist doch nur der Hinweis, wie das Script aufgerufen werden könnte.
Post by Stefan Reuther
- niemals irgendwelche Ausgaben parsen. Niemals "for i in $(ls *.x)",
immer "for i in *.x"; niemals "x=$(basename $y)", immer
"x=${y##*/}".
Selbst das for wird gequotet? Das war mir auch nicht bewusst.OK.
Danke.


Jan
Stefan Reuther
2021-01-14 16:25:30 UTC
Permalink
Post by Jan Novak
Post by Stefan Reuther
In deinem Skript.
Mit
    echo "$1"
wird da nichts mehr kaputtgemacht. Die printf-Variante kommt dann noch
mit ein paar mehr Sonderfällen klar (also '-n', '\c' usw.).
Das ist schon klar, allerdings ändert das nichts daran, dass die
doppleten Anführungszeichen innerhalb der spitzen Klammern verloren
gehen - und _das_ ist ja das eigentliche Problem.
Die sind halt - aus Sicht der Shell, die das Skript ausführt - niemals
da gewesen.
Post by Jan Novak
Post by Stefan Reuther
- niemals irgendwelche Ausgaben parsen. Niemals "for i in $(ls *.x)",
   immer "for i in *.x"; niemals "x=$(basename $y)", immer
   "x=${y##*/}".
Selbst das for wird gequotet? Das war mir auch nicht bewusst.
Der Punkt ist an der Stelle, dass in $(ls *.x) Ausgaben geparsed werden
(nämlich die Ausgaben von 'ls'); dass das ein for-Kommando ist, ist an
der Stelle nebensächlich. Das ist so ein Antipattern, was man
gelegentlich sieht.

Dieses Ausgaben-Parsen sollte halt soweit es geht vermieden werden.


Stefan
Helmut Waitzmann
2021-01-14 18:47:38 UTC
Permalink
Post by Jan Novak
Post by Stefan Reuther
- niemals irgendwelche Ausgaben parsen. Niemals "for i in $(ls *.x)",
immer "for i in *.x"; niemals "x=$(basename $y)", immer
"x=${y##*/}".
Selbst das for wird gequotet? Das war mir auch nicht bewusst.OK.
Danke.
Das ist ein Missverständnis:  Die Anführungszeichen in Stefans Text
gehören nicht zu den Shell‐Kommandos.  Sie sollen die Shell‐Kommandos
nur innerhalb des Fließtextes auszeichnen, damit man sieht, welche
Teile des Texts jetzt Shell‐Kommandos sind, und welche nicht. 

Ja, das ist ein Problem.  Ich habe für mich entschieden,
Shell‐Kommandos entweder als eigenen eingerückten Textabschnitt
hinzuschreiben, und/oder sie in typographische Anführungszeichen („“
oder «»), die man innerhalb von Shell‐Kommandos eher nicht findet, zu
setzen. 
Stefan Reuther
2021-01-15 16:31:17 UTC
Permalink
Post by Helmut Waitzmann
Post by Stefan Reuther
- niemals irgendwelche Ausgaben parsen. Niemals "for i in $(ls *.x)",
   immer "for i in *.x"; niemals "x=$(basename $y)", immer
   "x=${y##*/}".
Selbst das for wird gequotet? Das war mir auch nicht bewusst.OK. Danke.
Das ist ein Missverständnis:  Die Anführungszeichen in Stefans Text
gehören nicht zu den Shell‐Kommandos.  Sie sollen die Shell‐Kommandos
nur innerhalb des Fließtextes auszeichnen, damit man sieht, welche Teile
des Texts jetzt Shell‐Kommandos sind, und welche nicht. 
Ja, das ist ein Problem.  Ich habe für mich entschieden, Shell‐Kommandos
entweder als eigenen eingerückten Textabschnitt hinzuschreiben, und/oder
sie in typographische Anführungszeichen („“ oder «»), die man innerhalb
von Shell‐Kommandos eher nicht findet, zu setzen. 
Normalerweise nehm ich inzwischen meistens wie in Markdown `Backticks`,
aber die gibt's ja als archaische Shell-Syntax auch noch...


Stefan
Helmut Waitzmann
2021-01-13 23:46:24 UTC
Permalink
Post by Jan Novak
Ein
printf '%s\n' {"test":"bla"}
gibt
{test:bla}
aus. Das ist kein json String mehr. Die doppelten Anführungszeichen fehlen.
Das hat damit zu tun, dass der Shell gewisse Zeichen in der
Kommandozeile nicht einfach als Parameter stehen lässt, sondern ihnen
eine besondere Bedeutung zugewiesen hat und sie besonders behandelt. 

Wenn man die Sonderbehandlung nicht haben möchte, sondern die Zeichen
einfach für sich stehen sollen, muss man sie durch Quoting (s. u.)
davor schützen (siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02>). 

Zu diesen Sonderzeichen gehören die Zeichen


| & ; < > ( ) $ ` \ " ' <space> <tab> <newline>


und in manchen Zusammenhängen auch noch die Zeichen


* ? [ # ˜ = %


Moderne Shells haben möglicherweise noch weitere Zeichen; beim Bash
beispielsweise gehören die Schweifklammern in bestimmten Fällen auch
noch dazu.

Für das Quoting stellt der Shell verschiedene Mechanismen, die alle
ihre Vor‐ und Nachteile haben, bereit: 

Der erste funktioniert mit dem „\“ (backslash, umgekehrter
Schrägstrich, siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01>): 

Ein Backslash, der seinerseits nicht durch einen Quoting‐Mechanismus
vor Sonderbehandlung geschützt ist, hat folgende Wirkung:  Er
schützt das nachfolgende Zeichen, sofern es kein Newline‐Zeichen
ist, vor dessen Sonderbedeutung.  Auch Zeichen, die keine Sonderbedeutung
haben, dürfen mit einem Backslash geschützt werden.  Das ist dann
zwar unnötig, schadet aber nicht. 

Beispiel:

Um den Text „{"test":"bla"}“ in einer Zeile auszugeben, kann man


printf '%s\n' \{\"\t\e\s\t\"\:\"\b\l\a\"\}

schreiben.  Dabei ist das Quoting zumindest bei den Buchstaben
unnötig, schadet aber nicht. 


Selbst ein „\“ kann mit einem „\“ geschützt werden: 


printf '%s\n' \\

gibt einen Apostroph in einer Zeile aus. 


Und dann hat dieser Mechanismus noch eine Besonderheit:  Wenn man ein
„\“‐Zeichen unmittelbar vor ein Newline‐Zeichen – anders ausgedrückt:
ans Zeilenende – stellt, wird das Newline‐Zeichen nicht geschützt
sondern zusammen mit dem „\“ vom Shell ignoriert, genau so, als
ständen beide nicht da.  Damit lassen sich lange Kommandozeilen
umbrechen. 

Ich halte diesen Mechanismus für massenhafte Anwendung von Hand für
nicht so praktikabel, weil es nicht sicher ist, welche Zeichen das
Quoting nötig haben.  Beispielsweise hat der Bash neben denen, die
ein POSIX‐Shell hat, noch weitere. 

\D\i\e\ \A\l\t\e\r\n\a\t\i\v\e\,\ \e\i\n\f\a\c\h\ \a\l\l\e\ \
\Z\e\i\c\h\e\n\ \d\a\m\i\t\ \z\u\ \s\c\h\ü\t\z\e\n\, \
\f\u\n\k\t\i\o\n\i\e\r\t\ \z\w\a\r\,\ \i\s\t\ \a\b\e\r\ \i\n\ \
\m\a\s\s\e\n\h\a\f\t\e\r\ \A\n\w\e\n\d\u\n\g\ \n\i\c\h\t\ \
\s\e\h\r\ \g\u\t \z\u\ \l\e\s\e\n\.

Deshalb, und weil man mit dem Backslash ein Newline‐Zeichen nicht
schützen kann, gibt es als zweiten Quoting‐Mechanismus den
Mechanismus mit dem Apostroph (siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02>). 
Der funktioniert so: 

Alle Folgen von Zeichen, die man zwischen zwei Apostrophe
einschließt, verlieren ihre Sonderbedeutung und stehen für sich.  Das
bedeutet natürlich, dass man einen Apostroph nicht zwischen zwei
Apostrophe einschließen kann (denn der eingeschlossene Apostroph
würde statt dessen die Einschließung beenden).

printf '%s\n' '{"test":"bla"}'

gibt den Text „{"test":"bla"}“ in einer Zeile aus. 


Und dann gibt es noch einen dritten Quoting‐Mechanismus, den
Mechanismus mit dem Anführungszeichen (siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03>). 
Der funktioniert so ähnlich wie der mit dem Apostroph, hat aber ein
paar Besonderheiten: 

Die wichtigste ist, dass darin vorkommende Parameter‐ oder
Variablenexpansionen („$1“ oder „$variable“) oder
Kommandoausgabe‐Substitutionen

„$(ein Kommando)“

und

„`ein Kommando`“

ausgeführt werden, ohne dass das Resultat anschließend noch an
IFS‐Bruchstellen zerbrochen wird.  Auch „\“‐Zeichen haben darin eine
Sonderbedeutung, die der vom ersten Quoting‐Mechanismus ähnelt, aber
nicht gleich ist.  Genaueres steht im angeführten URL. 

Als Merkregel halte ich für mich fest:  Außer für Parameter‐ oder
Variablenexpansionen und Kommandoausgabe‐Substitutionen (und
vielleicht noch, um einem Apostroph seine Sonderbedeutung zu nehmen)
ziehe ich ihm die beiden anderen Quoting‐Mechanismen vor. 

Was macht man nun, wenn man beispielsweise den Text


Konrad sprach zur Frau Mama:
"Ich geh' fort und Du bleibst da."

(siehe
<http://www.dasbergwerk.de/Niederer_Unfug/Struwelpeter.html>)
ausgeben möchte? 

Die letzte Gedichtzeile macht Ärger:  Sie einfach in Apostrophe
einzuschließen, funktioniert wegen dem Wort „geh'“ nicht: 

printf '%s\n' \
'Konrad sprach zur Frau Mama:' \
'"Ich geh' fort und Du bleibst da."'

Sie in Anführungszeichen zu setzen, funktioniert auch nicht, wegen
der Anführungszeichen für die wörtliche Rede: 

printf '%s\n' \
'Konrad sprach zur Frau Mama:' \
""Ich geh' fort und Du bleibst da.""


Woran man vielleicht zunächst nicht denkt, was im Zusammenhang mit
Quoting aber sehr hilfreich ist:

Man kann in einer Kommandozeile jederzeit zwei (egal, auf welche
Weise) gequotete oder ungequotete Textstücke aneinanderkleben
(ohne dass die dann aneinanderstoßenden Quotingmechanismen
einander stören), um ein Textstück, das aus der Zusammenklebung
der beiden Teile besteht, zu erhalten. Man braucht sie dazu nur
ohne Zwischenraum nebeneinanderzusetzen:

Beispiel:

Im Kommando


printf '%s\n' 'Hello, world!'

kann der Parameter „Hello, world!“ beispielsweise auch als
Zusammenklebung des ungequoteten Stücks „Hel“ und des in Apostrophe
eingefassten Stücks „lo, world!“ geschrieben werden:

printf '%s\n' Hel'lo, world!'

=> Die Aneinanderklebemethode erlaubt es, jederzeit den
Quotingmechanismus zu wechseln.

Das kann man nutzen, um in einem Text, der einen Apostroph
enthält, alle Zeichen außer dem Apostroph zu quoten: Man beginnt
den Text in Apostrophe eingefasst, beendet unmittelbar vor dem im
Text enthaltenen Apostroph die Einfassung in Apostrophe, fasst dann
den gewünschten Apostroph entweder in „""“ ein oder maskiert ihn durch
ein vorangestelltes „\“ und kann danach mit der Einfassung in
Apostrophe fortfahren:

Beispiel:

printf '%s\n' \
'Konrad sprach zur Frau Mama:' \
'"Ich geh'"'"' fort und Du bleibst da."'
| ^^^^^
| |\|/4.: mit Einfassung in Apostrophe fortfahren
| | 3.: einen Apostroph in Anführungszeichen einfassen
| 2.: die Einfassung in Apostrophe beenden
1.: eine Einfassung in Apostrophe beginnen

oder auch:


printf '%s\n' \
'Konrad sprach zur Frau Mama:' \
'"Ich geh'\'' fort und Du bleibst da."'
| ^^ ^
| || 4.: mit Einfassung in Apostrophe fortfahren
| |3.: den Apostroph mit einem Backslash schützen
| 2.: die Einfassung in Apostrophe beenden
1.: eine Einfassung in Apostrophe beginnen
Jan Novak
2021-01-14 06:20:32 UTC
Permalink
Post by Helmut Waitzmann
Post by Jan Novak
aus. Das ist kein json String mehr. Die doppelten Anführungszeichen fehlen.
Das hat damit zu tun, dass der Shell gewisse Zeichen in der
Kommandozeile nicht einfach als Parameter stehen lässt, sondern ihnen
eine besondere Bedeutung zugewiesen hat und sie besonders behandelt.
Wenn man die Sonderbehandlung nicht haben möchte, sondern die Zeichen
einfach für sich stehen sollen, muss man sie durch Quoting (s. u.) davor
schützen (siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02>).
Das ist mir bekannt. Aber ich will ja einen mehrere KB großen String
nicht noch vorher quoten, bevor ich ihn dann nochmal parse und dann
formatiert ausgebe. Vor allem könnte innerhalb des Strings auch schon
gequotet sein oder Anführungszeichen stehen.
Post by Helmut Waitzmann
Zu diesen Sonderzeichen gehören die Zeichen
| & ; < > ( ) $ ` \ " ' <space> <tab> <newline>
Diese Zeichen existieren eventuell auch innerhalb des json strings.
Post by Helmut Waitzmann
Für das Quoting stellt der Shell verschiedene Mechanismen, die alle ihre
Der erste funktioniert mit dem „\“ (backslash, umgekehrter Schrägstrich,
klar, ist mir bekannt.
Post by Helmut Waitzmann
beide nicht da.  Damit lassen sich lange Kommandozeilen umbrechen.
Ich halte diesen Mechanismus für massenhafte Anwendung von Hand für
nicht so praktikabel, weil es nicht sicher ist, welche Zeichen das
Quoting nötig haben.  Beispielsweise hat der Bash neben denen, die ein
POSIX‐Shell hat, noch weitere.
Davon hört man ja immer wieder, dass viele eine Inkonsitenz bemängeln.

Jan
Ulli Horlacher
2021-01-14 08:08:35 UTC
Permalink
Post by Jan Novak
Das ist mir bekannt. Aber ich will ja einen mehrere KB großen String
nicht noch vorher quoten, bevor ich ihn dann nochmal parse und dann
formatiert ausgebe. Vor allem könnte innerhalb des Strings auch schon
gequotet sein oder Anführungszeichen stehen.
Einer der vielen Gruende, warum man keine sh-Programme schreiben sollte.
sh ist ok fuer kleine Skripte, aber sobald es etwas komplexer wird,
schiesst man sich damit unweigerlich in den Fuss.

Ich fall auch immer wieder drauf rein: zuerst starte ich aus Faulheit
meine Skripte in sh, aber nach spaetestens 10 Zeilen wechsle ich dann doch
zu Perl. Python ginge auch, aber das ist mir sperrig. Das kommt (fuer
mich) nur fuer richtig grosse Programme in Frage, wo man sehr sauber
programmieren muss.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Marc Haber
2021-01-14 08:38:03 UTC
Permalink
Post by Ulli Horlacher
Ich fall auch immer wieder drauf rein: zuerst starte ich aus Faulheit
meine Skripte in sh, aber nach spaetestens 10 Zeilen wechsle ich dann doch
zu Perl.
Das geht mir ähnlich, wobei ich dann dir erste Zeit immer rumfluche,
wieviele Dinge man in perl explizit ausprogrammieren muss (in
Directories hineiniterieren, öffnen von Dateien etc).

Shell ist für mein Tagesgeschäft in vielen Punkten _viel_ einfacher
und schneller geschrieben.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ulli Horlacher
2021-01-14 08:53:40 UTC
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Ich fall auch immer wieder drauf rein: zuerst starte ich aus Faulheit
meine Skripte in sh, aber nach spaetestens 10 Zeilen wechsle ich dann doch
zu Perl.
Das geht mir ähnlich, wobei ich dann dir erste Zeit immer rumfluche,
wieviele Dinge man in perl explizit ausprogrammieren muss (in
Directories hineiniterieren, öffnen von Dateien etc).
Man kann auch Perl mit sh verbinden:

$output = `sh-commands ...`;

Das ist zwar kein sauberer Programmierstil, aber manchmal will man einfach
schnell was hinferkeln :-)


Zum einlesen von Dateien verwende ich:

$data = slurp($file);

Mit der Hilfsfunktion:

sub slurp {
my $file = shift;
local $_;
local $/;

if (open $file,$file) {
$_ = <$file>;
close $file;
}

return $_;
}
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Marc Haber
2021-01-14 10:48:58 UTC
Permalink
Post by Ulli Horlacher
Post by Marc Haber
Post by Ulli Horlacher
Ich fall auch immer wieder drauf rein: zuerst starte ich aus Faulheit
meine Skripte in sh, aber nach spaetestens 10 Zeilen wechsle ich dann doch
zu Perl.
Das geht mir ähnlich, wobei ich dann dir erste Zeit immer rumfluche,
wieviele Dinge man in perl explizit ausprogrammieren muss (in
Directories hineiniterieren, öffnen von Dateien etc).
$output = `sh-commands ...`;
Das ist zwar kein sauberer Programmierstil, aber manchmal will man einfach
schnell was hinferkeln :-)
Eklig. Dann lieber ein Shellscript.
Post by Ulli Horlacher
$data = slurp($file);
sub slurp {
my $file = shift;
local $_;
local $/;
if (open $file,$file) {
$_ = <$file>;
close $file;
}
return $_;
}
Fehlerbehandlung? Funktioniert das auch in Pipes?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ulli Horlacher
2021-01-14 11:41:34 UTC
Permalink
Post by Marc Haber
Post by Ulli Horlacher
$output = `sh-commands ...`;
Das ist zwar kein sauberer Programmierstil, aber manchmal will man einfach
schnell was hinferkeln :-)
Eklig. Dann lieber ein Shellscript.
Ich hab das auch nicht empfohlen. Nur gesagt, dass so was geht.
Und wenn ich faul bin, verwende ich es auch :-)
Post by Marc Haber
Post by Ulli Horlacher
$data = slurp($file);
sub slurp {
my $file = shift;
local $_;
local $/;
if (open $file,$file) {
$_ = <$file>;
close $file;
}
return $_;
}
Fehlerbehandlung?
Kommt danach.
Hab ich der Einfachheit hier weggelassen.
Post by Marc Haber
Funktioniert das auch in Pipes?
Perl kennt wie Python keine Pipes.
Fehlerbehandlung gibts in Pipes auch nicht.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Marcus Jodorf
2021-01-14 16:57:32 UTC
Permalink
Post by Marc Haber
Fehlerbehandlung? Funktioniert das auch in Pipes?
Mal ein einfaches Beispiel in python:

import sys
f = open(sys.argv[1]) if len(sys.argv) > 1 else sys.stdin
for line in f:
# do your stuff
f.close()

Damit funktioniert
„prog.py datei.txt“, „cat datei.txt | prog.py“,
„prog.py < datei.txt“ und entsprechend auch consolen input bis EOF (Ctrl-D) einfach als
„prog.py“ aufgerufen.

Soll es nicht zeilenweise sein, dann nach dem open z.B einfach:
data = f.read()
statt „for line...“


Gibt zahllose Varianten, wie man sowas machen kann.
Fehlerbehandlung depends... hier könnte man z.B. ein try/except
drumlegen, um z.B. UnicodeDecodeError abzufangen.

Wenn man stattdessen raw bytes einliest, würde man vermutlich
wenigstens IOError abfangen wollen oder man macht es generisch und fängt
jede mögliche Exception ab und steigt geordnet aus.


Gruß,

Marcus
⚂⚃
Stefan Reuther
2021-01-14 16:32:39 UTC
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Ich fall auch immer wieder drauf rein: zuerst starte ich aus Faulheit
meine Skripte in sh, aber nach spaetestens 10 Zeilen wechsle ich dann doch
zu Perl.
Das geht mir ähnlich, wobei ich dann dir erste Zeit immer rumfluche,
wieviele Dinge man in perl explizit ausprogrammieren muss (in
Directories hineiniterieren, öffnen von Dateien etc).
Shell ist für mein Tagesgeschäft in vielen Punkten _viel_ einfacher
und schneller geschrieben.
Andererseits sind die Dinge, die man ausprogrammieren muss, genau die,
in denen man in Shell pfuscht.

Mal eben über eine Dateiliste iterieren: for i in *.x --> foreach(<*.x>)

Rekursiv über eine Dateiliste iterieren kann man mit Glück auf 'find
-exec' abbilden. Will man Status mitführen, muss man mit 'find | while
read' pfuschen, oder in Shell genauso mit einer rekursiven Funktion
explizit ausprogrammieren wie in Perl.

iter() {
for i in "$1"/*; do
if test -d "$i"; then iter "$i"; else .... fi
done
}

sub iter {
my $d = shift;
opendir my $dir, $d;
foreach (readdir $dir) {
if (-d "$d/$_") { iter("$d/$_") } else { ... }
}
}

Für ein Einmalskript ist natürlich Pfuschen erlaubt.


Stefan
Jan Novak
2021-01-14 10:41:56 UTC
Permalink
Post by Ulli Horlacher
Post by Jan Novak
Das ist mir bekannt. Aber ich will ja einen mehrere KB großen String
nicht noch vorher quoten, bevor ich ihn dann nochmal parse und dann
formatiert ausgebe. Vor allem könnte innerhalb des Strings auch schon
gequotet sein oder Anführungszeichen stehen.
Einer der vielen Gruende, warum man keine sh-Programme schreiben sollte.
sh ist ok fuer kleine Skripte, aber sobald es etwas komplexer wird,
schiesst man sich damit unweigerlich in den Fuss.
kann ich absolut nachvollziehen.
Post by Ulli Horlacher
Ich fall auch immer wieder drauf rein: zuerst starte ich aus Faulheit
meine Skripte in sh, aber nach spaetestens 10 Zeilen wechsle ich dann doch
zu Perl. Python ginge auch, aber das ist mir sperrig. Das kommt (fuer
mich) nur fuer richtig grosse Programme in Frage, wo man sehr sauber
programmieren muss.
Das Problem ist, dass in einem Standard debian kein python installiert
ist, bei perl bin ich mir nicht sicher.
Das bedeutet, das Script hat dann immer Abhängigkeiten. Das wollten wir
gerne vermeiden. Das Scripüt soll möglichst überall ohne zutun von
Externen funktionieren - daher die bash. Die ist überal da, wo wir arbeiten.


Jan
Marc Haber
2021-01-14 10:51:05 UTC
Permalink
Post by Jan Novak
Das Problem ist, dass in einem Standard debian kein python installiert
ist, bei perl bin ich mir nicht sicher.
Aber natürlich ist ein python in einem Standard-Debian installiert.

Vor fünfzehn Jahren habe ich noch danach geträumt, ein schlankes
"Security-Debian" ohne perl und python haben zu können, die
Distribution geht aber ganz drastisch in eine andere Richtung.
Post by Jan Novak
Das bedeutet, das Script hat dann immer Abhängigkeiten. Das wollten wir
gerne vermeiden. Das Scripüt soll möglichst überall ohne zutun von
Externen funktionieren - daher die bash. Die ist überal da, wo wir arbeiten.
Inzwischen gibt es genug subtile Inkompatibilitäten der bash, dass man
sich auch nicht mehr darauf verlassen kann. Das Shellscript sollte man
als Paket mit passenden Abhängigkeiten verteilen oder dokumentieren,
welche _Pakete_ man installiert haben muss, damit das Script
funktioniert. Am besten prüft man auch noch im Script ab ob alles da
ist was man braucht, und das ist meist nicht all zu viel.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ulli Horlacher
2021-01-14 11:48:19 UTC
Permalink
Post by Jan Novak
Das Problem ist, dass in einem Standard debian kein python installiert
ist, bei perl bin ich mir nicht sicher.
Ich kenne seit 2000 kein UNIX, wo kein Perl dabei ist, von extremen Exoten
wie Embeded Devices (Router, Fernseher, etc) abgesehen. Sogar VMWare ESX
kommt mit Perl.
Post by Jan Novak
Das bedeutet, das Script hat dann immer Abhängigkeiten. Das wollten wir
gerne vermeiden. Das Scripüt soll möglichst überall ohne zutun von
Externen funktionieren - daher die bash. Die ist überal da, wo wir arbeiten.
Und deine Skripte verwenden NUR bash und keine externe Programme?
Dasglaubichnicht :-)

Ich programmiere seit 25 Jahren fast nur noch in Perl und meine Programme
laufen out-of-the-box ueberall.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Jan Novak
2021-01-14 12:01:04 UTC
Permalink
Post by Ulli Horlacher
Post by Jan Novak
Das Problem ist, dass in einem Standard debian kein python installiert
ist, bei perl bin ich mir nicht sicher.
Ich kenne seit 2000 kein UNIX, wo kein Perl dabei ist, von extremen Exoten
wie Embeded Devices (Router, Fernseher, etc) abgesehen. Sogar VMWare ESX
kommt mit Perl.
Ja, Perl mag dabei sein und python vielleicht auch.
da ich aber mangels Kentniss der beiden Sprachen diese so gut wie nie
verwendet habe (ein bischen beoim Raspi vielleicht), kam ich noch nie in
den Genuss:-)
Post by Ulli Horlacher
Post by Jan Novak
Das bedeutet, das Script hat dann immer Abhängigkeiten. Das wollten wir
gerne vermeiden. Das Scripüt soll möglichst überall ohne zutun von
Externen funktionieren - daher die bash. Die ist überal da, wo wir arbeiten.
Und deine Skripte verwenden NUR bash und keine externe Programme?
Dasglaubichnicht :-)
In der Regel schon.
Naja... type, find, for, while, test[] ... da sist etwa 95%
Post by Ulli Horlacher
Ich programmiere seit 25 Jahren fast nur noch in Perl und meine Programme
laufen out-of-the-box ueberall.
Das glaube ich dir. Aber wie gesagt: ich will nicht auch noch perl oder
python lernen...
Ich arbeite viel mit php, JS und shell scripten... und selbst da
passiert es oft, dass ich in einem shell script am Ende der Zeile ein ;
anfügen will ;-)

Jan
Ulli Horlacher
2021-01-14 12:12:37 UTC
Permalink
Post by Jan Novak
Post by Ulli Horlacher
Post by Jan Novak
Das Problem ist, dass in einem Standard debian kein python installiert
ist, bei perl bin ich mir nicht sicher.
Ich kenne seit 2000 kein UNIX, wo kein Perl dabei ist, von extremen Exoten
wie Embeded Devices (Router, Fernseher, etc) abgesehen. Sogar VMWare ESX
kommt mit Perl.
Ja, Perl mag dabei sein und python vielleicht auch.
da ich aber mangels Kentniss der beiden Sprachen diese so gut wie nie
verwendet habe
Geheimtipp: so was kann man lernen! :-)
Gerade bei Perl ist die Lernkurve sehr flach. Man kann mit minimalen subset
anfangen. Wenn man sh und awk kennt, geht das ratzfatz.
Post by Jan Novak
Post by Ulli Horlacher
Und deine Skripte verwenden NUR bash und keine externe Programme?
Dasglaubichnicht :-)
In der Regel schon.
Naja... type, find, for, while, test[] ... da sist etwa 95%
***@fex:~: type find
find is /usr/bin/find

Schon reingefallen!
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
j***@schily.net
2021-01-14 12:17:47 UTC
Permalink
Post by Ulli Horlacher
Post by Jan Novak
In der Regel schon.
Naja... type, find, for, while, test[] ... da sist etwa 95%
find is /usr/bin/find
Schon reingefallen!
joerg> type find
find ist in Shell eingebaut

so kommt es mit "bosh" ;-)

Das "find" Builtin in bosh ist ein 3 Zeilen Wrapper um die libfind.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-14 20:08:31 UTC
Permalink
Post by j***@schily.net
Post by Ulli Horlacher
Post by Jan Novak
In der Regel schon.
Naja... type, find, for, while, test[] ... da sist etwa 95%
find is /usr/bin/find
Schon reingefallen!
joerg> type find
find ist in Shell eingebaut
so kommt es mit "bosh" ;-)
Ich kann auch eine shell bauen, die alle Spezialfaelle abdeckt.
Das ist aber fuer die Realitaet und fuer DIESEN Anwendungsfall ("soll
ueberall laufen") voellig irrelevant.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
j***@schily.net
2021-01-15 00:25:32 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
joerg> type find
find ist in Shell eingebaut
so kommt es mit "bosh" ;-)
Ich kann auch eine shell bauen, die alle Spezialfaelle abdeckt.
Das ist aber fuer die Realitaet und fuer DIESEN Anwendungsfall ("soll
ueberall laufen") voellig irrelevant.
Naja, der Bourne Shell läuft ja überall...

Ansonsten ist das find aus der libfind schneller als Andere und es unterstützt
-call als quasi Variante zu -exec um damit ohne fork()/exec() direkt wieder
Kommandos im selben Shell auszuführen. Das ist rasend schnell.

Letztlich habe ich das mal gebaut um sicherzustellen, daß die Bibliothek
libfind auch unter Grenzfällen korrekt funktioniert und nachdem ich mit David
Korn darüber diskutiert hatte, dessen ksh93 ja fast Alles außer find eingebaut
hat.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-15 08:08:01 UTC
Permalink
Post by j***@schily.net
Post by Ulli Horlacher
Post by j***@schily.net
joerg> type find
find ist in Shell eingebaut
so kommt es mit "bosh" ;-)
Ich kann auch eine shell bauen, die alle Spezialfaelle abdeckt.
Das ist aber fuer die Realitaet und fuer DIESEN Anwendungsfall ("soll
ueberall laufen") voellig irrelevant.
Naja, der Bourne Shell läuft ja überall...
Und jede Bourne Shell hat find als internes Kommando?
DAS glaub ich nun nicht.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
j***@schily.net
2021-01-15 11:20:28 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
Naja, der Bourne Shell läuft ja überall...
Und jede Bourne Shell hat find als internes Kommando?
DAS glaub ich nun nicht.
Es ist natürlich immer so, daß es problematisch ist ein Programm mit seinen
Vorgängerversionen zu vergleichen.

Das find(1) Builtin kam im Juli 2015.

Es muß also schon eine ausreichend aktuelle Version installiert sein.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-15 18:34:17 UTC
Permalink
Post by j***@schily.net
Post by Ulli Horlacher
Und jede Bourne Shell hat find als internes Kommando?
DAS glaub ich nun nicht.
Es ist natürlich immer so, daß es problematisch ist ein Programm mit seinen
Vorgängerversionen zu vergleichen.
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Ich kenne keins.
Das ist jedenfalls das voellige Gegenteil von "laeuft ueberall".
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Ralph Aichinger
2021-01-15 18:49:48 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Die bash bei Debian stable ist 5.0

https://packages.debian.org/buster/bash

Ich vermute bei Ubuntu ist es ähnlich.

Bei MacOS ist es ein Trauerspiel, aber viele Leute die das CLI nutzen
verwenden sowieso Homebrew oder was in der Art

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
Bastian Blank
2021-01-15 19:40:09 UTC
Permalink
Post by Ralph Aichinger
Post by Ulli Horlacher
Post by j***@schily.net
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Die bash bei Debian stable ist 5.0
bash ist nicht die bourne shell.

Bastian
Ulli Horlacher
2021-01-15 21:52:26 UTC
Permalink
Post by Ralph Aichinger
Post by Ulli Horlacher
Post by j***@schily.net
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Die bash bei Debian stable ist 5.0
***@unifex:~# echo $BASH_VERSION
5.0.17(1)-release
***@unifex:~# type -a find
find is /usr/bin/find


find ist auch da ein externes Kommando!
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Marc Haber
2021-01-16 08:38:43 UTC
Permalink
Post by Ulli Horlacher
Post by Ralph Aichinger
Post by Ulli Horlacher
Post by j***@schily.net
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Die bash bei Debian stable ist 5.0
5.0.17(1)-release
find is /usr/bin/find
find ist auch da ein externes Kommando!
Du weißt aber schon, dass Du mit Jörg Schilling sprichst, oder? Das
ist der Kollege, der den Autor eines GPL-Programms fragt, ob er das
Programm nicht unter eine freie Lizenz stellen möchte.

Und der vermutlich eine sehr genaue Unterscheidung zwischen "bourne
shell" und "bourne again shell" macht?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
j***@schily.net
2021-01-17 16:17:02 UTC
Permalink
Post by Ralph Aichinger
Post by Ulli Horlacher
Post by j***@schily.net
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Die bash bei Debian stable ist 5.0
Da hast Du aber etwas komplett mißverstanden.

bash ist ein Klon, also ein Shell Nachbau und keinesfalls ein Bourne Shell.

Ich rede von der aktuellen Weiterentwicklung des Bourne Shell, in der sich
immer noch Originalcode aus dem jahr 1977 finden läßt.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Christian Weisgerber
2021-01-15 21:17:56 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
Post by Ulli Horlacher
Und jede Bourne Shell hat find als internes Kommando?
DAS glaub ich nun nicht.
Es ist natürlich immer so, daß es problematisch ist ein Programm mit seinen
Vorgängerversionen zu vergleichen.
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Ähnlich wie Helmut Schellong preist Schily hier sein privates
Shell-Programm an. Dass er es als „die Bourne-Shell“ verkaufen will,
ist etwa so ernst zu nehmen wie wenn ich verkünde, mich zum Kaiser
von China zu krönen.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Marc Haber
2021-01-16 08:39:36 UTC
Permalink
Post by Christian Weisgerber
Post by Ulli Horlacher
Post by j***@schily.net
Post by Ulli Horlacher
Und jede Bourne Shell hat find als internes Kommando?
DAS glaub ich nun nicht.
Es ist natürlich immer so, daß es problematisch ist ein Programm mit seinen
Vorgängerversionen zu vergleichen.
Das find(1) Builtin kam im Juli 2015.
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Ähnlich wie Helmut Schellong preist Schily hier sein privates
Shell-Programm an. Dass er es als „die Bourne-Shell“ verkaufen will,
ist etwa so ernst zu nehmen wie wenn ich verkünde, mich zum Kaiser
von China zu krönen.
Im Gegensatz zu Helmut traue ich Schily aber zu, sich sklavischst an
die Standards bzw ein Vorbild zu halten.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
j***@schily.net
2021-01-17 16:27:12 UTC
Permalink
Post by Marc Haber
Im Gegensatz zu Helmut traue ich Schily aber zu, sich sklavischst an
die Standards bzw ein Vorbild zu halten.
bosh wird auch regelmäßig bei der Standardisierung mit berücksichtigt, denn ich
bin auch einer von 8 Leuten, die den POSIX Standard schreiben ;-)
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Marc Haber
2021-01-17 17:38:25 UTC
Permalink
Post by j***@schily.net
Post by Marc Haber
Im Gegensatz zu Helmut traue ich Schily aber zu, sich sklavischst an
die Standards bzw ein Vorbild zu halten.
bosh wird auch regelmäßig bei der Standardisierung mit berücksichtigt, denn ich
bin auch einer von 8 Leuten, die den POSIX Standard schreiben ;-)
Das ist natürlich geschummelt!

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
j***@schily.net
2021-01-17 17:39:48 UTC
Permalink
Post by Marc Haber
Im Gegensatz zu Helmut traue ich Schily aber zu, sich sklavischst an
die Standards bzw ein Vorbild zu halten.
bosh wird auch regelmäßig bei der Standardisierung mit berücksichtigt, denn ich
bin auch einer von 8 Leuten, die den POSIX Standard schreiben ;-)
Das ist natürlich geschummelt!
???
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Helmut Waitzmann
2021-01-17 19:12:14 UTC
Permalink
Post by Marc Haber
Post by j***@schily.net
Post by Marc Haber
Im Gegensatz zu Helmut traue ich Schily aber zu, sich
sklavischst an die Standards bzw ein Vorbild zu halten.
bosh wird auch regelmäßig bei der Standardisierung mit
berücksichtigt, denn ich bin auch einer von 8 Leuten, die den
POSIX Standard schreiben ;-)
Das ist natürlich geschummelt!
???
Marc erklärt, warum Bosh sich sklavisch an den POSIX‐Standard hält: 
Der Bosh‐Autor sorgt dafür, dass der POSIX‐Standard zum Bosh passt. 

Jörg, denk Dir ein Schmunzelchen dazu! 


Aber Spaß beiseite:  Vielleicht könntet ihr den Betreff anpassen? 
Mit Sonderzeichen und Quoting hat es inzwischen wirklich nichts mehr
zu tun.
j***@schily.net
2021-01-17 20:46:41 UTC
Permalink
Marc erklärt, warum Bosh sich sklavisch an den POSIX‐Standard hält: 
Der Bosh‐Autor sorgt dafür, dass der POSIX‐Standard zum Bosh passt. 
Jörg, denk Dir ein Schmunzelchen dazu! 
Bei der POSIX Standardisierung geht es beim Shell hauptsächlich darum
Unterschiede der verschiedenen Shells zu analysieren, zu diskutieren und
abzustimmen, was davon tolerierbare Unterschiede sind, und natürlich darum
wohin man in der Zukunft möchte.

Da dabei natürlich auch ein wichtiger Punkt ist, was schon irgendwo
implementiert ist (denn POSIX will eigenlich keine eigenen Erfindungen
standardisieren) kann es natürlich auch bei einer Diskussion helfen wenn eine
Idee schon mehr als 0x implementiert ist ;-) Ausschlaggebend ist letzlich
natürlich ein Konsenz Aller in der "Austin Core Gruppe".

Durch meine intimen Kenntnisse des Quellcodes und der Tatsache, daß auch der
Korn Shell letzlich auf einer Bourne Shell Version von 1983 aufbaut, kann ich
natürlich bei bestimmten Fragen erklären warum bestimmte Dinge auf die aktuelle
Weise funktionieren und wie das genau funktioniert.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Marc Haber
2021-01-17 19:57:19 UTC
Permalink
Post by Marc Haber
Im Gegensatz zu Helmut traue ich Schily aber zu, sich sklavischst an
die Standards bzw ein Vorbild zu halten.
bosh wird auch regelmäßig bei der Standardisierung mit berücksichtigt, denn ich
bin auch einer von 8 Leuten, die den POSIX Standard schreiben ;-)
Das ist natürlich geschummelt!
???
Selbst an den Standards schreiben ist unfair ;-)
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
j***@schily.net
2021-01-17 16:21:27 UTC
Permalink
Ähnlich wie Helmut Schellong preist Schily hier sein privates
Shell-Programm an. Dass er es als „die Bourne-Shell“ verkaufen will,
Nein, definitiv nicht!

Ich "bewerbe" hier nicht meinen "bsh", der 1984 der weltweit erste Shell
mit vollinterigertem History-editor war, sondern "bosh", der eine
Weiterentwicklung des Bourne Shell (also des Codes von Stephen Bourne) ist.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
j***@schily.net
2021-01-17 16:14:20 UTC
Permalink
Post by Ulli Horlacher
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Ich kenne keins.
Also SchilliX-ON hat diesen Bourne Shell als /sbin/sh installiert und
damit wird der erste Teil des Bootens in den Multi-User Mode (also vor dem
eventuellen Mounten von /usr) komplett damit besritten.

/bin/bosh ist auch dieser Shell
/bin/sh ist allerdings ksh93, weil dies Leute heutzutage erwarten

Bevor /sbin/sh auf SchilliX-ON wieder zum Bourne Shell (wenn auch in seiner nun
aktualisierten Version) wurde, hat jemand von den Gentoo Leuten den aktuellen
Bourne Shell nach /bin/sh auf Gentoo Linux installiert und über ca. 3 Monate
Bugs gemeldet, die Inkompatibilitäten zu dem sonst installierten dash betrafen.
Danach lief Alles wunderbar. Ein typisches Linux mit /bin/sh == bash kann daher
auch mit bosh arbeiten, wenn man ihn mit

smake COPTX=-DDO_POSIX_SH

kompiliert hat, so daß er strikt POSIX konform ist, wenn er als /bin/sh gerufen
wird.

Damit bosh als /sbin/sh auf OpenSolaris funktioniert, mußte ich 3 Shell Skripte
aus der System-Steuerung von kleineren ksh-ismen befreien, die nicht Bestandteil
des POSIX Standards sind.
Post by Ulli Horlacher
Das ist jedenfalls das voellige Gegenteil von "laeuft ueberall".
Ich habe gesagt: "laeuft ueberall", nicht ist "überall installiert".

Was genau hast Du also bei "laeuft ueberall" nicht verstanden?

Aber es gibt da wohl mehr Leute, die diesen Begriff nicht verstanden haben...

So wird z.B. von gmake behauptet "laeuft ueberall", obwohl gmake auf diversen
Plattformen nur mit trivialen Makefiles funktioniert, nicht aber mit dem was
man heute erwartet. Darum habe ich übrigens 1997 beschlossen "smake"
weiterzuentwicklen, weil nur damit eine Kompilation von den cdrtools auf allen
unterstützten Zielplattformen möglich war.

Vielleicht mal etwas zur Geschichte des "Erfolgs" von gmake:

1) Ein make Klon wird 1989 geschrieben und der versucht alle zusätzlichen
Features des beliebten SunPro Make nachzubauen

2) Dieser Klon "gmake" wird massiv beworben....

3) Nach ca. 10 Jahren Werbung beginnt man mit schleichender Modifikation
zwecks Erzeugung von Inkompatibilitäten.

4) OSS Projekte passen sich an die Inkompatibilitäten an und funktionieren
danach nicht mehr mit dem Vorbild SunPro Make...

So bekommt man, wenn man genug Zeit hat, eine Dominanz auf dem Markt ohne
besser zu sein.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-17 21:34:13 UTC
Permalink
Post by j***@schily.net
Post by Ulli Horlacher
Und welches UNIX kommt mit so einer aktuellen bourne shell?
Also SchilliX-ON hat diesen Bourne Shell als /sbin/sh installiert
Und wer ausser dir verwendet diese mehr sls obskure UNIX?
Das ist doch voellig laecherlich-irrelevant!
Post by j***@schily.net
Post by Ulli Horlacher
Das ist jedenfalls das voellige Gegenteil von "laeuft ueberall".
Ich habe gesagt: "laeuft ueberall", nicht ist "überall installiert".
Was genau hast Du also bei "laeuft ueberall" nicht verstanden?
Aber es gibt da wohl mehr Leute, die diesen Begriff nicht verstanden haben...
Du hast nicht verstanden, warum es in diesem (Teil-)Thread ueberhaupt geht
und auf was auch du dich bezogen hast.
Ich wiederhol es nochmal fuer dich:


From: Jan Novak <***@gmail.com>
Newsgroups: de.comp.os.unix.shell
Subject: Re: Sonderzeichen in der Shell-Kommandozeile? -- Quoting hilft!
Date: Thu, 14 Jan 2021 13:01:04 +0100
Post by j***@schily.net
Post by Ulli Horlacher
Das bedeutet, das Script hat dann immer Abhängigkeiten. Das wollten wir
gerne vermeiden. Das Scripüt soll möglichst überall ohne zutun von
Externen funktionieren - daher die bash. Die ist überal da, wo wir arbeiten.
Und deine Skripte verwenden NUR bash und keine externe Programme?
Dasglaubichnicht :-)
In der Regel schon.
Naja... type, find, for, while, test[] ... da sist etwa 95%
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Christian Weisgerber
2021-01-14 14:44:41 UTC
Permalink
Post by Ulli Horlacher
Post by Jan Novak
Das Problem ist, dass in einem Standard debian kein python installiert
ist, bei perl bin ich mir nicht sicher.
Ich kenne seit 2000 kein UNIX, wo kein Perl dabei ist, von extremen Exoten
wie Embeded Devices (Router, Fernseher, etc) abgesehen.
FreeBSD ist schon mal eines.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Michael Bäuerle
2021-01-14 16:16:43 UTC
Permalink
Post by Christian Weisgerber
Post by Ulli Horlacher
Ich kenne seit 2000 kein UNIX, wo kein Perl dabei ist, von extremen Exoten
wie Embeded Devices (Router, Fernseher, etc) abgesehen.
FreeBSD ist schon mal eines.
NetBSD ist ein anderes.

Und bei macOS ist es "deprecated":
<https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes>
|
| Scripting Language Runtimes
| Deprecations
|
| Scripting language runtimes such as Python, Ruby, and Perl are
| included in macOS for compatibility with legacy software.
| Future versions of macOS won’t include scripting language runtimes by
| default, and might require you to install additional packages. [...]
j***@schily.net
2021-01-14 11:31:31 UTC
Permalink
Post by Ulli Horlacher
Einer der vielen Gruende, warum man keine sh-Programme schreiben sollte.
sh ist ok fuer kleine Skripte, aber sobald es etwas komplexer wird,
schiesst man sich damit unweigerlich in den Fuss.
Wenn man es richtig macht, geht es auch mit dem Shell.

Viele Leute machen beim Shell allerdings Flüchtigkeitsfehler.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
j***@schily.net
2021-01-14 10:52:21 UTC
Permalink
Post by Helmut Waitzmann
Das hat damit zu tun, dass der Shell gewisse Zeichen in der
Kommandozeile nicht einfach als Parameter stehen lässt, sondern ihnen
eine besondere Bedeutung zugewiesen hat und sie besonders behandelt. 
Wenn man die Sonderbehandlung nicht haben möchte, sondern die Zeichen
einfach für sich stehen sollen, muss man sie durch Quoting (s. u.)
davor schützen (siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02>). 
Zu diesen Sonderzeichen gehören die Zeichen
| & ; < > ( ) $ ` \ " ' <space> <tab> <newline>
und in manchen Zusammenhängen auch noch die Zeichen
* ? [ # ˜ = %
Die Liste aus der von Dir genannten URL ist veraltet/fehlerhaft und inzwischen
korrigiert. Dawir aber kein TC3 mehr herausgeben werden und die nächste
offizielle Version des Standards die neue Hauptversion "issue 8" werden wird,
muß man dazu aktuell in das Bugtracking System sehen um die aktuelle Liste zu
erfahren. So wie es aussieht, benötigen wir für die Fertigstellung dieses
Standards bis in den Herbst und die neue Version wird daher wohl erst in einem
Jahr verabschieded.

Meine aus der aktuellen Liste abeleitete Quotingsammlung sieht so aus:

char xchars[] = " \t\"'<>%|;()&-!#*?\\{}[]^$"; /* Chars that need quoting */

Das sind die Zeichen, die mein History Editor des aktuellen Bourne Shell
automatisch quotet, wenn sie in einem Dateinamen vorkommen, der durch TAB
Expansion ersetzt wurde.

Wichtig ist übrigens auch '^', das immer im Bourne Shell als Pipe Ersatz für
Großbuchstaben Terminals verwendet wurde und das auch im Globbing relevant ist.

Dieses Zeichen (falls ungequotet) ist nach meinen Erfahrungen die häufigste
Ursache für Shell Skripte, die nicht immer funktionieren.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-14 11:54:43 UTC
Permalink
Post by j***@schily.net
char xchars[] = " \t\"'<>%|;()&-!#*?\\{}[]^$"; /* Chars that need quoting */
Welche Shell expandiert % ^ - ?
Post by j***@schily.net
Wichtig ist übrigens auch '^', das immer im Bourne Shell als Pipe Ersatz für
Großbuchstaben Terminals verwendet wurde und das auch im Globbing relevant ist.
Das ist doch nur noch von historischem Interesse?
Ich kenne keine aktuelle shell mehr, die das macht.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
j***@schily.net
2021-01-14 12:14:23 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
char xchars[] = " \t\"'<>%|;()&-!#*?\\{}[]^$"; /* Chars that need quoting */
Welche Shell expandiert % ^ - ?
OK, das % wird für den bsh benötigt. Das ist der erste Shell mit voll
integriertem History Editor. Den History Editor hatte ich 1984 für den bsh
geschrieben und 2006 herausgelöst und als Bibliothek für den Bourne Shell
ertüchtigt. Der Code wird gemeinsam verwendet.

^ und - werden aucj im Globbing verwendet.
Post by Ulli Horlacher
Post by j***@schily.net
Wichtig ist übrigens auch '^', das immer im Bourne Shell als Pipe Ersatz für
Großbuchstaben Terminals verwendet wurde und das auch im Globbing relevant ist.
Das ist doch nur noch von historischem Interesse?
Ich kenne keine aktuelle shell mehr, die das macht.
Der aktuelle Bourne Shell schaltet ^ als | Ersatz nur im "strict POSIX Modus"
ab, also wenn er als /usr/xpg4/bin/sh (oder was sonst konfiguriert) aufgerufen
wurde, oder nach set -o posix.

Der aktuelle Bourne Shell ist andererseits die definitive Empfehlung für
Plattformen, die bislang "dash" verwenden, weil er erheblich näher am POSIX
Standard ist und vor Allem Multi-Byte Zeichen unterstützt. Daneben ist "bosh"
auch noch geringfügig schneller als "dash".
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Helmut Waitzmann
2021-01-14 19:32:30 UTC
Permalink
Post by j***@schily.net
Post by Helmut Waitzmann
Wenn man die Sonderbehandlung nicht haben möchte, sondern die
Zeichen einfach für sich stehen sollen, muss man sie durch Quoting
(s. u.) davor schützen (siehe
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02>). 
Zu diesen Sonderzeichen gehören die Zeichen
| & ; < > ( ) $ ` \ " ' <space> <tab> <newline>
und in manchen Zusammenhängen auch noch die Zeichen
* ? [ # ˜ = %
Die Liste aus der von Dir genannten URL ist veraltet/fehlerhaft und
inzwischen korrigiert.
[…]
Post by j***@schily.net
char xchars[] = " \t\"'<>%|;()&-!#*?\\{}[]^$";
/* Chars that need quoting */
Danke für die Korrektur.  Daran sieht man, dass es keine gute Idee
ist, genau wissen zu wollen, welche Sonderzeichen kein Quoting nötig
haben. 

Umgekehrt kriegt man es robuster hin, wenn man jegliche Sonderzeichen
vorsichtshalber mit Quoting schützt. 

Sofern die Regeln «der Apostroph schützt alles, außer sich selbst»,
«der Backslash schützt den Apostroph» und «die Anführungszeichen
schützen den Apostroph» weiterhin gültig bleiben (wovon ich ausgehe,
weil sonst alle möglichen Shell‐Skripte nicht mehr funktionieren)
braucht einen als Shell‐Skript‐Schreiber die Menge der weiteren
Sonderzeichen, die Quoting nötig haben, nicht mehr im einzelnen
bekannt zu sein. 
Helmut Waitzmann
2021-01-13 23:50:05 UTC
Permalink
Post by Jan Novak
Post by Helmut Waitzmann
Post by Jan Novak
No JSON object could be decoded
Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe
ich erfolglos versucht.
#!/bin/bash
if [ "$1" ]; then
   if [ -e "$1" ]; then
       python -m json.tool "$1"
   else
       echo $1| python -m json.tool
   fi
else
   echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Du möchtest gerne, dass „echo“ Dir gewisse[1] Parameter nicht so
ausgibt, wie Du sie ihm angibst, sondern sie auf spezielle Weise
vor dem Ausgeben bearbeitet?
Wie kommst du darauf, bw. _wo_ habe ich das geschrieben??
Post by Helmut Waitzmann
Du möchtest gerne, dass gewisse[1] Parameter nicht so an „echo“
übergeben werden, wie Du sie angibst, sondern, dass sie erst noch
zersägt werden?
Siehe oben: Nichts zersägen.
Post by Helmut Waitzmann
Ich geb' zu, beide Fragen sind rhetorisch gemeint.
Kommt nicht wirklich gut und lustig ist es auch nicht.
Ja, gewiss.  Die Besonderheiten von „echo“ und von
Variablenexpansionen ohne Anführungszeichen kommen in
„de.comp.os.unix.shell“ aber nicht zum ersten Mal auf den Tisch
sondern sind wiederholt Thema. 

Regelmäßigen Lesern von „de.comp.os.unix.shell“ könnten sie
eigentlich bekannt sein – jedenfalls Lesern, die nicht nur die
Artikel lesen, die Followups auf ihre eigenen Fragen sind. 

[…]
Post by Jan Novak
Post by Helmut Waitzmann
Und wenn Du es vollends verbessern willst, ersetze bitte das
zweite gesamte „echo“‐Kommando durch
printf '\n\t%s\n' "${0##*/}"' [fson file] | [json string]'
1. ist das doch nur der Hinweise, wie das kleine Script aufgerufen
werden soll
Aber richtig funktionieren soll der Hinweis doch trotzdem, nicht
wahr? 
Post by Jan Novak
und 2. ist
printf '\n\t%s\n' "${0##*/}"'
gegen
echo -e "\n\t$(basename $0)"
weder falsch noch problematisch.
Es tut nicht das, was es soll:  Auch hier gibt „echo“ die letzte
Pfadkomponente des Namen des Shell‐Skripts – wenn es sie überhaupt
erst unbeschadet erhält – (je nach Fassung) möglicherweise nicht
einfach unverändert aus. 
Post by Jan Novak
Abgesehen davon, dass es einfacher zu schreiben und verständlicher
zu lesen ist.
Verständlicher zu lesen ist es nur, wenn man die Probleme, die „echo“
und Variablenexpansion ohne Anführungszeichen machen, nicht kennt. 
Wer sie kennt, muss sich hier fragen:  Wollte der Autor das so haben,
und wenn ja, zu welchem Zweck?  Oder könnte das ein Versehen sein,
und wenn ja, hat es Konsequenzen? 
Post by Jan Novak
Aber das geht am Thema vorbei.
Ich vermute, dass die von Dir beobachtete Fehlermeldung ihren
Ursprung in „echo“ und der Variablenexpansion ohne Anführungszeichen
hat.  Mehr dazu in getrennten Beiträgen. 
Jan Novak
2021-01-14 06:41:24 UTC
Permalink
Post by Jan Novak
Post by Helmut Waitzmann
Ich geb' zu, beide Fragen sind rhetorisch gemeint.
Kommt nicht wirklich gut und lustig ist es auch nicht.
Ja, gewiss.  Die Besonderheiten von „echo“ und von Variablenexpansionen
ohne Anführungszeichen kommen in „de.comp.os.unix.shell“ aber nicht zum
ersten Mal auf den Tisch sondern sind wiederholt Thema.
Regelmäßigen Lesern von „de.comp.os.unix.shell“ könnten sie eigentlich
bekannt sein – jedenfalls Lesern, die nicht nur die Artikel lesen, die
Followups auf ihre eigenen Fragen sind.
Ich lese seit Jahren hier und in vielen anderen NG's ... und ich
beantworte auch Fragen, sofern mir das möglich ist.
Aber das ist ein ganz anderes Thema.


Jan
Helmut Waitzmann
2021-01-13 23:50:32 UTC
Permalink
Post by Jan Novak
Post by Helmut Waitzmann
Du möchtest gerne, dass „echo“ Dir gewisse[1] Parameter nicht so
ausgibt, wie Du sie ihm angibst, sondern sie auf spezielle Weise
vor dem Ausgeben bearbeitet?
Wie kommst du darauf, bw. _wo_ habe ich das geschrieben??
Das hast Du nirgends geschrieben – das ist ein mögliches Verhalten
von „echo“: 

„echo“ kommt aus zwei verschiedenen Unix‐Traditionen.  In beiden gab
es ein „echo“‐Kommando, und sie verhielten sich unterschiedlich. 

Deshalb war es im POSIX‐Standard nicht möglich, ein Verhalten für
„echo“ festzulegen, das keine der beiden Traditionen vor den Kopf
stößt. 

Man ist deshalb einen anderen Weg gegangen:  Ein neues Kommando –
„printf“ – ist angetreten, die Aufgaben von beiden „echo“‐Varianten
(abhängig von dem Formatierungsparameter) zu übernehmen. 

In Deinem Fall, wo Du den übergebenen Parameter als Zeile an python
verfüttern willst, wäre

printf '%s\n' "$1" | python -m json.tool

das Richtige.  „echo“ ist dafür nicht geeignet, weil es – je nach
Implementierung – Escape‐Sequenzen, die im JSON‐Text enthalten sein
können, selber verarbeitet und also nicht unverändert an python
weiterreicht. 

Wenn Du Escape‐Sequenzen ähnlich wie bei „echo -e“ interpretiert
haben willst, kommt die Shell‐Funktion

echo_e()
(
IFS=' ' &&
printf '%b\n' "$*"
)

infrage. 
j***@schily.net
2021-01-14 11:26:24 UTC
Permalink
Das hast Du nirgends geschrieben – das ist ein mögliches Verhalten
von „echo“: 
„echo“ kommt aus zwei verschiedenen Unix‐Traditionen.  In beiden gab
es ein „echo“‐Kommando, und sie verhielten sich unterschiedlich. 
Deshalb war es im POSIX‐Standard nicht möglich, ein Verhalten für
„echo“ festzulegen, das keine der beiden Traditionen vor den Kopf
stößt. 
Das Problem war/ist nicht das abweichende Verhalten der unterschiedllichen UNIX
Versionen, das eigentliche Problem war/ist bash, denn erst durch die Einführung
von Optionen (wie -e), die über das -n von BSD hinausgehen sind die
Kompatilitätsprobleme entstanden.

Auf zertifizierten Plattformen wie Solaris und Mac OS wird bash übrigens so
kompiliert, daß bash sich per Default POSIX konform verhält und Backslash
Escape Sequenzen expandiert. Auch sollte man nicht vergessen, daß das fehlende
Expandieren der Backslash Sequenzen nur für kleine embedded Systeme gestattet
ist.

Plattformen, die sich "UNIX" nennen wollen, müßen _alle_ XSI Erweiterungen
implementieren. Daher ist auch z.B. dash kein UNIX Shell, weil dash keine
Unterstützung für Multi-Byte Zeichen bietet.
Man ist deshalb einen anderen Weg gegangen:  Ein neues Kommando –
„printf“ – ist angetreten, die Aufgaben von beiden „echo“‐Varianten
(abhängig von dem Formatierungsparameter) zu übernehmen. 
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.

Leider gibt es aber printf Implementierungen, die nicht kompatibel sind, weil:

- sie NULL Bytes nicht korrekt erzeugen können mit Aufrufen wie:

printf '%b' 'ab\000cd'

- sie nicht alle Escape Sequenzenvon POSIX korrekt unterstützen

- sie zusätzliche Escape Sequenzen in einer Weise implementieren, die
abweichendes Verhalten vom Standard bedingt und daher zu unerwartetem
Verhalten führen kann, wenn man den Standard als garantiert annimmt.

- sie die Utility Syntax Guidelines nicht vollständig unterstützen.

Darüberhinaus, gibt es Leute, die printf falsch verwenden.

printf $foo

ist z.B. etwas das unvorhersehbare Resultate liefert, da der Inhalt von $foo
beliebig sein kann und Grenzeffekte triggern kann.

Also auch bei Verwendung von printf(1) muß man vorsichtig sein...

Wir werden übrigens vermutlich mit der Einführung von gettext(1) in der
künftigen ISSUE 8 Version von POSIX für printf(1) fordern. daß "%n$"
unterstützt wird.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-14 12:00:23 UTC
Permalink
Post by j***@schily.net
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.
Schon die Ausgabe von "$@" klappt mit printf nicht.

Ich hab deshalb fuer meinen UNIX-Kurs showargs geschrieben um den
Studenten shell expanion zu erklaeren

***@fex:/tmp: showargs -e a* z*
-e a* z1 zz
1 [-e]
2 [a*]
3 [z1]
4 [zz]
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Tim Landscheidt
2021-01-14 13:59:37 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.
Ich hab deshalb fuer meinen UNIX-Kurs showargs geschrieben um den
Studenten shell expanion zu erklaeren
-e a* z1 zz
1 [-e]
2 [a*]
3 [z1]
4 [zz]
Gleicher Name, andere Programmiersprache (?) und seit zwei
Jahrzehnten bei mir immer in dem Einsatz, wenn ich über mei-
ne eigenen Füße stolpere:

| #!/usr/bin/perl -w

| use strict;
| use warnings;

| use Data::Dumper;

| print Dumper \@ARGV;

Tim
Christian Garbs
2021-01-15 22:52:31 UTC
Permalink
Mahlzeit!
Post by Tim Landscheidt
| #!/usr/bin/perl -w
[…]
Post by Tim Landscheidt
| use warnings;
Hosenträge UND Gürtel? ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
The more you read the less everyone else knows.
Marc Haber
2021-01-16 08:39:59 UTC
Permalink
Post by Christian Garbs
Post by Tim Landscheidt
| #!/usr/bin/perl -w
[…]
Post by Tim Landscheidt
| use warnings;
Hosenträge UND Gürtel? ;-)
E: "use strict" missing

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bastian Blank
2021-01-16 08:43:19 UTC
Permalink
Post by Marc Haber
E: "use strict" missing
Sie meinten "use v5.28"? Das bringt, neben strict, auch noch andere
Erweiterungen mit, "say" z.b., was das kaputte Verhalten von "print"
fixt.

Grüße,
Bastian
Marc Haber
2021-01-17 10:24:20 UTC
Permalink
Post by Bastian Blank
Post by Marc Haber
E: "use strict" missing
Sie meinten "use v5.28"? Das bringt, neben strict, auch noch andere
Erweiterungen mit, "say" z.b., was das kaputte Verhalten von "print"
fixt.
Oh, ich merke gerade dass ich zu lange kein perl mehr gemacht habe und
wenn, dann auf Basis alter Literatur. Hast Du mal was zum Nachlesen?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bastian Blank
2021-01-17 10:30:22 UTC
Permalink
Post by Marc Haber
Oh, ich merke gerade dass ich zu lange kein perl mehr gemacht habe und
wenn, dann auf Basis alter Literatur. Hast Du mal was zum Nachlesen?
Die Online-Doku, was anderes habe ich aktuell auch nicht zu Hand:
https://perldoc.perl.org/functions/use
https://perldoc.perl.org/feature

Bastian
Tim Landscheidt
2021-01-16 12:04:06 UTC
Permalink
Post by Christian Garbs
Post by Tim Landscheidt
| #!/usr/bin/perl -w
[…]
Post by Tim Landscheidt
| use warnings;
Hosenträge UND Gürtel? ;-)
Die Semantik ist leicht anders, aber grundsätzlich: Ja, im-
mer, sofern irgendwie möglich :-).

Tim
j***@schily.net
2021-01-14 15:00:01 UTC
Permalink
Post by j***@schily.net
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.
Was genau willst Du denn erreichen?

die Ausgabe von "$@" klappt mit printf nicht

ist ja erstmal nicht unbedingt richtig.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ulli Horlacher
2021-01-14 19:57:00 UTC
Permalink
Post by j***@schily.net
Post by j***@schily.net
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.
Was genau willst Du denn erreichen?
Shell-Expansion zeigen.
Post by j***@schily.net
ist ja erstmal nicht unbedingt richtig.
Wie machst du das mit printf?
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
j***@schily.net
2021-01-15 11:23:49 UTC
Permalink
Post by Ulli Horlacher
Post by j***@schily.net
Post by j***@schily.net
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.
Was genau willst Du denn erreichen?
Shell-Expansion zeigen.
Das geht doch mit printf....
Post by Ulli Horlacher
Post by j***@schily.net
ist ja erstmal nicht unbedingt richtig.
Wie machst du das mit printf?
Du schreibst ja leider immer noch nicht was genau Du gerne machen möchtest.

Von Deinem Beispiel gehen mit printf nur die Index-Nummern nicht.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Horst Felder
2021-01-14 13:46:47 UTC
Permalink
Das hast Du nirgends geschrieben – das ist ein mögliches
Verhalten von „echo“: 
„echo“ kommt aus zwei verschiedenen Unix‐Traditionen.  In
beiden gab es ein „echo“‐Kommando, und sie verhielten sich
unterschiedlich. 
Deshalb war es im POSIX‐Standard nicht möglich, ein Verhalten
für „echo“ festzulegen, das keine der beiden Traditionen vor
den Kopf stößt.Â
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)

Verstehe… :D
--
Mit freundlichen Grüßen
Horst Felder - www.flohheim.de
GNU/Linux; damit ich auch morgen noch vernünftig arbeiten kann!
Helmut Waitzmann
2021-02-21 20:03:05 UTC
Permalink
Post by j***@schily.net
Das Problem war/ist nicht das abweichende Verhalten der
unterschiedllichen UNIX Versionen, das eigentliche Problem war/ist
bash, denn erst durch die Einführung von Optionen (wie -e), die
über das -n von BSD hinausgehen sind die Kompatilitätsprobleme
entstanden.
Laut
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_18>
und
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16>
fangen die Probleme bereits vorher an:  BSD‐echo kennt die Option
«-n», aber keine Escape‐Sequenzen.  System‐V‐echo kennt die Option
«-n» nicht, aber Escape‐Sequenzen. 

Deshalb gibt es keine Möglichkeit, einen «echo»‐Aufruf, der eine
Zeichenkette ohne abschließendes Newline‐Zeichen ausgibt, so zu
gestalten, dass er sowohl in der BSD‐ als auch in der
System‐V‐Tradition funktioniert.  Die Option «-e» kommt da noch gar
nicht ins Spiel. 
Post by j***@schily.net
Es wäre schön, wenn printf wirklich die Lösung aller Probleme böte.
Leider gibt es aber printf Implementierungen, die nicht kompatibel
sind,
Welche? 
Post by j***@schily.net
printf '%b' 'ab\000cd'
- sie nicht alle Escape Sequenzenvon POSIX korrekt unterstützen
- sie zusätzliche Escape Sequenzen in einer Weise implementieren, die
abweichendes Verhalten vom Standard bedingt und daher zu unerwartetem
Verhalten führen kann, wenn man den Standard als garantiert annimmt.
- sie die Utility Syntax Guidelines nicht vollständig unterstützen.
Bei der Implementierung auf Debian 10 Linux sieht die Ausgabe des
Kommandos

printf '<%b>' 'ab\0000cd' '\\' '\a' '\b' '\f' '\n' '\r' '\t' \
'\v' '\cs' 'S' |
od -v -w10 -t c

so aus:


Beim built‐in‐«printf» im «dash»:


0000000 < a b \0 c d > < \ >
0000012 < \a > < \b > < \f > <
0000024 \n > < \r > < \t > < \v
0000036 > <
0000040


Beim built‐in‐«printf» im als «sh» aufgerufenen «bash»:


0000000 < a b \0 c d > < \ >
0000012 < \a > < \b > < \f > <
0000024 \n > < \r > < \t > < \v
0000036 > <
0000040


Beim built‐in‐«printf» im als «bash» aufgerufenen «bash»:


0000000 < a b \0 c d > < \ >
0000012 < \a > < \b > < \f > <
0000024 \n > < \r > < \t > < \v
0000036 > <
0000040


Beim standalone‐«printf»:


0000000 < a b \0 c d > < \ >
0000012 < \a > < \b > < \f > <
0000024 \n > < \r > < \t > < \v
0000036 > <
0000040


Das sieht mir korrekt aus. 



Bei Debian 6 war die Ausgabe beim built‐in‐«printf» im «dash» noch
defekt:


0000000 < a b > < \ > < \a >
0000012 < \b > < \f > < \n > <
0000024 \r > < \t > < \v > <
0000035


Beim built‐in‐«printf» im «bash» (mit beiden Aufrufarten) und
standalone war sie wie bei Debian 10. 

Stefan Wiens
2021-01-13 16:49:23 UTC
Permalink
Post by Jan Novak
ich habe unten stehendes Script, welches mir den json Inhalt der
übergebenen Datei oder des übergebenen Jsons Strings formatiert
anzeigen soll.
Bei der Ünergabe einer Datei klappt das, der gleiche Inhalt als
Parameter endet mit einem
No JSON object could be decoded
Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich
erfolglos versucht.
#!/bin/bash
if [ "$1" ]; then
if [ -e "$1" ]; then
python -m json.tool "$1"
else
echo $1| python -m json.tool
fi
else
echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Vielleicht könntest du einen vollständigen, konkreten Aufruf zeigen
und angeben, was herauskommt bzw. was nach deinen Wünschen
herauskommen sollte.

Zur Diagnose könntest du den Python-Aufruf durch hd(1) o.Ä. ersetzen.

ARG_MAX nicht vergessen.
--
Stefan
Helmut Waitzmann
2021-01-13 23:53:09 UTC
Permalink
Post by Jan Novak
ich habe unten stehendes Script, welches mir den json Inhalt der
übergebenen Datei oder des übergebenen Jsons Strings formatiert
anzeigen soll.
Bei der Ünergabe einer Datei klappt das, der gleiche Inhalt als
Parameter endet mit einem
No JSON object could be decoded
Fehler.
Diverse " in der Zeile echo $1| python -m json.tool für $1 habe ich
erfolglos versucht.
#!/bin/bash
if [ "$1" ]; then
if [ -e "$1" ]; then
python -m json.tool "$1"
else
echo $1| python -m json.tool
fi
else
echo -e "\n\t$(basename $0) [fson file] | [json string]\n"
fi
Wenn man im Shell einen Parameter (sei es einer der numerierten
positional parameters wie beispielsweise „$1“ oder „$@“, einer der
speziellen Parameter wie beispielsweise „$-“ oder eine Variable wie
beispielsweise „$variable“) in der Parameterliste eines Kommandos
ohne Anführungszeichen („"“) expandieren lässt, verarbeitet der Shell
den erhaltenen Wert vor seiner endgültigen Verwendung weiter:  Der
Wert wird nach Zeichen, die in der Shell‐Variablen „IFS“ enthalten
sind, durchsucht und an jedem Vorkommen eines solchen Zeichens in
zwei Bruchstücke zersägt, die dann als eigenständige Parameter
erscheinen. 

Die Variable „IFS“ enthält normalerweise ein Leerzeichen, einen
Tabulator und einen Zeilenvorschub. 

Beispiel:

Das Shell‐Kommando


(
set -- '______' '\ /' ' \ /' ' \/' &&
printf '%s\n' "$@"
)

gibt ein Dreieck als ASCII‐Grafik aus (bitte zum Betrachten eine
Schriftart einstellen, bei der alle Buchstaben gleich breit sind): 


______
\ /
\ /
\/

Wenn man statt „"$@"“ „$@“ schreibt, werden alle Werte nach der
Expansion an den in ihnen enthaltenen Folgen von Leerstellen,
Tabulatoren und Zeilenvorschüben in zwei Teile zerbrochen: 

______
\
/
\
/
\/

Genaueres müsste im Shell‐Handbuch und jedenfalls in
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05>
stehen. 

Diese seltsame Eigenschaft der Expansion ohne Anführungszeichen hat
vermutlich historische Gründe.  Sie ist im Allgemeinen nicht
sinnvoll, kann aber in Spezialfällen gewünscht sein. 
Lesen Sie weiter auf narkive:
Loading...