[flnews] Schwierigkeiten mit dem externen Editor

[Michael Uplawski]

Mahlzeit

Ich kann mir nicht vorstellen, dass das so gewollt ist. Zum Beispiel
beim Followup:
Der esterne Editor (/usr/bin/gvim oder /usr/bin/vim -g) wird gestartet,
aber der interne Editor auch. Im internen Editor erscheint der zitierte
Post, der externe Editor bleibt leer, die temporäre Datei /tmp/flews_.*
hat offensichtlich keinen Inhalt.

Jetzt kann ich machen was ich will. Zum Ziel führt allerdings nur, den
fertigen Artikel aus dem internen Editor abzuschicken. Freilich kann ich
ihn nach und aus GVim kopieren und so von der Rechtschreibkorrektur
profitieren...
Dazu erfindet man aber keine temporäre Datei... da stimmt doch etwas
nicht?

Cheerio.
--
Es ist an der Zeit

[Michael Uplawski]

Mahlzeit

Ich kann mir nicht vorstellen, dass das so gewollt ist. Zum Beispiel
beim Followup:

Der externe Editor (/usr/bin/gvim oder /usr/bin/vim -g) wird gestartet,

[Marcel Logen]

Michael Uplawski in de.comm.software.newsreader:

>Ich kann mir nicht vorstellen, dass das so gewollt ist. Zum Beispiel
>beim Followup:
>Der externe Editor (/usr/bin/gvim oder /usr/bin/vim -g) wird gestartet,
>aber der interne Editor auch. Im internen Editor erscheint der zitierte
>Post, der externe Editor bleibt leer, die temporäre Datei /tmp/flews_.*
>hat offensichtlich keinen Inhalt.

Wie lautet denn bei Dir der Eintrag "editor:" im configfile?

Wahrscheinlich fehlt da nur ein Parameter.

Marcel gjq8 (544584)
--
────╮ ╭──────────╮ ╭───╮ ╭────╮ ╭──╮ ╭──╮ ╭─────╮
╭──╯ ╰────╮ ╰──╮ ╭─╯ ╰─╮ ╰─╮ ╰─╮ │ │ │ │ │ ╭─╯ ╭
│ ╭────╮ ╭─╯ ╭─╯ ╰─╮ ╭─╯ ╭─╯ ╰─╯ ╰─╯ ╰─╯ │ ╭───────╯
╰─╯ ╰─╯ ╰──────╯ ╰──────╯ ╰──╯ 7dfad8

[Michael Uplawski]

Marcel Logen hat geschrieben:

> Michael Uplawski in de.comm.software.newsreader:

> > Der externe Editor (/usr/bin/gvim oder /usr/bin/vim -g) wird gestartet,
> > aber der interne Editor auch. Im internen Editor erscheint der zitierte
> > Post, der externe Editor bleibt leer, die temporäre Datei /tmp/flews_.*
> > hat offensichtlich keinen Inhalt.
>
> Wie lautet denn bei Dir der Eintrag "editor:" im configfile?

editor: /usr/bin/gvim

Cheerio

[Michael Bäuerle]

Dennis Preiser wrote:

> Versuch mal
>
> editor: /usr/bin/gvim -f

Das funktionieren so nicht. flnews erwartet hier ein ausführbares
Programm. Die Dokumentation könnte an dieser Stelle besser sein.

Für Editor-Parameter muss man ein Script verwenden.

[Michael Bäuerle]

Dennis Preiser wrote:
> Michael Bäuerle <michael....@gmx.net> wrote:

> > Dennis Preiser wrote:
> > > Versuch mal
> > >
> > > editor: /usr/bin/gvim -f
> >
> > Das funktionieren so nicht. flnews erwartet hier ein ausführbares
> > Programm. Die Dokumentation könnte an dieser Stelle besser sein.
> >
> > Für Editor-Parameter muss man ein Script verwenden.
>

