ubuntuusers.de

Hallo!

Ich habe ganz seeeeltsame Fragen! 😈

Gibt es ein Programm zur graphischen Programmierung von Shellskripten?

Andere Frage: gibt es einen halbautomatischen (geführten) Bashcode-Generator? (jetzt weniger Skripte, sondern einzelne Befehle)

Und noch eine: Gibt es ein Programm, welches ein gegebenes Shellskript lauffähig in eine einzige Befehlszeile schreibt?

Danke!

Guten Morgen!

Kurz gesagt: Mach's dir selbst.

IMHO ergibt Bash-Codegenerierung keinen Sinn, wenn du den Generator nicht selbst geschrieben hast, um deine alltägliche Arbeit zu vereinfachen.

Aber auf jeden Fall solltest du Bashskripting lernen.

Verstehe ich „graphische Programmierung“ als etwas wie eine DSL richtig?

mfg

Malte

Und ich suche nach einer Shell die meine Gedanken interpretieren kann!

Bash-Programming mit einer GUI? 😊

Keine Ahnung, ob diese Links noch existieren oder gänzlich tot sind, aber kannst ja mal schauen, ob das hier hilft:

http://www.linuxforums.org/forum/programming-scripting/44438-gui-scripting-like-autoit-autohotkey.html

Danke. Ich laß mich gerne dafür auslachen. Die Frage ist, ob es sich lohnt, in dieser Richtung was Anfängerfreundliches einzurichten , siehe http://wiki.ubuntuusers.de/Baustelle/Cli_Companion/Fortgeschrittene.

Denn wenn es das schon gibt, wäre die Mühe umsonst.

Den ShellskriptInEineZeileSchreiber könnte ich allerdings schon wirklich gebrauchen - um ihn dem Zusammenhang anzubieten.

Wie würde man so einen ShellskriptInEineZeileSchreiber googeln?

Danke

Ich lache Dich nicht aus 😉

Eigentlich hatte ich eher im Sinn, dass es so etwas doch gar nicht gibt.

So, in der Art: "Ein Yeti 😊 "

Ausserdem finde ich Deinen Ansatz klasse, erstmal zu schauen ob so etwas nicht schon existiert und dann selbst noch so etwas entwicklen zu wollen 👍

danke.

Ich lasse trotzden mal auf "ungelöst", weil ich ja noch keine definitive Antwort habe.

Als Praktiker mit (inzwischen) einer gewissen Erfahrung würde ich mal sagen: richtig schönen Shell-Code wird man kaum auf Knopfdruck erzeugen können. Da gehört einfach zu viel Gehirnschmalz im Vorfeld dazu, damit man einen sinnvollen Programmansatz findet.

Die meiste Arbeit liegt beim Programmieren eben doch erstmal in der "Modellbildung", und das ist Kreativarbeit ...

My 1½ Cents.

track

p.s.:
Was ich sehr wohl nutze ist eine Sammlung von erprobten und bewährten Routinen, damit ich das Rad nicht zu oft erfinde.
Aber dann wird einfach mit gedit oder geany geguttenbergt. (beide haben übrigens auch Bash-Code- Highlighting drin)

track schrieb:

Als Praktiker mit (inzwischen) einer gewissen Erfahrung würde ich mal sagen: richtig schönen Shell-Code wird man kaum auf Knopfdruck erzeugen können.

Ich würde noch weiter gehen uns sagen, dass es schönen Shell-Code gar nicht geben kann 😈

Ansonsten stimme ich Dir natürlich zu. Programmieren via UI-Elementen quasi im Baukastenprinzip ist nicht wirklich produktiv. Ansätze dazu sind mir bisher nur im spielerischen Einsteigerbereich bekannt. Dafür hat noch niemand eine wirklich sinnvolle Lösung gefunden.

Im Grafikbereich ist das bei prozeduralen Texturen durchaus üblich:

• Art of Illusion

• Blender

• Maya

Der Synthesizer pd hat auch sowas. Der Router der Buzz-Abkömmlinge ist im Prinzip dasselbe.

Letztenendes realisieren die alle eine Kette von Filtern: Generator → Filter/Operator → Endergebnis. Weil wir’s bei Shell-Skripten häufig auch mit Filtern in Form von Pipes zu tun haben, ergäbe so ein „Node-Editor“ schon einen gewissen Sinn. Aber nur bei ganz einfachen Problemen. Ganz abgesehen davon, dass du es nicht nur mit der Shell alleine zu tun hast, sondern auch mit awk, sed oder anderen Tools, die alle ihre eigene kleine Sprache mitbringen, die der Editor dann auch visualisieren können müsste.

