(gelöst) script für convert

[guennid]

Wie kriegt man sowas:

convert /pfad/*.png -resize 2480x3508 -units PixelsPerInch -density 300x300 /pfad/[dateiname].pdf

in ein shell-script? dateiname soll abgefragt werden.

Grüße, Günther

[heisenberg]

Code: Alles auswählen

for src in /pfad/*.png;do
    read -p "Ausgabedateiname für $(basename $src)? " dateiname
    convert $src -resize 2480x3508 -units PixelsPerInch -density 300x300 $(dirname $src)/${dateiname}.pdf[/quote]
done

[Phineas]

Ich würde konsequenter quoten und:

Code: Alles auswählen

if [ -e "$(dirname $src)/${dateiname}.pdf" ]; then
  # wenigstens eine Warnung
fi

[guennid]

Ich kann Pascal, aber mit dieser vermaledeiten Shell-Syntax komme ich nicht klar. Und verstehen möchte ich schon, was ich tue. Bezeichner bitte, wenn möglich, auf deutsch.
Vielleicht erkläre ich erst mal, was ich erreichen möchte: Es sollen alle PNGs in einem Verzeichnis in ein PDF in diesem Verzeichnis gesteckt werden

Meine Fragen:
Bedarf es dazu überhaupt einer Schleife (ich gehe mal davon aus, dass das Konstrukt eine for-Schleife ist). Auf der Konsole/im Terminal ist das ganze ein Einzeiler ohne Schleife
Was ist "src" in Zeile 1?
Warum soll die Abfrage des einen Dateinamens für das PDF in die Schleife?
Was ist "basename" in Zeile 2? (Mir hätte gereicht, dass lediglich der nackte Ziel-Datei-Name, ohne Extension abgefragt und übergeben wird)
In Zeile 3 weiß ich dann mit "dirname" nichts anzufangen. Das pdf soll wie gesagt im selben Verzeichnis wie die einzelnen PNGs landen.

[heisenberg]

Vielleicht erkläre ich erst mal, was ich erreichen möchte: Es sollen alle PNGs in einem Verzeichnis in ein PDF in diesem Verzeichnis gesteckt werden

Erklären was Du erreichen willst, ist der ideale Anfang!

Bedarf es dazu überhaupt einer Schleife (ich gehe mal davon aus, dass das Konstrukt eine for-Schleife ist). Auf der Konsole/im Terminal ist das ganze ein Einzeiler ohne Schleife

Interessant. Wusste nicht dass das geht. Deswegen die Schleife. Dann ohne Schleife:

Code: Alles auswählen

read -p "Ausgabedateiname(ohne Erweiterung)? " dateiname
convert /pfad/*.png -resize 2480x3508 -units PixelsPerInch -density 300x300 /pfad/${dateiname}.pdf

...aber mit dieser vermaledeiten Shell-Syntax komme ich nicht klar. Und verstehen möchte ich schon, was ich tue.

Ist wie mit allem. Erst kommt Lernen, dann Verstehen durch Üben, dann Können. Daher die weit verbreitete Abkürzung: LVÜK

Anfangen kannst Du damit dir mal das Shell-Scripting-Tutorial, das ich in meiner Signatur verlinkt habe anzuschauen.

[guennid]

Danke sehr

Ich wollte den ganzen Klimbim in einen Parameter packen, aber das kriegte ich mit dieser Syntax nicht gebacken. Ich glaube die bei mir fehlenden Schweifklammern bei ${dateiname} waren der entscheidende Fehler.

Grüße, Günther

[heisenberg]

Die geschweiften Klammern sind dafür da, den Variablennamen zu begrenzen. Meist geht das ohne. Wenn aber nach dem Variablennamen ein Zeichen kommt, das auch ein gültiges Zeichen für die Variablenbenennung ist(Der Punkt ist kein gültiges Zeichen), dann führt dass dazu, dass eine andere - wahrscheinlich nicht belegte - Variable verwendet wird.

[tobo]

Ich kann Pascal, aber mit dieser vermaledeiten Shell-Syntax komme ich nicht klar. Und verstehen möchte ich schon, was ich tue.

Du kennst instantfpc?
http://wiki.freepascal.org/InstantFPC/de

[Meillo]

dateiname soll abgefragt werden.

Es entspraeche dem Stil eines Unix-Tools mehr, wenn der Dateiname als Argument uebergeben werden wuerde, statt ihn interaktiv einzulesen ...

[guennid]

Du kennst instantfpc?

Nein, kannte ich nicht danke für den link!
shell-scripting mit klarer pascal-Syntax! Das muss ich ausprobieren.
Im zweiten Beispiel irritiert mich diese Ausgabe(?)-Zeile:

Code: Alles auswählen

/home/testuser/.cache/instantfpc/test1

Die geschweiften Klammern sind dafür da, den Variablennamen zu begrenzen. Meist geht das ohne.

Genau diese Schwammigkeit mag ich nun eigentlich gar nicht leiden.

Es entspraeche dem Stil eines Unix-Tools mehr, wenn der Dateiname als Argument uebergeben werden wuerde, statt ihn interaktiv einzulesen ...

Hmmm, könnte ich probieren. Wenn ich recht verstehe, dann meinst du, dass ich den Dateinamen dem script als Parameter mitgeben soll. Dann müsste er nach meiner Spekulation im script trotzdem einer Variablen übergeben werden oder geht das direkt?. Wie wäre denn dann hier die zielführende Syntax?

[Meillo]

Die geschweiften Klammern sind dafür da, den Variablennamen zu begrenzen. Meist geht das ohne.

Genau diese Schwammigkeit mag ich nun eigentlich gar nicht leiden.

Da gibt's keine Schwammigkeit, das ist alles exakt definiert. Kannst du hier nachlesen: http://pubs.opengroup.org/onlinepubs/96 ... hap02.html

Es entspraeche dem Stil eines Unix-Tools mehr, wenn der Dateiname als Argument uebergeben werden wuerde, statt ihn interaktiv einzulesen ...

Hmmm, könnte ich probieren. Wenn ich recht verstehe, dann meinst du, dass ich den Dateinamen dem script als Parameter mitgeben soll. Dann müsste er nach meiner Spekulation im script trotzdem einer Variablen übergeben werden oder geht das direkt?. Wie wäre denn dann hier die zielführende Syntax?

Ich koennte dir das schon hinschreiben, aber irgendwie denke ich mir, dass du dir nach so langer und aktiver Zeit hier im Forum schon zumindest ein paar Shell-Scripting-Grundlagen aneignen koenntest. Jedenfalls habe ich nicht den Eindruck, dass du nicht dazu faehig waerst. Probier's also erstmal selber; wir helfen dir dann beim Debuggen.

[tobo]

Im zweiten Beispiel irritiert mich diese Ausgabe(?)-Zeile:

Code: Alles auswählen

/home/testuser/.cache/instantfpc/test1

Das ist paramstr(0) - die ausführbare Datei, die aus dem Skript erzeugt wurde. FPC ist ja ein Compiler und auch wenn da ein Skript geschrieben wird, im Hintergrund wird kompiliert, nicht interpretiert.

[guennid]

Probier's also erstmal selber

Abgelehnt. Die Syntax ist mir zutiefst zuwider. Gute deutschspachige Tutorials gibt's nicht. Aber gut, ich werde mal versuchen, den Parameter einer Variablen anzudrehen, obwohl - ich weiß nicht mal, wie man einen solchen Parameter im script anspricht. Wenn das funktioniert, kann es ja mit heisenbergs code weitergehen.
Ein extensiveres Probieren wäre nicht so gut für meinen Blutdruck.

instantfpc ist offenbar auch nichts für mich. Den ganzen Lazaruskram will ich mir nicht installieren, ein deb-Paket scheint's nicht zu geben.

Grüße, Günther

[heisenberg]

Gute deutschspachige Tutorials...

...gibt es jede Menge. Einen Tip hast Du bereits von mir bekommen. Es gibt noch mindestens 5 andere exzellente Seiten.

Du musst Dich auch nicht rechtfertigen. Du kannst es auch einfach bleiben lassen. Aber vielleicht interessiert es Dich ja, wie Du mit einem mächtigen Betriebssystem effektiver umgehen kannst und Deine Fähigkeit ausbaust, mit diesem Werkzeug umzugehen. Und ich vermute ja, dass Du Dir das wünscht, sonst hättest Du ja nicht diese Frage gestellt. Und vielleicht willst Du ja nicht bei jeder Pille-Palle Aufgabenstellung das Forum bemühen müssen bzw. darauf angewiesen sein müssen, um Dir das verhasste Shellscripting vorkauen zu lassen.

Und man muss kein Bash-Scripting können. Aber Bash ist halt fast überall wo linux ist. Es ist also rein persönlich sehr vorteilhaft, das zu können.

Wenn Du erst mal ein bisschen mit der Bash beschäftigt hast, dann geht das immer leichter.

[guennid]

Ok, sowohl

Code: Alles auswählen

#!/bin/sh
convert /pfad/*.png -resize 2480x3508 -units PixelsPerInch -density 300x300 /pfad/$1.pdf

als auch

Code: Alles auswählen

#!/bin/sh
name=$1
convert /pfad/*.png -resize 2480x3508 -units PixelsPerInch -density 300x300 /pfad/$name.pdf

tun das Gewünschte.

[edit:]
@heisenberg
Falls du das hier meinst: https://wiki.ubuntuusers.de/Shell/Bash- ... _Anfänger/ Halte ich nicht für geeignet, ernsthaft shell-scripting lernen zu wollen. OK schnuppern mag gehen, und dann??? Doch wieder erst mal Englisch lernen? So weit gehen auch meine Ansprüche nicht. Wenn's komplizierter wird, schreibe ich mir ein Pascal-Programm.

[tobo]

instantfpc ist offenbar auch nichts für mich. Den ganzen Lazaruskram will ich mir nicht installieren, ein deb-Paket scheint's nicht zu geben.

Deb-Paket gibt's nicht aber 2 *.pas zum kompilieren:
https://sourceforge.net/p/lazarus-ccr/s ... nstantfpc/
Aber ist ja eh alles nicht Thema hier...

[heisenberg]

@Günther:

Naja es ist vielleicht nicht immer der 1. Treffer ganz oben in Google und manchmal braucht es vielleicht sogar mehr als ein oder zwei Suchen. Wer sich Mühe gibt, der findet.

Z. B.:

Rheinwerk: Shellscripting-Online-Buch


...und Englisch? Für mich selbst bin ich nicht motiviert, mich nur mit dem deutschsprachigen Internet zufrieden geben zu wollen. Habe auch - als das notwendig war - mir diverse Videos über toudou.com zusammengesucht; auch wenn ich nicht ein Fitzelchen chinesisch lesen kann. Hat trotzdem geklappt. Wo ein Wille, ... wissen schon.

...und ja, manchmal ist das Erlernen von Neuem ganz schön hart. Ich fand den Einstieg in das Konfigurationsmanagement mit Chef bei gleichzeitigem Einstieg in die Programmiersprache Ruby sehr heftig. Die Dokumentation von Chef sieht in gewisser Weise gut aus. Woran es total mangelt sind irgendwelche brauchbaren Einrichtungsleitfäden für den Chef-Server. Als ich dann das richtige Material hatte - ein O'Reilly Buch, das ich dafür bestellt hatte(Ist leider auch nur in Englisch verfügbar) - ging's vorwärts.

[Meillo]

Die Syntax ist mir zutiefst zuwider.

Dann verwende halt 'ne andere Shell. Das ist doch gerade das Schoene an Unix: Niemand zwingt dich dazu die Bash oder auch nur eine Bourne-kompatible-Shell als Shell zu verwenden. Du kannst auch eine csh verwenden oder fish oder einen Python-Interpreter ... oder deine eigene in Pascal selbst geschriebene Shell -- es ist voellig egal. Einfach in /etc/shells eintragen und mit chsh(1) setzen.

Und mittels Shebang brauchst du auch kein einziges Shellscript mehr fuer die Bash schreiben. Du kannst dort genauso Perl, Ruby, Python, Instantfpc, whatever verwenden.

Wie du siehst, gibt es fuer dich ueberhaupt keinen Grund, dich mit einer Syntax zu befassen, die dir zutiefst zuwider ist. Aber dann verhalte dich auch konsequent, denn was ich nicht leiden kann ist dieses Rumgejammere, dass du einerseits Shellscripten willst, dich andererseits aber nicht damit befassen willst. Wenn dich die Syntax so stoert, dann richte dir dein System so ein, dass du dir diese Syntax ersparst (aka. change it). Wenn dir aber der Aufwand, dein System so einzurichten stoert, dann lerne die Syntax zu akzeptieren (aka. love it). Wenn du nichts von beidem willst, dann verzichte auf's Shellscripten (aka. leave it).

[MaGe]

Ok, sowohl

Code: Alles auswählen

#!/bin/sh
convert /pfad/*.png -resize 2480x3508 -units PixelsPerInch -density 300x300 /pfad/$1.pdf

als auch

Code: Alles auswählen

#!/bin/sh dann ins verzeichnis wechseln
name=$1
convert /pfad/*.png -resize 2480x3508 -units PixelsPerInch -density 300x300 /pfad/$name.pdf

tun das Gewünschte..

ist das ergebnis so gewollt? bei mir

-1
-2
-3

wenn so sein solte?

Code: Alles auswählen

 vorher                nachher

test-1.png           test-1.pdf
test-2.png           test-2.pdf
test.3.png           test.3.pdf

wenn so dann ins verzeichnis wechseln

mit for-Schleife.

Code: Alles auswählen

for i in `ls *.png`; do convert "$i" -resize 2480x3508 -units PixelsPerInch -density 300x300 "${i%.*}.pdf" ; done

und ohne Schleife

Code: Alles auswählen

ls -1 *.png | xargs -n 1 bash -c 'convert "$0" -resize 2480x3508 -units PixelsPerInch -density 300x300 "${0%.*}.pdf"'

gruss MaGe

[uname]

Die Syntax ist mir zutiefst zuwider

Naja sowohl Pascal als auch die Bourne Shell (Basis für Bash (Bourne-again shell)) haben ihre Anfänge in den 1970er-Jahre. Pascal war eher eine Lehrsprache also für Schulen und Universitäten gedacht. Insgesamt also sehr einfach. Die Bourne Shell wurde bei Unix V7 mitgeliefert. Die Anzahl der UNIX-Systeme war bestimmt stark begrenzt und mit früherer Schul-Informatik (Pascal) und heutiger Schul-Informatik (wahrscheinlich MS Office) hatte das rein gar nichts zu tun. Da waren Profis am Werk. Naja heute ist jemand mit seinen Pascal-Kenntnissen im Vergleich zu den heutigen Mausschubsern natürlich schon wieder ein IT-Experte. Um jedoch ernsthaft in Linux einzusteigen sollte man die Möglichkeiten kennen und nicht seine eigenen Wege suchen. Die Shellprogrammierung gehört ähnlich zu Linux wie auch der Vim auch wenn es natürlich viele andere Editoren gibt. Insgesamt halte ich UNIX/Linux bzw. eigentlich seit den 1980er-Jahren eher GNU für eines der am besten durchdachten Konzepte überhaupt, die ihre Anfänge wohl in den 1960er-Jahren mit UNIX hatten. Und die Shellprogrammierung gehört definitiv dazu. Leider entscheidet in der Welt jedoch nicht Qualität über die Verbreitung. Schade eigentlich. Auch sind viele Menschen nicht bereit mal ernsthaft was Neues zu lernen, was eigentlich 40 Jahre alt ist.

[Liffi]

Insgesamt halte ich UNIX/Linux bzw. eigentlich seit den 1980er-Jahren eher GNU für eines der am besten durchdachten Konzepte überhaupt, die ihre Anfänge wohl in den 1960er-Jahren hatten. Und die Shellprogrammierung gehört definitiv dazu. Leider entscheidet in der Welt jedoch nicht Qualität über die Verbreitung. Schade eigentlich. Liegt vielleicht auch daran dass viele Menschen nicht bereit sind mal ernsthaft was Neues zu lernen, was eigentlich 40 Jahre alt ist.

Puh. Ich schreibe relative viele Shell-Skripte und muss sagen: Die Syntax ist einfach nicht schön. Leerzeichen, die an einigen Stellen benötigt, an anderen zu Fehlern führen, weil z.B. '[' ein Programm ist, ist schon verwirrend. Und auch, dass ']' als letztes Argument von '[' benötigt wird, ist schon ungewöhnlich (je nach Implementierung). Ich bin davon überzeugt, dass man heute sehr viel anders machen würde. Fließkommazahlen wären heute womöglich auch dabei . Auch der Support für Dictionaries/Hash Tables wäre sicher anders gelöst. Es gibt noch unzählige weitere Stellen, wo man das Sprachdesign heute sicher anders machen würde. Ich bin froh, dass mir tools wie shellcheck[1] helfen, nur wenige Fehler zu machen .

[1] https://www.shellcheck.net/

[uname]

Die Gründe für die Syntax kenne ich natürlich auch nicht. Ich könnte mir aber vorstellen, dass [ (test) eine schließende Klammer erfordert, um das Ende der Parameter einfacher zu erkennen und somit den Befehl besser zu parsen. Moderne Sprachen mit fast unendlich viel CPU, RAM und Plattenplatz können hier weit großzüger sein. Wobei mir ehrlich kein Zeichen bzw. das Fehlen eines Zeichens als sinnvoll erscheint, um [ korrekt nach Chomsky-Hierarchie (war es nicht kontextfrei und damit CH Typ 2 / Backus-Naur-Form ) zu beenden.

[guennid]

dieses Rumgejammere, dass du einerseits Shellscripten willst, dich andererseits aber nicht damit befassen willst.

Ich will ja gar nicht shell-scipten. Dafür ist mir Syntax viel zu undurchsichtig. Ich will ein konkretes Problem lösen: Bilder in ein seitenorientiertes PDF-File transferieren. Dazu werde ich schwerlich ein geeignetes Debian-Binary finden. Bleiben für mich zwei Möglichkeiten entweder ich baue mir selbst eins mit Pascal oder ich bemühe die shell. Da das, im vorliegenden Fall wie gezeigt, weiter nichts als ein Einzeiler ist, schien mir das das Praktischere. Aber die Syntax ist eben nicht praktisch. Und ich halte es für absoluten overhead, mir jetzt einen Kopp zu machen, warum ich zuletzt $name in meinem Einzeiler verwenden konnte, während tobo wohl der Ansicht war ${name} wäre zumindest das sicherere. Der Dateiname war übrigens "00004". Vielleicht lag's an den Zahlen. Bei Pascal gibt es sowas wie Typendeklaration. Ich habe Liffis Beitrag nichts hinzuzufügen.

Grüße, Günther

[uname]

mir jetzt einen Kopp zu machen

Das liegt an diesem Forum. Anstatt nur eine Lösung für ein Problem zu präsentieren wird gerne etwas weiter ausgeholt. Wie weiter oben steht benötigt man $(name} eigentlich nur dann wenn Zeichen folgen, die den Variablennamen verfälschen. Bei "name123" ist $name123 die Variable name123. Bei ${name}123 ist die Variable $name und 123 folgt dahinter z.B. als Text. In deinem Fall ist "." hinter name keine gültige Variablenbezeichnung und somit kannst du die geschweiften Klammern weglassen. Man kann sich höchtens überlegen ob es besser wäre immer ${} zu fordern. Da war der Programmierer wohl großzügig. Gibt im übrigen auch noch $(), (), (()) und wohl einiges mehr.

[Liffi]

Die Gründe für die Syntax kenne ich natürlich auch nicht. Ich könnte mir aber vorstellen, dass [ (test) eine schließende Klammer erfordert, um das Ende der Parameter einfacher zu erkennen und somit den Befehl besser zu parsen.

Das ist einfacher nur schöner für den Benutzer. Deshalb erfordert '[' das. Der Befehl selbst hört quasi mit dem ';' auf. Deshalb sind an dieser Stelle die Leerzeichen auch so wichtig.