> Aha, das erklärt auch, warum ich da ein Shell-Script mit
>
> | exec ${MACVIM} -g -f -c 'set wrap tw=72 ft=mail' -c ':silent:1,$s/^> >/>>/e' -c ':1 +' -- $*
>
> drin stehen habe ;-)

Ich hatte gerade folgendes Script getestet:
-----------------------------------------------------------------------
#! /bin/sh

/usr/pkg/bin/xnedit -geometry 70x50+0+85 -- $@
-----------------------------------------------------------------------

Das hat auch funktioniert.

[Michael Bäuerle]

Wenn flnews den externen Editor nicht starten konnte, dann sollte
auf dem Terminal folgendes erscheinen:
|
| [...]
| flnews: EXT: Executing external editor failed
| flnews: EXT: External editor reported error

Eigentlich sollte der externe Editor dann aber auch nicht erscheinen.
Ist "/usr/bin/gvim" vielleicht ein Script (das sich beendet, nachdem
es den Editor gestartet hat)?

Übergabe von Parametern (außer der zu editierenden Datei) funktioniert
nicht. Dazu kann man ein Wrapper-Script verwenden, siehe Beispiel in:
<news:AABkX7GB7fYAA...@WStation7.micha.freeshell.org>

Es muss aber trotzdem folgendes gewährleistet sein:
Das in configfile eingetragene Programm darf sich nicht beenden, bevor
der Artikel fertig ist (und muss mit dem Exit-Status Erfolg bzw. Fehler
mitteilen).

[Michael Uplawski]

Michael Bäuerle hat geschrieben:

> Wenn flnews den externen Editor nicht starten konnte, dann sollte
> auf dem Terminal folgendes erscheinen:
> |
> | [...]
> | flnews: EXT: Executing external editor failed
> | flnews: EXT: External editor reported error

Erscheint nicht, der Editor wird ja auch gestartet.

> Eigentlich sollte der externe Editor dann aber auch nicht erscheinen.
> Ist "/usr/bin/gvim" vielleicht ein Script (das sich beendet, nachdem
> es den Editor gestartet hat)?

/usr/bin/gvim ist ein symbolischer Link auf /usr/bin/vim. Ich habe darum
immer auch mit /usr/bin/vim -g getestet.

> Übergabe von Parametern (außer der zu editierenden Datei) funktioniert
> nicht. Dazu kann man ein Wrapper-Script verwenden, siehe Beispiel in:
> <news:AABkX7GB7fYAA...@WStation7.micha.freeshell.org>

Habe ich gesehen.
Ausprobiert habe ich in einzeiligen Skripten:

/usr/bin/gvim
/usr/bin/gvim $@
# sicherstellen, dass als $@ Dateiname(n) interpretiert wird, unnötig,
# da der Name der temporären Datei niemals mit '-' beginnt.
/usr/bin/gvim - $@

Alle vorigen Kommandos auch mit
/usr/bin/lxterminal -e "/usr/bin/vim"
/usr/bin/lxterminal -e "/usr/bin/vim -g"

Das Ergebnis ist im Großen und Ganzen auch identisch mit der im OP
beschriebenen Beobachtung: Beide Editoren werden gleichzeitig gestartet,
beide bleiben offen, nur der interne Editor zeigt Inhalt.

Was sich durch das Skript geändert hat: FLNews meldet, dass der Editor
normal beendet worden ist, obwohl er noch offen ist, und läuft. Das ist
unabhängig davon, ob ich den Editor im Terminal oder als GUI starte.

> Es muss aber trotzdem folgendes gewährleistet sein:
> Das in configfile eingetragene Programm darf sich nicht beenden, bevor
> der Artikel fertig ist (und muss mit dem Exit-Status Erfolg bzw. Fehler
> mitteilen).

FLnews meldet, er sei beendet, ich sehe ihn aber immer noch. Vielleicht
ist vim/GVim einfach inkompatibel.