Vain schrieb:

Der Synthesizer pd hat auch sowas.

Das ist ein Super-Beispiel! Man könnte das auch so sagen, finde ich: Kinder und dann wieder Leute ab ca. 30 wollen zum Lernen von was Neuem, aber Abstraktem, schon ein bißchen verführt werden. Dazwischen liegen die Jahre des Ehrgeizes. Aber irgendwann schämt man sich plötzlich auch nicht mehr vor sich selbst, sich zu den allereinfachsten Dingen Hilfestellung zu holen. Und nichts verführt zum Lernen so sehr wie interessante, scheinbar viel zu einfache Spielerei.

Mein Erstkontakt mit LateX war mit 35 und ohne Kurs oder Lehrbuch oder so was, nur mit den Spielereien von TeXmacs. Anders hätte ich das nicht gelernt. Inzwischen (nicht viel später) nur noch online-lateX und dies in einem Editor ohne jeden Komfort, nicht einmal mit Farben, und teils mit extravaganten Lösungen.

Mit PD dasselbe. PD macht sich anfangs ganz klein und tiefstaplerisch, so daß die Überraschung über seine Möglichkeiten immer steigt und anhält. Und nichts, aber auch gar nichts, bringt mehr Lerneffekt als positive Überraschung (so Spitzer).

Da ich die Möglichkeiten der Shell selbst - als Anfänger - ja nur ahne, fände ich es schade, wenn nicht eine solche Verführung machbar wäre. Copypaste ist schon so eine. (Ich kenne noch CP/M, wo nicht mal eine history war, sondern wo man aus der Konsole nur immer neu eingetippten Code auf eine Diskette speichern konnte.)

Und Leute wie ich machen garantiert keinen Kurs oder lesen ein oreilly-Buch. Die spinnen nämlich und wollen so was gar nicht zuhause haben, sondern lieber Homer oder the Beatles Complete oder die Feynman Lectures. Und wollen trotzdem verführt werden ... auch zum Benutzen der Shell. Daher mein Interesse an CLI Companion ...

Ganz abgesehen davon, dass du es nicht nur mit der Shell alleine zu tun hast, sondern auch mit awk, sed oder anderen Tools, die alle ihre eigene kleine Sprache mitbringen, die der Editor dann auch visualisieren können müsste.

Und genau da ist CLI Companion interessant bzw. könnte interessant werden (ist noch alpha). Denn das ist eigentlich nur eine Bibliothek, wo man die Schnipsel zu den einzelnen Sprachen exemplarisch speichern kann, und ... so mein Projekt ... dann auch zusammensetzen können sollte. Das wäre noch nicht wirklich "graphisch" und auch kein "guter" Code, aber - sch...egal - es wäre eine Verführung zur Spielerei.

Natürlich geht das alles auch im Skript, aber das traut sich der Anfänger vielleicht weniger, weil da das Sicherheit suggerierende Gerüst fehlt, welches die allerallerersten Schritte gaaanz ganz einfach machen muß.

Ich habe ja auch direkt über Programmiersprachen geschrieben. Und da gibt es so etwas afaik nicht - zumindest nichts wirklich herausragendes.

Ich kenne auch viele große Anwendungsprogramme - aus dem PDM Bereich bspw. - bei denen man Workflows grafisch zusammenklickt. Diese erreichen vermutlich teilweise sogar Turingvollständigkeit und man könnte folglich alles mit diesen programmieren.

Warcraft3 bietet auch eine Scriptsprache, die man über einen extrem grafisch orientierten Editor schreibt. Man muss da fast nur noch Werte eintragen; Die Struktur entsteht vollständig durch Geklicke.

Insofern gibt es sicherlich Ansätze, dynamische Abläufe mittels GUI-Bauskästen zusammenklickbar zu machen.

Allerdings kann man bei allem, was in Richtung Turingvollständnigkeit geht und weit über simples Zusammenstellen von Pipes hinausragt, die Frage nach dem wirklichen Nutzen und des Komforts stellen.

Speziell auf die Bash (und Konsorten) bezogen halte ich das für noch schwieriger, da etwas sinnvolles zu erstellen. Das wäre imho ein enormer Aufwand, da man ja in der Shell vor allem auf Fremdprogramme angewiesen ist.

