Vielen Dank, Meillo, für Deine Mühe!
Ich weiß allerdings nicht, ob ich Deine Analyse schon ganz verstehe.
Du meinst, dass das Problem darin liegt, dass das Script nicht mehr auf den Output von slmenu warten kann, weil es slmenu ja in irgendeiner Form in den Hintergrund verschieben musste / lösen musste?
Dann würde das Script sich ja weiter ausführen, bis ... ? Meinst Du das damit, dass das Script dann zeilenweise verarbeiten müsste?
Meillo hat geschrieben: 
10.04.2018 22:14:52
Btw: Was mich noch interessieren wuerde: Was genau macht den dieses Toogle? Warum werden da diese Marker (//+ bzw. //q) ausgegeben? Wenn ich raten muesste, wuerde sich vermuten, dass man damit versteckte Dateien anzeigen lassen bzw. ausblenden kann. Aber das macht keinen rechten Sinn, weil die Dateien ja vom Script kommen und nur nach slmenu gepiped werden. Ich versteh's noch nicht ganz (und hab nach dem langen Post keine rechte Lust mehr, mich durch das Bash-Script zu wuehlen ...)
Richtig geraten!
Ursprünglich war das Script ja für dmenu. Da hatte ich dann einen Befehlsmodus ausgearbeitet. D.h., immer wenn ich etwas eingab, was mit // anfing, lief ich nicht Gefahr, mit einem Suchergebnis zu kollidieren und konnte das nachfolgende als Befehl auswerten lassen. Das ermöglicht mir z.B. "//touch test" o.ä.
Die Befehle "//+" und "//q" schalteten dabei zwischen einfacher und erweiteter Ansicht um. D.h., im Normalmodus wurde mir die Ausgabe von
Code: Alles auswählen
input_short () {
check_root
short_ls () { ls -1 --group-directories-first -F; }
printf "%s\n$pardir%s\n" "$(pwd)" "$(short_ls)" | slmenu_cmd
}
angezeigt und im erweiterten Modus die Ausgabe von
Code: Alles auswählen
input_verbose () {
check_root
long_ls () { LC_ALL="C" ls -lAh --group-directories-first -F; }
printf "%s\n$pardir%s\n" "$(pwd)" "$(long_ls)" | slmenu_cmd -d
}
(check_root und $pardir sorgen nur dafür, dass in "/" kein "../" angezeigt wird, denn bekanntlich hat / ja kein Parentdirectory. Den Luxus habe ich mir nachträglich doch noch eingebaut...)
Jetzt in slmenu habe ich mir aber gedacht: Wenn ich schon den code selber kompiliere, kann ich mir gleich (neben zwei, drei anderen kleinen Änderungen) ein Tastenkürzel für das Umschalten zwischen dem normalen und dem erweitertem Modus anlegen. Dafür hatte ich mir von noice bzw. nnn (s.
https://suckless.org/rocks/ unter "File Browsers" bzw.
nnn) die Taste "." abgeschaut.
Also schreibt slmenu nun beim Drücken der Taste "." "//+" nach stdout. Damit wechselt das Script in den erweiterten Modus. Nun wird slmenu immer mit der Option "-d" gestartet, welche unsere Variable "dotfilestoggle" auf 1 setzt. Dann kann ich nach Wunsch mit der Taste "." wieder in den Normalmodus zurückkehren.
Meillo hat geschrieben: 10.04.2018 22:14:52
Aber wo ist denn das Problem? Ein (so kleines) Programm vielfach zu starten geht blitzschnell. Die Dateilisten wuerden sowieo immer neu eingelesen werden. Der Vorteil waere also nur das Merken des Zustands des Toggles. Wenn das aber dein Wrapperscript macht und dann ggf. `-d' setzt, hast du das schon geloest ... mit weniger Code als wenn du es haettest in C schreiben muessen ... und mit weniger Aufwand als wenn du dieses Script zum zeilenweisen Lesen und die FIFO wieder fuellen haettest schreiben muessen ... und weniger Verwaltung um die FIFO anzulegen und wieder zu loeschen.
Wahrscheinlich hast Du recht... Selbst die Dateiliste von /usr/bin wird mir praktisch ohne Zucken angezeigt (und das bei meinem recht alten Laptop (2009, single core)). Da ist mc langsamer...
Und schön durchbrowsen kann ich auch, denn die Pfeiltasten habe ich so belegt, dass mich das Drücken der linken Pfeiltaste ins Parentdirectory befördert und das Drücken der rechten Pfeiltaste den aktuellen Eintrag wie mit Enter auswählt.
Da kann ich dann genauso durch die Ordner flutschen wie mit noice, nnn oder mc (letzterer muss entsprechend eingestellt werden).
Falls noch die Frage kommt, warum ich als Terminal-file-manager nicht noice oder nnn nehme (oder bei mc bleibe), hier die unsortierten Gründe:
1. Ich kann im Moment hauptsächlich scripte schreiben und bei meinem eigenen file-manager kann ich das Programm nach meinen Wünschen gestalten, denn die "engine" des file-managers ist ja das script und nicht slmenu oder dmenu.
2. Bei noice, nnn oder mc kann man einfach nicht fein genug einstellen, bei welcher Datei welches Programm gestartet wird.
3. Was Eigenes macht Spaß.
4. nnn oder noice haben nicht so eine schöne eingebaute Kommandozeile wie mc oder die Kombination script+[a-z]*menu.
5. noice und mc haben kein "search-as-you-type" oder wie das heißt.
6. Bei mc brauche ich ganz viel gar nicht und vor allem der eingebaute Editor stört mich. Gut, man muss ihn ja nicht nutzen, aber irgendwie ...
mc und
mc-data haben gemeinsam 7MB installierte Größe. Ist eine philosophische Entscheidung...
Ich mag suckless!
hilft dir wahrscheinlich im Endeffekt viel mehr. 