[Michael Uplawski]

Supersedes wegenn ergänzender Bemerkung *)

Michael Bäuerle hat geschrieben:

> Wenn flnews den externen Editor nicht starten konnte, dann sollte
> auf dem Terminal folgendes erscheinen:
> |
> | [...]
> | flnews: EXT: Executing external editor failed
> | flnews: EXT: External editor reported error

Erscheint nicht, der Editor wird ja auch gestartet.

> Eigentlich sollte der externe Editor dann aber auch nicht erscheinen.
> Ist "/usr/bin/gvim" vielleicht ein Script (das sich beendet, nachdem
> es den Editor gestartet hat)?

/usr/bin/gvim ist ein symbolischer Link auf /usr/bin/vim. Ich habe darum
immer auch mit /usr/bin/vim -g getestet.

*) vim -g kann nicht mit '-' kombiniert werden (ist aber eh unnötig).

> Übergabe von Parametern (außer der zu editierenden Datei) funktioniert
> nicht. Dazu kann man ein Wrapper-Script verwenden, siehe Beispiel in:
> <news:AABkX7GB7fYAA...@WStation7.micha.freeshell.org>

Habe ich gesehen.
Ausprobiert habe ich in einzeiligen Skripten:

/usr/bin/gvim
/usr/bin/gvim $@
# sicherstellen, dass als $@ Dateiname(n) interpretiert wird, unnötig,
# da der Name der temporären Datei niemals mit '-' beginnt.
/usr/bin/gvim - $@

Alle vorigen Kommandos auch mit
/usr/bin/lxterminal -e "/usr/bin/vim"
/usr/bin/lxterminal -e "/usr/bin/vim -g"

Das Ergebnis ist im Großen und Ganzen auch identisch mit der im OP
beschriebenen Beobachtung: Beide Editoren werden gleichzeitig gestartet,
beide bleiben offen, nur der interne Editor zeigt Inhalt.

Was sich durch das Skript geändert hat: FLNews meldet, dass der Editor

normal beendet worden sei, obwohl er noch offen ist, und läuft. Das ist

unabhängig davon, ob ich den Editor im Terminal oder als GUI starte.

> Es muss aber trotzdem folgendes gewährleistet sein:
> Das in configfile eingetragene Programm darf sich nicht beenden, bevor
> der Artikel fertig ist (und muss mit dem Exit-Status Erfolg bzw. Fehler
> mitteilen).

FLnews meldet, er sei beendet, ich sehe ihn aber immer noch. Vielleicht
ist vim/GVim einfach inkompatibel.

[Michael Uplawski]

Supersedes wegenn ergänzender Bemerkung *)

Michael Bäuerle hat geschrieben:

> Wenn flnews den externen Editor nicht starten konnte, dann sollte
> auf dem Terminal folgendes erscheinen:
> |
> | [...]
> | flnews: EXT: Executing external editor failed
> | flnews: EXT: External editor reported error

Erscheint nicht, der Editor wird ja auch gestartet.

> Eigentlich sollte der externe Editor dann aber auch nicht erscheinen.
> Ist "/usr/bin/gvim" vielleicht ein Script (das sich beendet, nachdem
> es den Editor gestartet hat)?

/usr/bin/gvim ist ein symbolischer Link auf /usr/bin/vim. Ich habe darum
immer auch mit /usr/bin/vim -g getestet.
*) vim -g kann nicht mit '-' kombiniert werden (ist aber eh unnötig).

> Übergabe von Parametern (außer der zu editierenden Datei) funktioniert
> nicht. Dazu kann man ein Wrapper-Script verwenden, siehe Beispiel in:
> <news:AABkX7GB7fYAA...@WStation7.micha.freeshell.org>

Habe ich gesehen.
Ausprobiert habe ich in einzeiligen Skripten:

/usr/bin/gvim
/usr/bin/gvim $@
# sicherstellen, dass als $@ Dateiname(n) interpretiert wird, unnötig,
# da der Name der temporären Datei niemals mit '-' beginnt.
/usr/bin/gvim - $@

Alle vorigen Kommandos auch mit
/usr/bin/lxterminal -e "/usr/bin/vim"
/usr/bin/lxterminal -e "/usr/bin/vim -g"

Das Ergebnis ist im Großen und Ganzen auch identisch mit der im OP
beschriebenen Beobachtung: Beide Editoren werden gleichzeitig gestartet,
beide bleiben offen, nur der interne Editor zeigt Inhalt.

Was sich durch das Skript geändert hat: FLNews meldet, dass der Editor

normal beendet worden ist, obwohl er noch offen ist, und läuft. Das ist

unabhängig davon, ob ich den Editor im Terminal oder als GUI starte.

> Es muss aber trotzdem folgendes gewährleistet sein:
> Das in configfile eingetragene Programm darf sich nicht beenden, bevor
> der Artikel fertig ist (und muss mit dem Exit-Status Erfolg bzw. Fehler
> mitteilen).

FLnews meldet, er sei beendet, ich sehe ihn aber immer noch. Vielleicht
ist vim/GVim einfach inkompatibel.

[Michael Bäuerle]

Michael Uplawski wrote:
> Michael Bäuerle hat geschrieben:
> >
> > [...]

> > Es muss aber trotzdem folgendes gewährleistet sein:
> > Das in configfile eingetragene Programm darf sich nicht beenden, bevor
> > der Artikel fertig ist (und muss mit dem Exit-Status Erfolg bzw. Fehler
> > mitteilen).
>
> FLnews meldet, er sei beendet, ich sehe ihn aber immer noch. Vielleicht
> ist vim/GVim einfach inkompatibel.

Verhält sich hier genauso. Man braucht "-f", wie Dennis in
<news:0Tj4qojvI1f1oNfm%25de...@coredump.d--p.de> geschrieben hatte.

Dann funktioniert es (ich habe diesen Artikel mit gvim erstellt).

[Michael Uplawski]

Dennis Preiser hat geschrieben:

> Michael Uplawski <michael....@uplawski.eu> wrote:

> > Das Ergebnis ist im Großen und Ganzen auch identisch mit der im OP
> > beschriebenen Beobachtung: Beide Editoren werden gleichzeitig gestartet,
> > beide bleiben offen, nur der interne Editor zeigt Inhalt.
>

> Ein vim mit GUI braucht -f, sonst denkt flnews, er hat sich sofort
> wieder beendet.

Okay. Das ist jetzt

Gvim -f $@

Vielen Dank auch an Michael.

[Michael Uplawski]

Dennis Preiser hat geschrieben:

> Michael Uplawski <michael....@uplawski.eu> wrote:

> > Das Ergebnis ist im Großen und Ganzen auch identisch mit der im OP
> > beschriebenen Beobachtung: Beide Editoren werden gleichzeitig gestartet,
> > beide bleiben offen, nur der interne Editor zeigt Inhalt.
>

> Ein vim mit GUI braucht -f, sonst denkt flnews, er hat sich sofort
> wieder beendet.

Okay. Das ist jetzt

gvim -f $@

Vielen Dank auch an Michael.

[Michael Uplawski]

Mir schwant, dass eine Liste mit funktionierenden Kommandos für jeden Editor
– diejenigen, deren Benutzer sich darum scheren – veröffentlicht werden müsste.

> Ich hatte gerade folgendes Script getestet:
> -----------------------------------------------------------------------
> #! /bin/sh
>
> /usr/pkg/bin/xnedit -geometry 70x50+0+85 -- $@
> -----------------------------------------------------------------------
>
> Das hat auch funktioniert.