Ein bekannteres Beispiel: http://appinventor.googlelabs.com/about/

Es ist die Unverbindlichkeit der Textstreams, die die CLI aus macht, aber gleichzeitig erschwert sie auch abstraktere Lösungen wie z.B. das grafische Programmieren.

In den meisten Fällen wäre es einfacher die Programme neu zu schreiben bzw. sie um ein gemeinsames Protokoll zu erweitern (ähnlich dem was json/bson für das Netz darstellt), das dann unter anderem auch ein grafisches Programmier-Programm nutzen könnte.

Eine Mammutaufgabe. Aber irgendwann muss man ja mal anfangen, POSIX kann ja nicht bis an Ende aller Tage die Antwort sein.

Vain schrieb:

Letztenendes realisieren die alle eine Kette von Filtern: Generator → Filter/Operator → Endergebnis. Weil wir’s bei Shell-Skripten häufig auch mit Filtern in Form von Pipes zu tun haben, ergäbe so ein „Node-Editor“ schon einen gewissen Sinn. ...

Ok, das zusammenklauben von bewährten Codeschnipseln könnte man auf der Ebene ja tatsächlich automatisieren und "graphisieren" ...
Das könnte ja tatsächlich einen Sinn ergeben.

Relationalist schrieb:

... dann wieder Leute ab ca. 30 wollen zum Lernen von was Neuem, aber Abstraktem, schon ein bißchen verführt werden. Dazwischen liegen die Jahre des Ehrgeizes.

– äh, nee, ... ich bin z.B. schon über 50, aber mich muss man nicht zur Neugier verführen ... nee, wirklich nicht. 😀

Da ich die Möglichkeiten der Shell selbst - als Anfänger - ja nur ahne, fände ich es schade, wenn nicht eine solche Verführung machbar wäre.

ok, in dem Sinne wie oben: +1

Copypaste ist schon so eine. (Ich kenne noch CP/M, wo nicht mal eine history war, sondern wo man aus der Konsole nur immer neu eingetippten Code auf eine Diskette speichern konnte.)

Ja, auch ich bin ein Relikt aus der DOS-Zeit ... und Copy&Paste hat einen bestechenden Vorteil: es geht auch auf der Konsole und mit ssh.
Passt zum "Keep it simple".

Ganz abgesehen davon, dass du es nicht nur mit der Shell alleine zu tun hast, sondern auch mit awk, sed oder anderen Tools, die alle ihre eigene kleine Sprache mitbringen, die der Editor dann auch visualisieren können müsste.

Und genau da ist CLI Companion interessant bzw. könnte interessant werden (ist noch alpha). Denn das ist eigentlich nur eine Bibliothek, wo man die Schnipsel zu den einzelnen Sprachen exemplarisch speichern kann, und ... so mein Projekt ... dann auch zusammensetzen können sollte. Das wäre noch nicht wirklich "graphisch" und auch kein "guter" Code, aber - sch...egal - es wäre eine Verführung zur Spielerei.

Jaja, bewährte Schnipsel zusammenklicken hätte schon einen gewissen Reiz. Vor allem wären diese ausgetesteten Schnipsel dann auch (hoffentlich) wasserdicht. Damit erspart es einem als Supporter schonmal eine ganze Menge an sich ständig wiederholenden Urschleim-Fragen. Die machen nämlich den Löwen-Anteil aus, und bei der 49. Wiederholung ist da echt Geduld gefragt ... 😬

Der entscheidende Widerspruch liegt einfach in der Einfachheit und Portabilität der Shell vs. einem solchen Apparat von Entwicklungsumgebung.
Aber warum nicht mal probieren und gucken ...

track

– äh, nee, ... ich bin z.B. schon über 50, aber mich muss man nicht zur Neugier verführen ... nee, wirklich nicht. 😀

geil! 😛 Bist Du an allen Teilen so jung?

Jaja, bewährte Schnipsel zusammenklicken hätte schon einen gewissen Reiz. V

Von Klicken kann noch lange nicht die Rede sein.

Der entscheidende Widerspruch liegt einfach in der Einfachheit und Portabilität der Shell vs. einem solchen Apparat von Entwicklungsumgebung.

... wie bei mir mit LateX

Aber warum nicht mal probieren und gucken ...

Das Entwicklerteam setzt gerade andere Prioritäten. Die interessieren sich momentan für die manpages und für eine Verlinkung mit commandlinefu und für die Übersetzung von Wörtern wie "run" oder "edit" in alle Sprachen der Welt.