Zum Beispiel ist kein Kommando erforderlich, damit (G)Vim $@ als Eingabedatei
erkennt. '--' wäre nur nötig, wenn ein Dateiname mit '-' beginnt. Siehe
<news:AABkX8WhkcIAA...@kurti.uplawski.eu> für GVim mit -f, damit der
Editor keinen eigenen Prozess bekommt.

Okay, für mich läuft es.

Schönen Sonntag.

[Michael Uplawski]

Mir schwant, dass eine Liste mit funktionierenden Kommandos für jeden Editor
– diejenigen, deren Benutzer sich darum scheren – veröffentlicht werden müsste.

Michael Bäuerle hat geschrieben:

> Ich hatte gerade folgendes Script getestet:
> -----------------------------------------------------------------------
> #! /bin/sh
>
> /usr/pkg/bin/xnedit -geometry 70x50+0+85 -- $@
> -----------------------------------------------------------------------
>
> Das hat auch funktioniert.

Zum Beispiel ist kein Kommando erforderlich, damit (G)Vim $@ als Eingabedatei
erkennt. '--' wäre nur nötig, wenn ein Dateiname mit '-' beginnt. Siehe
<news:AABkX8WhkcIAA...@kurti.uplawski.eu> für GVim mit -f, damit der
Editor keinen eigenen Prozess bekommt.

Okay, für mich läuft es.

Schönen Sonntag.

[Diedrich Ehlerding]

Michael Bäuerle meinte:

>
> Ich hatte gerade folgendes Script getestet:
>
-----------------------------------------------------------------------
> #! /bin/sh
>
> /usr/pkg/bin/xnedit -geometry 70x50+0+85 -- $@
>
-----------------------------------------------------------------------
>
> Das hat auch funktioniert.

Bei mir funktioniert

#! /bin/sh

gvim -f $@

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Michael Uplawski]

> Bei mir funktioniert
>
> #! /bin/sh
>
> gvim -f $@

Stimmt. Siehe <AABkX8WhkcIAA...@kurti.uplawski.eu>

Ich kannte -f nicht und als ich die man-page las, wusste ich, dass ich ihn auch
dann nicht hergenommen hätte, wenn ich sie schon früher gelesen hätte.

Ohne Beispiele scheint mir Dokumentation im Allgemeinen nicht einzugehen.

Danke an Alle, das war notwendig

Michael

[Michael Bäuerle]

In diesem Snapshot steht in der manpage, dass man in configfile keine
Parameter für den Editor angeben darf. Außerdem ist ein Beispiel-Script
zum Start eines externen Editors enthalten (Unterverzeichnis "editor"):
<https://micha.freeshell.org/flnews/src/flnews-1.2.0pre24.tar.bz2>
Size(flnews-1.2.0pre24.tar.bz2)= 1216193
SHA2-256(flnews-1.2.0pre24.tar.bz2)= 4d74f5b4474d95455639f2ecb7f97232988c03d54ab9a662eec767894e88bd38

Dort sind außerdem die Bugfixes für die Auswahl einer nicht
existierenden Gruppe und für den Artikelbaum bzw. -liste ohne Fläche
zum zeichnen drin.

Die Farben für externes Zitat und Signatur kann man jetzt ebenfalls im
configfile angeben.

[Michael Uplawski]

Vielen Dank!

Michael Bäuerle hat geschrieben:

> <https://micha.freeshell.org/flnews/src/flnews-1.2.0pre24.tar.bz2>

[Helmut Waitzmann]

Michael Bäuerle <michael....@gmx.net> in der Gruppe
«de.comm.software.newsreader»:

[Es geht um ein Wrapper‐Skript, das vom newsreader «flnews»
gestartet werden soll, um einen externen Editor – hier
«/usr/pkg/bin/xnedit» – zu starten.]

> Ich hatte gerade folgendes Script getestet:
>
> -----------------------------------------------------------------------
> #! /bin/sh
>
> /usr/pkg/bin/xnedit -geometry 70x50+0+85 -- $@
> -----------------------------------------------------------------------
>
> Das hat auch funktioniert.
>

Aber bitte in Shell‐Skripten «$@» immer in Anführungszeichen
setzen – es sei denn, man will, dass die Werte des Parameters «@»
nach dem Auswerten noch überall da zerbrochen werden, wo sie ein
in der Shell‐Variablen «IFS» enthaltenes Zeichen enthalten, und,
dass anschließend auch noch in den Bruchstücken zufällig
enthaltene (aber hier nicht so gemeinte) Dateinamensmuster («?»,
«*», «[…]») durch entsprechende gefundene Dateinamen ersetzt
werden.

Des weiteren empfiehlt es sich, bei Wrapper‐Shell‐Skripten das
gewrappte Programm, das am Ende gestartet werden soll, mittels
«exec» zu starten, damit es in der Prozess‐Baum‐Struktur den
Platz des Wrapper‐Skripts einnimmt und nicht etwa einen weiteren
Prozess erzeugt.

Beispielsweise könnte es ja sein, dass «flnews» in gewissen
Fällen gewisse Signale (beispielsweise ein Hangup‐, Interrupt‐
oder Stop‐Signal) an den von ihm gestarteten Editor schicken
möchte.  Würde das Wrapper‐Skript einen eigenen Prozess
spendieren, würden diese Signale nur das Wrapper‐Skript statt den
von ihm gestarten Editor erreichen.  (Dass Signale an einen
Prozess auch dessen Prozess‐Kinder erreichen, ist ein Märchen,
das sich leider hartnäckig hält.)


Die erste Zeile


#! /bin/sh

in einer lesbaren und ausführbaren Shell‐Skript‐Datei ist für den
Shell «/bin/sh», der die Datei lesen und interpretieren wird, nur
ein Kommentar (denn sie beginnt mit einem «#»).  Ihre
Sonderbedeutung erhält sie erst von den in der
Laufzeitfunktionsbibliothek enthaltenen Funktionen der
«exec»‐Familie:

Wenn so eine Funktion eine Datei, die kein echtes
(Maschinen‐)Programm ist, als Programm zu starten versucht,
scheitert das zunächst, weil ein Shell‐Skript kein
Maschinen‐Programm ist.  Die Funktion unternimmt dann einen
zweiten Versuch:  Sie öffnet das Shell‐Skript zum Lesen und
schaut nach, ob die erste Zeile mit der Zeichenfolge «#!»
beginnt.  Ist das der Fall, liest sie den Rest der Zeile.  Sie
erwartet in dieser Zeile den Namen eines Shells und optional noch
einen Parameter.  Dann startet sie den Shell und übergibt ihm den
optionalen Parameter (falls vorhanden) und den Namen des
Shell‐Skripts als (weiteren) Parameter.

Der gestartete Shell liest das Shell‐Skript und arbeitet den in
ihr stehenden Text als Shell‐Kommandos ab.

Sollte der Dateiname dieses Shell‐Skripts mit einem Minuszeichen
(«-») oder einem Pluszeichen («+») beginnen, würde der Shell den
Namen nicht als Dateinamen sondern als Shell‐Aufruf‐Option
missverstehen.  Um das zu verhindern, empfiehlt es sich, in die
«#!»‐Zeile als optionalen Parameter den Parameter «-» (ein
einzelnes Minuszeichen) zu stellen.  Er sorgt dafür, dass die
Funktion aus der Laufzeitbibliothek dem Shell als ersten
Parameter «-» und erst als zweiten Parameter den Namen des
Shell‐Skripts mitgibt.  Der Parameter «-» teilt dem Shell mit,
dass alle weiteren Parameter keine Shell‐Optionsparameter sind,
auch wenn sie mit einem Minus‐ oder Plus‐Zeichen beginnen
sollten.

In der Summe würde ich das Shell‐Skript so formulieren:


#! /bin/sh -
exec /usr/pkg/bin/xnedit -geometry 70x50+0+85 -- "$@"


Wenn «flnews» es dann beispielsweise mit dem Parameter
«ein Dateiname» startet, bewirkt das, dass «/bin/sh» mit den
Parametern «-», «das_Shell‐Skript» und «ein Dateiname» gestartet
wird.  «/bin/sh» liest dann das Shell‐Skript ein, ignoriert die
Kommentarzeile und interpretiert die zweite Zeile, nachdem er den
Parameter «@» durch den übergebenen Parameter «ein Dateiname»
ersetzt hat, so, als hätte man die Kommandozeile

exec /usr/pkg/bin/xnedit -geometry 70x50+0+85 -- \
'ein Dateiname'

ins Shell‐Skript geschrieben.


Das hat denselben Effekt, als hätte man «flnews» mitteilen
können, das Programm «/usr/pkg/bin/xnedit» mit (neben dem
Dateinamen noch) den zusätzlichen Parametern «-geometry»,
«70x50+0+85», «--» zu starten:  Das Shell‐Skript bewirkt in der
Summe nur eine Hinzunahme der Parameter «-geometry», «70x50+0+85»
und «--».  Es entsteht kein weiterer Prozess, und es wird auch
nichts am übergebenen Dateinamen herumgefummelt – genau das, was
hier gewünscht ist.


Merksätze für Wrapper‐Skripte:


Man verwendet zum Weiterreichen der Parameter, die das
Wrapper‐Skript vom Aufrufer erhalten hat, den Parameter «@»,
nicht etwa «*», und man verwendet ihn in Anführungszeichen, also
«"$@"», damit die vom Aufrufer dem Wrapper‐Skript übergebenen
Parameter unverfälscht an das gewrappte Programm weitergereicht
werden.

Das gewrappte Programm, das vom Wrapper‐Skript schließlich
gestartet werden soll, startet man mit dem Shell‐Kommando «exec»,
damit der Wrapper‐Skript‐Prozess keinen neuen Prozess erzeugt, um
das gewrappte Programm zu starten, sondern jetzt das gewrappte
Programm selber ausführt.  So sorgt man dafür, dass das gewrappte
Programm im Prozess‐Baum genau dort steht, wo der Aufrufer (hier:
«flnews») das Wrapper‐Skript hingestellt hatte.

Mein Vorschlag wäre, Wrapper‐Shell‐Skripte in der Gruppe
«de.comp.os.unix.shell» zu diskutieren.  Deshalb mache ich 'mal
ein Crossposting mit Followup‐To dorthin.  Bei Bedarf bitte
seinerseits anpassen.
--
Hat man erst verstanden, wie Unix funktioniert, ist auch
das Shell-Handbuch kein Buch mit sieben Siegeln mehr.

[Helmut Waitzmann]

Michael Uplawski <michael....@uplawski.eu>:

> /usr/bin/gvim $@
> # sicherstellen, dass als $@ Dateiname(n) interpretiert wird, unnötig,
> # da der Name der temporären Datei niemals mit '-' beginnt.

Woher hast du die Information?  Steht das in der
«flnews»‐Dokumentation, dass «flnews» nie einen Dateinamen
aussucht, der mit einem Minuszeichen beginnt, und das auch in
Zukunft nicht tun wird?

Das Verhalten von Programmen, den Parameter «--» (zwei
Minuszeichen) als Optionen‐Ende‐Anzeiger zu benutzen, ist sehr
weit verbreitet:  Es ist auch das vom POSIX‐Standard wärmstens
empfohlene Verhalten für alle (gegenwärtigen und erst recht
zukünftigen) Programme.  (Es gibt ein paar Altlasten, die man
nicht mehr ändern kann, ohne Rückwärtskompatibilität zu
verlieren.)

Damit lassen sich die auf die Folge der Optionen folgenden
Parameter davor schützen, als Optionen missverstanden zu werden –
ob sie es nun nötig haben oder nicht – und es ist unnötig, mit
dem Feuer zu spielen:

> # sicherstellen, dass als $@ Dateiname(n) interpretiert wird, unnötig,
> # da der Name der temporären Datei niemals mit '-' beginnt.

> /usr/bin/gvim - $@

Bist du sicher, dass «flnews» dem Editor den Namen der zu
bearbeitenden Datei über die Standardeingabe statt als
Aufrufparameter liefert?  Der Parameter «-» teilt «gvim» mit,
dass der Dateiname nicht als Parameter übergeben wird sondern aus
der Standardeingabe gelesen werden kann.

[Michael Uplawski]

Helmut Waitzmann hat geschrieben:

> Michael Uplawski <michael....@uplawski.eu>:
> > /usr/bin/gvim $@
> > # sicherstellen, dass als $@ Dateiname(n) interpretiert wird, unnötig,
> > # da der Name der temporären Datei niemals mit '-' beginnt.
>
> Woher hast du die Information?  Steht das in der «flnews»‐Dokumentation,
> dass «flnews» nie einen Dateinamen aussucht, der mit einem Minuszeichen
> beginnt, und das auch in Zukunft nicht tun wird?

Es passiert mir, dass ich früher geschriebene Shell-Skripte als Schablone
verwende; manchmal so alte, dass ich gar nicht mehr weiß, wieso das
funktioniert hat.., oder woher ich das wusste. Besonders darum nehme ich die
Kritik ernst. Siehe auch die Fortsetzung:

> Das Verhalten von Programmen, den Parameter «--» (zwei Minuszeichen) als
> Optionen‐Ende‐Anzeiger zu benutzen, ist sehr weit verbreitet:  Es ist
> auch das vom POSIX‐Standard wärmstens empfohlene Verhalten für alle
> (gegenwärtigen und erst recht zukünftigen) Programme.  (Es gibt ein paar
> Altlasten, die man nicht mehr ändern kann, ohne Rückwärtskompatibilität
> zu verlieren.)
>
> Damit lassen sich die auf die Folge der Optionen folgenden Parameter
> davor schützen, als Optionen missverstanden zu werden – ob sie es nun
> nötig haben oder nicht – und es ist unnötig, mit dem Feuer zu spielen:

Okay.

[Helmut Waitzmann]

Helmut Waitzmann <nn.th...@xoxy.net>:

> Das Verhalten von Programmen, den Parameter «--» (zwei
> Minuszeichen) als Optionen‐Ende‐Anzeiger zu benutzen, ist sehr
> weit verbreitet:  Es ist auch das vom POSIX‐Standard wärmstens
> empfohlene Verhalten für alle (gegenwärtigen und erst recht
> zukünftigen) Programme.  (Es gibt ein paar Altlasten, die man
> nicht mehr ändern kann, ohne Rückwärtskompatibilität zu
> verlieren.)
>
> Damit lassen sich die auf die Folge der Optionen folgenden
> Parameter davor schützen, als Optionen missverstanden zu werden –
> ob sie es nun nötig haben oder nicht

Im POSIX‐Standard wird das unter dem Begriff «Utility Syntax
Guidelines» beschrieben:
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02>. 
Sie legen einerseits fest, wie Programme ihre Aufrufparameter
verstehen sollen, und geben deshalb andererseits dem Anwender
oder Aufrufer dieser Programme Zusicherungen, wie er die
Aufrufparameter so gestalten kann, dass beispielsweise Dateinamen
nicht als Optionen missinterpretiert werden können.

Beispielsweise nimmt die Beschreibung
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#top>)
des Programms «vi» (auf das «vim» und «gvim» zurückgehen) in
ihrem Abschnitt über die Options darauf Bezug:
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_04>