(mir) unverständliche Ausgabe in shell script

[Jan Novak]

Hallo,

ich habe ein (bash) shell scrip unter debian bullsese, welches als
wrapper für find dient, weil es so viele verschiedene Pfade/Typen/Alter
von Dateien/Verzeichnissen zu suchen/löschen gibt.

Das cfg-inlcude sieht u.a so aus (ist noch viel mehr drin, jedoch soll
dieses als Beispiel dienen):

#
# config file for cleanup.cfg
#
# DIR = directory to scan
# PATTERN = file Pattern or *
# DAY = mtime of Files/Directorys old, 0=everything
# WHAT = what to scan: f=files, d=dirs, fd=files & directorys, s=symlinks
# WHEN = d = daily, m=monthly
#

LOG="/cx/logs/admin/cd-cleanup.log"
USER="cx"
GROUP="cxgroup"


DIR=();
PATTERN=();
DAY=();
WHAT=();
WHEN=();
DEPTH=();

DIR=("${DIR[@]}" "/cx/users/*/ams/auf");
PATTERN=("${PATTERN[@]}" "*");
DAY=("${DAY[@]}" "7");
WHAT=("${WHAT[@]}" "s");
WHEN=("${WHEN[@]}" "d");
DEPTH=("${DEPTH[@]}" "0");

DIR=("${DIR[@]}" "/cx/users/*/ams/wof");
PATTERN=("${PATTERN[@]}" "*");
DAY=("${DAY[@]}" "7");
WHAT=("${WHAT[@]}" "s");
WHEN=("${WHEN[@]}" "d");
DEPTH=("${DEPTH[@]}" "0");


DIR=("${DIR[@]}" "/cx/temp");
PATTERN=("${PATTERN[@]}" "*");
DAY=("${DAY[@]}" "7");
WHAT=("${WHAT[@]}" "f");
WHEN=("${WHEN[@]}" "d");
DEPTH=("${DEPTH[@]}" "0");


Das shell script sieht so aus:

...
include obige cfg
...
anzahl=${#DIR[@]}
while (test $i -lt $anzahl ); do
ldir="${DIR[$i]:0}"
lday="${DAY[$i]:0}"
lwhat="${WHAT[$i]:0}"
lpattern="${PATTERN[$i]:0}"
lwhen="${WHEN[$i]:0}"
ldepth="${DEPTH[$i]:0}"


# das hier verwundert mich
echo ${ldir}
#
# tue dann etwas mit dem dir aus $ldir

let i=$i+1
done


für den Block in der cfg oben, also für "/cx/users/*/ams/auf" wird der
Stern aufgelöst und alle User mit entsprechenden Verzeichnissen angezeigt.
Für den zweite Block in der cfg, also "/cx/users/*/ams/wof" passiert
dies aber nicht, und es wird nur "/cx/users/*/ams/wof" ausgegeben.
Wenn ich die Blöcke vertause, also den 2. an die erste Settel setze,
passiert es wieder, dass im ersten Block der * aufgelöst wird und im
zweiten nicht - es liegt also nicht an den Verzeichnissen.

Kann mir jemand dieses unterschiedliche Verhalten erklären und einen
Lösungsansatz geben?



Jan

[Stefan Reuther]

Am 01.12.2022 um 12:44 schrieb Jan Novak:
> DIR=("${DIR[@]}" "/cx/users/*/ams/auf");

einfacher: DIR+=("/cx/users/*/ams/auf")

> Das shell script sieht so aus:
>
> ...
> include obige cfg
> ...
> anzahl=${#DIR[@]}
> while (test $i -lt $anzahl ); do
>     ldir="${DIR[$i]:0}"
>     lday="${DAY[$i]:0}"
>     lwhat="${WHAT[$i]:0}"
>     lpattern="${PATTERN[$i]:0}"
>     lwhen="${WHEN[$i]:0}"
>     ldepth="${DEPTH[$i]:0}"
>
> # das hier verwundert mich
> echo ${ldir}
> #
> # tue dann etwas mit dem dir aus $ldir
>
>     let i=$i+1
> done

Ich finde jetzt in dem Code keinen offensichtlichen Fehler, getestet damit:

DIR=()
DIR=("${DIR[@]}" "/bin/*")
DIR=("${DIR[@]}" "/lib/*")
anzahl=${#DIR[@]}
i=0
while ( test $i -lt $anzahl ); do

ldir="${DIR[$i]:0}"

echo ${ldir}
let i=$i+1
done

Insofern würde ich spekulieren, dass der Fehler in dem gekürzten Teil liegt.


Stefan

[Jan Novak]

Am 01.12.22 um 18:27 schrieb Stefan Reuther:

> Am 01.12.2022 um 12:44 schrieb Jan Novak:
>> DIR=("${DIR[@]}" "/cx/users/*/ams/auf");
>
> einfacher: DIR+=("/cx/users/*/ams/auf")

Ohhh... ja. Danke für den Tipp.

> Ich finde jetzt in dem Code keinen offensichtlichen Fehler, getestet damit:
>
> DIR=()
> DIR=("${DIR[@]}" "/bin/*")
> DIR=("${DIR[@]}" "/lib/*")
> anzahl=${#DIR[@]}
> i=0
> while ( test $i -lt $anzahl ); do
> ldir="${DIR[$i]:0}"
> echo ${ldir}
> let i=$i+1
> done
>
> Insofern würde ich spekulieren, dass der Fehler in dem gekürzten Teil liegt.

verdammt :-)
Ich wollte nicht den ganzen langen Code posten. Aber meine Vermutung lag
auch in dieser Richting.
Ich werde dasmorgen nochmal step by step durchgehen und "loggen". Danke
vorab.


Jan

[Christian Garbs]

Mahlzeit!

Jan Novak <rep...@gmail.com> wrote:

> für den Block in der cfg oben, also für "/cx/users/*/ams/auf" wird der
> Stern aufgelöst und alle User mit entsprechenden Verzeichnissen angezeigt.
> Für den zweite Block in der cfg, also "/cx/users/*/ams/wof" passiert
> dies aber nicht, und es wird nur "/cx/users/*/ams/wof" ausgegeben.
> Wenn ich die Blöcke vertause, also den 2. an die erste Settel setze,
> passiert es wieder, dass im ersten Block der * aufgelöst wird und im
> zweiten nicht - es liegt also nicht an den Verzeichnissen.

Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine Dateien
passt, also nichts gefunden wird? Dann bleibt das Pattern unaufgelöst.

Das fällt mir öfter bei sowas wie "for i in *.foo" auf die Füße, wenn
dann eine einzige Schleifeniteration mit "i='*.foo'" durchlaufen wird.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Zesterdaz, all mz kezboards were so far awaz...

[Jan Novak]

Am 01.12.22 um 21:19 schrieb Christian Garbs:

> Mahlzeit!
>
> Jan Novak <rep...@gmail.com> wrote:
>
>> für den Block in der cfg oben, also für "/cx/users/*/ams/auf" wird der
>> Stern aufgelöst und alle User mit entsprechenden Verzeichnissen angezeigt.
>> Für den zweite Block in der cfg, also "/cx/users/*/ams/wof" passiert
>> dies aber nicht, und es wird nur "/cx/users/*/ams/wof" ausgegeben.
>> Wenn ich die Blöcke vertause, also den 2. an die erste Settel setze,
>> passiert es wieder, dass im ersten Block der * aufgelöst wird und im
>> zweiten nicht - es liegt also nicht an den Verzeichnissen.
>
> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine Dateien
> passt, also nichts gefunden wird? Dann bleibt das Pattern unaufgelöst.

das stimmt (und hatte ich nicht bedacht), aber es gibt ja auch Ausgaben,
wenn ich die beiden Suchen vertausche.
Dennoch wichtiger Tipp.

Jan

[Ulli Horlacher]

Jan Novak <rep...@gmail.com> wrote:

>> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine Dateien
>> passt, also nichts gefunden wird? Dann bleibt das Pattern unaufgelöst.
>
> das stimmt (und hatte ich nicht bedacht)

Das ist einer der VIELEN Gruende, warum mit (ba)sh keine Programme
schreibt, sondern mit einer vernuenftigen (Skript-)Sprache.

"In sh will man nicht programmieren, man will es nur verstehen"
Kristian Koehntopp


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Stefan Reuther]

Am 02.12.2022 um 09:06 schrieb Ulli Horlacher:
> Jan Novak <rep...@gmail.com> wrote:
>>> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine Dateien
>>> passt, also nichts gefunden wird? Dann bleibt das Pattern unaufgelöst.
>>
>> das stimmt (und hatte ich nicht bedacht)
>
> Das ist einer der VIELEN Gruende, warum mit (ba)sh keine Programme
> schreibt, sondern mit einer vernuenftigen (Skript-)Sprache.

Auch wenn das im Großen und Ganzen stimmt, zumindest ab einer bestimmten
Programmgröße, so hat doch eine *aktuelle* bash eine Menge getan, da
Schreiben ernsthafterer Programme zu erleichtern.

Eine Standard-sh hat eben keine lokalen Variablen, keine Arrays, keine
Hashes. Und dann stümpert man eben rum, mit Glück 'eval x_$i=\$val',
meistens aber eher 'x="$x $val"', um sowas zu simulieren.


Stefan

[Jan Novak]

Am 02.12.22 um 09:06 schrieb Ulli Horlacher:

> Jan Novak <rep...@gmail.com> wrote:
>
>>> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine Dateien
>>> passt, also nichts gefunden wird? Dann bleibt das Pattern unaufgelöst.
>>
>> das stimmt (und hatte ich nicht bedacht)
>
> Das ist einer der VIELEN Gruende, warum mit (ba)sh keine Programme
> schreibt, sondern mit einer vernuenftigen (Skript-)Sprache.

da ist zwar jetzt OT, aber was wäre denn eine vernuenftigen
(Skript-)Sprache, welche standardmäßig verfügbar ist?


Jan

[Ulli Horlacher]

Perl.
Python.

[Stefan Reuther]

Am 05.12.2022 um 08:29 schrieb Ulli Horlacher:
> Jan Novak <rep...@gmail.com> wrote:
>> Am 02.12.22 um 09:06 schrieb Ulli Horlacher:

>>> Das ist einer der VIELEN Gruende, warum mit (ba)sh keine Programme
>>> schreibt, sondern mit einer vernuenftigen (Skript-)Sprache.
>>
>> da ist zwar jetzt OT, aber was wäre denn eine vernuenftigen
>> (Skript-)Sprache, welche standardmäßig verfügbar ist?
>
> Perl.
> Python.

Bei Debian ist das wohl im Basissystem.

Aber gerade von *dir* hätte ich jetzt erwartet, dass du mit einer
Solaris-Distribution um die Ecke kommst, die kein Perl enthält. Was
nicht heißt, dass man das nicht umgehend ändern sollte.

Standardmäßig in POSIX wäre wohl nur awk.


Stefan

[Thomas Dorner]

Perl läßt sich halt auf so gut wie jeder noch so exotischen Hardware
installieren. (sogar auf BS2000 :-)

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Stefan Kanthak]

"Thomas Dorner" <de.comp.os.unix.s...@spamgourmet.com> schrieb:

[...]

> Perl lنكt sich halt auf so gut wie jeder noch so exotischen Hardware

> installieren. (sogar auf BS2000 :-)

1) BS2000 ist KEINE Hardware.

2) Fuer 'ne Spectra 70 habe ich noch nie Perl gesehen, aber ein laufendes
BS2000!

Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Ulli Horlacher]

Stefan Reuther <stefa...@arcor.de> wrote:
> Am 05.12.2022 um 08:29 schrieb Ulli Horlacher:
>> Jan Novak <rep...@gmail.com> wrote:
>>> Am 02.12.22 um 09:06 schrieb Ulli Horlacher:
>>>> Das ist einer der VIELEN Gruende, warum mit (ba)sh keine Programme
>>>> schreibt, sondern mit einer vernuenftigen (Skript-)Sprache.
>>>
>>> da ist zwar jetzt OT, aber was wäre denn eine vernuenftigen
>>> (Skript-)Sprache, welche standardmäßig verfügbar ist?
>>
>> Perl.
>> Python.
>
> Bei Debian ist das wohl im Basissystem.
>
> Aber gerade von *dir* hätte ich jetzt erwartet, dass du mit einer
> Solaris-Distribution um die Ecke kommst, die kein Perl enthält.

Mir ist in den letzten 20 Jahren kein UNIX System untergekommen, in dem
kein Perl mit dabei ist.
Von sehr speziellen Router und Storagesystemen abgesehen.


"Solaris-Distribution" gibt es sowieso nicht.

[Martin Vaeth]

Christian Garbs <mi...@cgarbs.de> schrieb:

>
> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine Dateien
> passt, also nichts gefunden wird? Dann bleibt das Pattern unaufgelöst.
>
> Das fällt mir öfter bei sowas wie "for i in *.foo" auf die Füße, wenn
> dann eine einzige Schleifeniteration mit "i='*.foo'" durchlaufen wird.

set -o nullglob

Ist allerdings leider nicht POSIX: bosh und dash kennen das z.B. nicht.
bash und zsh hingegen schon.

[Ulli Horlacher]

Martin Vaeth <mar...@mvath.de> wrote:

>> Das fällt mir öfter bei sowas wie "for i in *.foo" auf die Füße, wenn
>> dann eine einzige Schleifeniteration mit "i='*.foo'" durchlaufen wird.
>
> set -o nullglob
>
> Ist allerdings leider nicht POSIX: bosh und dash kennen das z.B. nicht.
> bash und zsh hingegen schon.

In bash heisst es shopt -s nullglob

Allerdings fuehrt das zu bloeden Seiteneffekten, zB:
ls gibtsnicht*

In dem Zusammenhang ist auch dotglob noch interessant.
dann matcht * auch .*

[Christian Weisgerber]

On 2022-12-05, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Mir ist in den letzten 20 Jahren kein UNIX System untergekommen, in dem
> kein Perl mit dabei ist.

FreeBSD.
Kann man natürlich leicht nachinstallieren, ist aber von Haus aus
nicht dabei.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Thomas Dorner]

"Stefan Kanthak" <postmaster@[127.0.0.1]> writes:
> "Thomas Dorner" <de.comp.os.unix.s...@spamgourmet.com> schrieb:
>
> [...]
>

>> Perl läßt sich halt auf so gut wie jeder noch so exotischen Hardware

>> installieren. (sogar auf BS2000 :-)
>
> 1) BS2000 ist KEINE Hardware.

Stimmt, also genauer BS2000 auf Mainframe HW (S/390 und MIPS SR2000,
wenn ich mich recht erinnere - ist schon fast 2 Jahrzehnte her).

> 2) Fuer 'ne Spectra 70 habe ich noch nie Perl gesehen, aber ein laufendes
> BS2000!

Wenn da ein Posix Subsystem drauf ist, läßt sich vermutlich auch immer
noch Perl installieren.

[Helmut Waitzmann]

Ulli Horlacher <fram...@rus.uni-stuttgart.de>:

>
> In bash heisst es shopt -s nullglob
>
> Allerdings fuehrt das zu bloeden Seiteneffekten, zB:
> ls gibtsnicht*

So rächt sich die Faulheit, ein Leerzeichen und einen Punkt nicht
eintippen müssen zu wollen.  (Das bezieht sich auf diejenigen,
die die «ls»‐Spezifikation entsprechend festgelegt haben.)  Der
Kenner geht einfach so vor:

(
shopt -s nullglob &&
set -- gibtesnicht* &&
if ${1+:} false
then
ls -- "$@"
fi
)


Wer es mit gleicher Semantik etwas kryptischer haben will, nimmt


{
! ${1+:} false ||
ls -- "$@"
}

statt

if ${1+:} false
then
ls -- "$@"
fi


Wenn man das Nichtpassen des Dateinamenmusters lieber als Fehler
werten, statt als leere Menge gefundener Dateinamen haben möchte,
kann man es so machen:

(
shopt -s failglob &&
ls -- gibtesnicht*
)


Alles kein Problem.

[Helmut Waitzmann]

Christian Garbs <mi...@cgarbs.de>:

> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine
> Dateien passt, also nichts gefunden wird? Dann bleibt das Pattern
> unaufgelöst.
>
> Das fällt mir öfter bei sowas wie "for i in *.foo" auf die Füße,
> wenn dann eine einzige Schleifeniteration mit "i='*.foo'"
> durchlaufen wird.

for i in *.foo
do
if ! test -e "$i" && ! test -h "$i"
then
continue
fi
…
done

[Helmut Waitzmann]

Ulli Horlacher <fram...@rus.uni-stuttgart.de>:

> Jan Novak <rep...@gmail.com> wrote:
>
>>> Kann es sein, dass das Pattern "/cx/users/*/ams/wof" auf keine
>>> Dateien passt, also nichts gefunden wird? Dann bleibt das
>>> Pattern unaufgelöst.
>>
>> das stimmt (und hatte ich nicht bedacht)
>>
>
> Das ist einer der VIELEN Gruende, warum mit (ba)sh keine
> Programme schreibt, sondern mit einer vernuenftigen
> (Skript-)Sprache.

Sag das mal beispielsweise den Entwicklern der Shell‐Skripte in
«/etc/init.d/» und von «/usr/bin/ps2pdfwr».

Aber im speziellen Fall des Dateinamenmusters, das auf keinen
vorhandenen Dateinamen passt, gibt es im «bash» das Kommando
«shopt -s nullglob» oder auch das Kommando «shopt -s failglob»,
die beide mit dem Unsinn stehengebliebener unersetzter
Dateinamenmuster Schluss machen.

> "In sh will man nicht programmieren, man will es nur verstehen"
>
> Kristian Koehntopp

Wenn es doch nur so wäre!  Es liegen genug Shell‐Skripte herum,
denen man ansieht, dass sie jemand programmiert hat, ohne «sh»
verstanden zu haben.  Das Verzeichnis «/etc/init.d/» ist voll
davon.

Das Problem der meisten derartigen Programmierer ist, dass sie
den Unterschied zwischen einer Kommandozeile im «sh», die ein
simple command darstellt, und einem
«execvp()»‐Aufrufparameter‐Vektor ignorieren.

--
Hat man erst verstanden, wie Unix funktioniert, ist auch
das Shell-Handbuch kein Buch mit sieben Siegeln mehr.

[Martin Vaeth]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Martin Vaeth <mar...@mvath.de> wrote:
>
>>> Das fällt mir öfter bei sowas wie "for i in *.foo" auf die Füße, wenn
>>> dann eine einzige Schleifeniteration mit "i='*.foo'" durchlaufen wird.
>>
>> set -o nullglob
>>
>> Ist allerdings leider nicht POSIX: bosh und dash kennen das z.B. nicht.
>> bash und zsh hingegen schon.
>
> In bash heisst es shopt -s nullglob

Tatsächlich: Selbst da bemüht sich die bash noch, POSIX möglichst
unähnlich zu sein:

% bash -c "set -o noglob; echo *"
*
% bash -c "set -o nullglob; echo aa*"
bash: line 1: set: nullglob: invalid option name
aa*
%

Hingegen:

% zsh -c "set -o nullglob; echo aa*"

%

> Allerdings fuehrt das zu bloeden Seiteneffekten, zB:
> ls gibtsnicht*

In "vernünftigen" Shells hilft
set +o nullglob
In bash vermutlich nur
shopt -u nullglob

> In dem Zusammenhang ist auch dotglob noch interessant.
> dann matcht * auch .*

Solchen Blödsinn braucht man in der zsh nicht:
Da gibt man einfach * .* ein, wenn man beides meint; die blödsinnigen
Spezialfälle . und .. werden von der zsh automatisch gefiltert.

[Ralph Angenendt]

Well, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> "Solaris-Distribution" gibt es sowieso nicht.

Schillix (basierend auf OpenSolaris) und die ganzen Illumos-basierten
Versionen (Dyson, NexentaStor, OpenIndiana, SmartOS, u,a.) würde ich
schon als Solaris-Distributionen bezeichnen.

Keine Ahnung wie lebendig die alle sind.

Ralph
--
Is your mother worried?
Would you like us to assign someone to worry your mother?

[Michael Bäuerle]

Ralph Angenendt wrote:
> Well, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >
> > "Solaris-Distribution" gibt es sowieso nicht.
>
> Schillix (basierend auf OpenSolaris) und die ganzen Illumos-basierten
> Versionen (Dyson, NexentaStor, OpenIndiana, SmartOS, u,a.) würde ich
> schon als Solaris-Distributionen bezeichnen.
>
> Keine Ahnung wie lebendig die alle sind.

Nach dem Tod von Jörg Schilling dürfte es für Schillix nicht so gut
aussehen. Zumindest SmartOS ist aber lebendig.


[Subject angepasst]

[Ulli Horlacher]

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

>> "In sh will man nicht programmieren, man will es nur verstehen"
>>
>> Kristian Koehntopp
>

> Wenn es doch nur so wäre!  Es liegen genug Shell?Skripte herum,

> denen man ansieht, dass sie jemand programmiert hat, ohne «sh»
> verstanden zu haben.  Das Verzeichnis «/etc/init.d/» ist voll
> davon.

Das ist noch lange kein Grund es denen nachzutun :-}
"Wenn alle MIST bauen, dann will ich es auch!"

[Christian Weisgerber]

On 2022-12-06, Martin Vaeth <mar...@mvath.de> wrote:

>> In bash heisst es shopt -s nullglob
>
> Tatsächlich: Selbst da bemüht sich die bash noch, POSIX möglichst
> unähnlich zu sein:
>

> % bash -c "set -o nullglob; echo aa*"
> bash: line 1: set: nullglob: invalid option name

Oder man interpretiert es so, dass der Namensraum hinter -o von
POSIX reserviert ist und Erweiterungen in den neuen shopt-Namensraum
gesteckt werden.

*schulterzuck*

[Christian Weisgerber]

On 2022-12-06, Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> Wenn es doch nur so wäre!  Es liegen genug Shell‐Skripte herum,
> denen man ansieht, dass sie jemand programmiert hat, ohne «sh»
> verstanden zu haben.

Diese Aussage kann man auf jede beliebte Skript- und Programmiersprache
ausdehnen.

[Christian Weisgerber]

On 2022-12-06, Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> Wer es mit gleicher Semantik etwas kryptischer haben will, nimmt
>
>
> {
> ! ${1+:} false ||
> ls -- "$@"
> }

${1+ls -- "$@"}

[Helmut Waitzmann]

Christian Weisgerber <na...@mips.inka.de>:

> On 2022-12-06, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>
>> Wer es mit gleicher Semantik etwas kryptischer haben will,
>> nimmt
>>
>>
>> {
>> ! ${1+:} false ||
>> ls -- "$@"
>> }
>
> ${1+ls -- "$@"}

Ja, das ist noch kryptischer.  Aber ich trau' dem nicht so
recht.  Ich meine, mich zu erinnern, in «comp.unix.shell» mal
eine Diskussion gesehen zu haben, bei der jemand einen Shell
verwendet hat, bei dem zwischen «+» und «}» nur ein einziges Wort
stehen darf.


Dem könnte man aber mit


${1+ls} ${1+--} ${1+"$@"}

abhelfen.  Das sieht dann noch verzwickter aus, hat aber den
Nachteil, dass dreimal dieselbe Entscheidung getroffen werden
muss.

Außerdem bin ich nicht so sicher, dass der Fall, dass dieses
Kommando zu nichts expandiert, wirklich funktioniert.  Zumindest
wird er den Exit‐Status möglicherweise nicht auf 0 setzen,
sondern vom (hier nicht aufgeführten) vorausgehenden Kommando
unverändert stehen lassen.

Zumindest in meiner Vorstellung sollte die Anzeige einer leeren
Menge von Dateinamen aber mit dem Exit‐Status 0 enden: 
Schließlich erfüllt sie die gestellte Aufgabe fehlerfrei.

[Christian Weisgerber]

On 2022-12-07, Helmut Waitzmann <nn.th...@xoxy.net> wrote:

>> ${1+ls -- "$@"}
>
> Ja, das ist noch kryptischer.  Aber ich trau' dem nicht so
> recht.

Ich erinnere daran, dass wir die Umgebung durch "shopt -s nullglob"
schon auf bash verengt hatten.

[Martin Vaeth]

Helmut Waitzmann <nn.th...@xoxy.net> schrieb:
> Christian Weisgerber <na...@mips.inka.de>:
>>
>> ${1+ls -- "$@"}

>
> Außerdem bin ich nicht so sicher, dass der Fall, dass dieses
> Kommando zu nichts expandiert, wirklich funktioniert.

Das geht mit Sicherheit.

> Zumindest wird er den Exit‐Status möglicherweise nicht auf 0 setzen

Das mit Sicherheit nicht; aber will man das bei einem NOOP?
Falls ja, kann man das natürlich angeben:

${1+ls -- "$@"}${1-:}

[Christian Weisgerber]

On 2022-12-08, Martin Vaeth <mar...@mvath.de> wrote:

>>> ${1+ls -- "$@"}
>>

>> Zumindest wird er den Exit‐Status möglicherweise nicht auf 0 setzen
>
> Das mit Sicherheit nicht;

bash$ shopt -s nullglob
bash$ set -- gibtesnicht*
bash$ false
bash$ ${1+ls -- "$@"}
bash$ echo $?
0

[Martin Vaeth]

Christian Weisgerber <na...@mips.inka.de> schrieb:

>>>
>>> Zumindest wird er den Exit‐Status möglicherweise nicht auf 0 setzen
>>
>> Das mit Sicherheit nicht;
>
> bash$ shopt -s nullglob
> bash$ set -- gibtesnicht*
> bash$ false
> bash$ ${1+ls -- "$@"}
> bash$ echo $?
> 0

Du hast recht. Das selbe auf zsh, dash und bosh
(ohne die ersten beiden Zeilen, natürlich).
Den Grund dafür verstehe ich allerdings nicht:
Ein leeres Kommando sollte doch den Status nicht ändern.
(Dessen war ich sogar so sicher, dass ich die Behauptung ohne Test
in so starker Art formuliert hatte.)

[Martin Vaeth]

Martin Vaeth <mar...@mvath.de> schrieb:

>
> Ein leeres Kommando sollte doch den Status nicht ändern.

bash, dash, zsh, bosh sind sich jedenfalls einig, das doch zu tun:

% for i in bash dash zsh bosh; $i -c 'A=; false; $A; echo $?'
0
0
0
0

Im Gegensatz zu:

% for i in bash dash zsh bosh; $i -c 'A=; false;

echo $?'
1
1
1
1

Bei bash und dash geht es noch kurioser:

% for i in bash dash zsh bosh; $i -c 'A=; false;
;
echo $?'
bash: -c: line 2: syntax error near unexpected token `;'
bash: -c: line 2: `;'
dash: 2: Syntax error: ";" unexpected
1
1

[Helmut Waitzmann]

Martin Vaeth <mar...@mvath.de>:

Das klebt im Fall, dass es mindestens einen Positionsparameter
(positional parameter) gibt, den ersten Parameter zusätzlich an
den letzten hinten dran.

[Martin Vaeth]

Helmut Waitzmann <nn.th...@xoxy.net> schrieb:
> Martin Vaeth <mar...@mvath.de>:

>>
>> ${1+ls -- "$@"}${1-:}
>
> Das klebt im Fall, dass es mindestens einen Positionsparameter
> (positional parameter) gibt, den ersten Parameter zusätzlich an
> den letzten hinten dran.

Richtig. Das war nicht mein Tag, als ich das Posting geschrieben habe.

[Helmut Waitzmann]

Christian Weisgerber <na...@mips.inka.de>:

> On 2022-12-07, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>
>>> ${1+ls -- "$@"}
>>
>> Ja, das ist noch kryptischer.  Aber ich trau' dem nicht so
>> recht.
>
> Ich erinnere daran, dass wir die Umgebung durch "shopt -s nullglob"
> schon auf bash verengt hatten.

Und da funktioniert das?  Nicht nur, weil es im Augenblick
entsprechend implementiert ist, sondern, weil es das Handbuch
zusichert?  Die Beschreibung im «bash»‐Handbuch gibt das nach
meinem Verständnis nicht her:

${parameter:+word}
Use Alternate Value. If parameter is null or unset,
nothing is substituted, otherwise the expansion of
word is substituted.

Da steht «word», nicht «words».  POSIX
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>,
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446>)
hält es ebenso.

[Helmut Waitzmann]

Martin Vaeth <mar...@mvath.de>:

Da bin ich auch schon mal 'reingefallen.  Und da meine ich, ist
die Definition von «${var-…}» in der Tat nicht optimal gewählt.

Viel praktischer wäre die Definition «Wenn der Parameter
definiert (mit Doppelpunkt: und nicht leer) ist, ersetze den
Ausdruck durch nichts; wenn der Parameter nicht definiert (mit
Doppelpunkt: oder leer) ist, ersetze ihn durch den hinter dem
«-»‐Zeichen folgenden Ersatzwert».  (Aber der Zug, das zu ändern,
ist natürlich längst abgefahren.)


Damit hätte man dann einfach


${1-:} ls -- "$@"

schreiben können.

[Thomas Dorner]

Helmut Waitzmann <nn.th...@xoxy.net> writes:
> Christian Weisgerber <na...@mips.inka.de>:
>> On 2022-12-07, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>
>>>> ${1+ls -- "$@"}
>>>
>>> Ja, das ist noch kryptischer.  Aber ich trau' dem nicht so recht.
>>
>> Ich erinnere daran, dass wir die Umgebung durch "shopt -s nullglob"
>> schon auf bash verengt hatten.
>
> Und da funktioniert das?

Ja.

v+
~> (shopt -s nullglob; function xxx() { ${1+ls -d -- "$@"}; }; xxx X* ; echo =====; xxx C*)
=====
C Citations.txt
v-

> Da steht «word», nicht «words».  POSIX
> (<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>,
> <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446>)
> hält es ebenso.

Aber word ist als recht komplex definiert:

| In each case that a value of word is needed (based on the state of
| parameter, as described below), word shall be subjected to tilde
| expansion, parameter expansion, command substitution, and arithmetic
| expansion.

Das reicht für mich, word ist hier nicht als /[A-Za-z_0-9]+/ (oder so)
definiert, sondern als Ergebnis mehrerer Ersetzungen, bei denen
beliebige Worte entstehen können.

[Helmut Waitzmann]

Thomas Dorner
<de.comp.os.unix.s...@spamgourmet.com>:

> Helmut Waitzmann <nn.th...@xoxy.net> writes:
>> Christian Weisgerber <na...@mips.inka.de>:
>>> On 2022-12-07, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>>
>>>>> ${1+ls -- "$@"}
>>>>
>>>> Ja, das ist noch kryptischer.  Aber ich trau' dem nicht so
>>>> recht.
>>>
>>> Ich erinnere daran, dass wir die Umgebung durch "shopt -s
>>> nullglob" schon auf bash verengt hatten.

[Im «bash»‐Handbuch:]

>> Da steht «word», nicht «words».  POSIX
>> (<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>,
>> <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446>)
>> hält es ebenso.
>
> Aber word ist als recht komplex definiert:
>
> | In each case that a value of word is needed (based on the state of
> | parameter, as described below), word shall be subjected to tilde
> | expansion, parameter expansion, command substitution, and arithmetic
> | expansion.
>
> Das reicht für mich, word ist hier nicht als /[A-Za-z_0-9]+/
> (oder so) definiert, sondern als Ergebnis mehrerer Ersetzungen,
> bei denen beliebige Worte entstehen können.

Ich verstehe das Zitat anders:  «Word» ist nicht das Ergebnis
mehrerer Ersetzungen, bei denen beliebige Wörter entstehen
können, sondern der Ausgangspunkt, aus dem, wenn er Ersetzungen
unterzogen wird, beliebige Wörter entstehen können.

[Thomas Dorner]

OK, aber was wäre dann die Konsequenz? Daß beim ersten Blank ein
Syntaxfehler ausgelöst wird, weil kein '}' aufgetaucht ist? Und das
obwohl das Konstrukt ansonsten recht einfach zu identifizieren ist?

Auf jeden Fall sollte die Dokumentation etwas exakter sein, aber hey,
das ist schon ziemlich gut. In meiner Diplomarbeit habe ich mit einer
Sprache gearbeitet, da hieß es: "'_' kann durch beliebige weiße
Leerzeichen ersetzt werden, sofern sich das Ergebnis eindeutig ableiten
läßt." (Albtraum für jeden Compilerbauer ... ;-)

[Sieghard Schicktanz]

Hallo Thomas,

Du schriebst am Thu, 15 Dec 2022 19:09:20 +0100:

> das ist schon ziemlich gut. In meiner Diplomarbeit habe ich mit einer
> Sprache gearbeitet, da hieß es: "'_' kann durch beliebige weiße

^^^^^

> Leerzeichen ersetzt werden, sofern sich das Ergebnis eindeutig

^^^^^^^^^^^
Gab's da auch andersfarbige Leerzeichen? Syntax durch Zeichenfarbe
definiert?

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Christian Weisgerber]

On 2022-12-16, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:

> Syntax durch Zeichenfarbe definiert?

In ALGOL, so um 1960 herum, waren Schlüsselwörter durch Fettschrift
ausgezeichnet. Wie das dann konkret umgesetzt wurde, war Implemen-
tierungssache.

[Ulli Horlacher]

Christian Weisgerber <na...@mips.inka.de> wrote:
> On 2022-12-16, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>
>> Syntax durch Zeichenfarbe definiert?
>
> In ALGOL, so um 1960 herum, waren Schlüsselwörter durch Fettschrift
> ausgezeichnet. Wie das dann konkret umgesetzt wurde, war Implemen-
> tierungssache.

Breitere Loecher in Lochkarten? :-)

[Tim Landscheidt]

Christian Weisgerber <na...@mips.inka.de> wrote:

>> Syntax durch Zeichenfarbe definiert?

> In ALGOL, so um 1960 herum, waren Schlüsselwörter durch Fettschrift
> ausgezeichnet. Wie das dann konkret umgesetzt wurde, war Implemen-
> tierungssache.

GROSSBUCHSTABEN?

Tim

[Thomas Dorner]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> Christian Weisgerber <na...@mips.inka.de> wrote:
>> In ALGOL, so um 1960 herum, waren Schlüsselwörter durch Fettschrift
>> ausgezeichnet. Wie das dann konkret umgesetzt wurde, war Implemen-
>> tierungssache.
>
> Breitere Loecher in Lochkarten? :-)

Der war gut, YMMD!

(Und für kursiv wurden die Löcher schräg gestanzt ... ;-)

[Sieghard Schicktanz]

Hallo Stefan,

Du schriebst am 16 Dec 2022 19:35:31 GMT:

> >> weiße
> > ^^^^^
> >> Leerzeichen ersetzt werden, sofern sich das Ergebnis eindeutig
> > ^^^^^^^^^^^

...
> /whitespace characters/ sind in der Programmierung Zeichen,

- und nicht nur dort, die im Deutschen als "LEERZEICHEN" bezeichnet
werden, und zwar unabhängig von irgendeiner Farbangebae -

> die im Buchdruck weiß erscheinen, wie Leerzeichen,
> Tabulatoren oder Zeilenenden - auf deutsch "Leerraum"

Ja, so kann man das auch nennen.
Trotzdem ist das - wieder einmal, mit steigender Häufigkeit - ein
Zeichen für schlampige Übersetzung oder gar einer solchen ohne jede
Kenntnis der Zielsprache. Das muß nicht einmal immer eine automatische
Übersetzung sein, leider...

[nospa...@efbe.prima.de]

Am 17.12.22 um 21:14 schrieb Stefan Ram:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> Ein Zeilenende (\r\n oder Ähnliches) ist /kein/ Leerzeichen.
>
> Zum Beispiel habe ich dies gerade in einer Anleitung für
> Markdown gelesen:
>
> |End a line with two spaces
> |to start a new paragraph.
>
> . Also so wie ein Signaturtrenner "-- " mit einem
> Leerzeichen endet??
>
> Nein, wahrscheinlich ist gemeint: "zwei /Zeilenenden/".
> Diese als "spaces" zu bezeichnen, ist verwirrend!

Nein das ist richtig, mit 2 spaces am Ende wird bei markdown ein neuer
Paragraf begonnen, mit weniger werden die Zeilen zusammengezogen. Ist
manchmal echt blöde, wenn der editor spaces am Zeilenende löscht...

[Sieghard Schicktanz]

Hallo Christian,

Du schriebst am Fri, 16 Dec 2022 21:08:48 -0000 (UTC):

> > Syntax durch Zeichenfarbe definiert?
>
> In ALGOL, so um 1960 herum, waren Schlüsselwörter durch Fettschrift

in der Syntax-Beschreibung

> ausgezeichnet. Wie das dann konkret umgesetzt wurde, war Implemen-
> tierungssache.

Bei meiner Arbeit damit war das AFAIR Einschluß in "Hochkommas" ("'")
und Großschreibung. ALGOL 60 auf TR440.

[Andreas Eder]

On Sa 17 Dez 2022 at 20:15, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:

> Bei meiner Arbeit damit war das AFAIR Einschluß in "Hochkommas" ("'")
> und Großschreibung. ALGOL 60 auf TR440.

Ja, so habe ich das auch noch in Erinnerung.
Mit Lochkartenstanzer am Leibnizrechenzentrum.

'Andreas

[Christian Garbs]

Mahlzeit!

Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:

> Zum Beispiel habe ich dies gerade in einer Anleitung für
> Markdown gelesen:
>
> |End a line with two spaces
> |to start a new paragraph.

[…]

> Nein, wahrscheinlich ist gemeint: "zwei /Zeilenenden/".
> Diese als "spaces" zu bezeichnen, ist verwirrend!

Die Anleitung ist in der Tat verwirrend, wenn nicht sogar falsch.

Zwei Zeilenenden erzeugen, so wie von Dir vermutet, einen neuen
Absatz.

Zwei Leerzeichen am Zeilenende erzwingen einen *Zeilen*wechsel.

Markdown verhält sich ja sonst wie HTML: Umbrochen wird unabgängig von
den Zeilenenden im Source. Das " \n" wirkt wie ein <br>.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Die Zauberer schauderten. Sie waren nicht prinzipiell gegen das Draußen,
lehnten jedoch für sich selbst einen Platz darin ab.
(Terry Pratchett, Schweinsgalopp)

[Sieghard Schicktanz]

Hallo Stefan,

Du schriebst am 17 Dec 2022 19:41:31 GMT:

[Leerzeichen]

> >>Tabulatoren oder Zeilenenden - auf deutsch "Leerraum"
> >Ja, so kann man das auch nennen.
> >Trotzdem ist das - wieder einmal, mit steigender Häufigkeit - ein
> >Zeichen für schlampige Übersetzung
>

> Ganz im Gegenteil!
>
> /Ein Leerzeichen/ ist das Zeichen mit dem ASCII-/Unicode-Code 32.
> "Leerzeichen" ist der Plural davon.

NUR in ComputerTexten und NUR unter Verwendung des ASCII- oder der
entsprechenden Untermenge des Unicode oder ähnlicher Codierungen für
Textdarstellung.

> Ein Zeilenende (\r\n oder Ähnliches) ist /kein/ Leerzeichen.

> Ein Tabulator ist auch /kein/ Leerzeichen.
>
> Deswegen sagt man gerade "Leerraum" und nicht "Leerzeichen".

Steig' mal kurz aus Deinem Computer und schau' Dir mal Druckerzeugnisse
und andere Schriftstücke an. Da wirst Du sowieso keine definierbaren
"Leerzeichen" finden. Auch bei Satzmaschinen (früher) war das nicht so
strikt, und auch nicht bei Schreibmaschinen (kennst Du?).
Ich mein', mal eine Art Definition für "Leerzeichen" gesehen zu haben,
die meint, daß das Zeichen wären, die leere (nicht von sichtbaren
Buchstaben besetzte) Bereiche in einem Text erzeugen. Darunter fielen
dann Deine o.g. "Leerzeichen" und "Tabulatoren", aber NICHT ein
ZeilenVORSCHUB (nicht -ende, und eigentlich sogar eher ein -UMBRUCH),
weil hinter dem ja kein weiterer Text auf derselben Zeile folgt.

Aber das Haar weiter zu spalten überlasse ich jetzt Dir allein.

[Thomas Hochstein]

Stefan Ram schrieb:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> Zum Beispiel habe ich dies gerade in einer Anleitung für
> Markdown gelesen:
>
> |End a line with two spaces
> |to start a new paragraph.

Das ist wohl eine Verwechslung. Zwei Leerzeichen am Zeilenende führen zum
Zeilenumbruch (<br/> in der Umsetzung als HTML), Absätze werden durch eine
Leerzeile (zwei Zeilenschaltungen, aber wer beschreibt das so?)
voneinander getrennt (<p>...</p> in der Umsetzung als HTML).

-thh

[Thomas Hochstein]

nospa...@efbe.prima.de schrieb:

> Nein das ist richtig, mit 2 spaces am Ende wird bei markdown ein neuer
> Paragraf begonnen,

Nein. Ein neuer Absatz wird durch eine Leerzeile begonnen. Zwei
Leerzeichen führen zu einem Zeilenumbruch, aber nicht zu einem neuen
Absatz. Unterstützung für Paragraphen (oder Artikel) hat Markdown nicht.

[Helmut Waitzmann]

Thomas Dorner
<de.comp.os.unix.s...@spamgourmet.com>:
> Helmut Waitzmann <nn.th...@xoxy.net> writes:
>
>> Thomas Dorner
>> <de.comp.os.unix.s...@spamgourmet.com>:
>>> Helmut Waitzmann <nn.th...@xoxy.net> writes:
>>>> Christian Weisgerber <na...@mips.inka.de>:
>>>>> On 2022-12-07, Helmut Waitzmann <nn.th...@xoxy.net>
>>>>> wrote:
>>>>>
>>>>>>> ${1+ls -- "$@"}
>>>>>>
>>>>>> Ja, das ist noch kryptischer.  Aber ich trau' dem nicht so
>>>>>> recht.
>>>>>
>>>>> Ich erinnere daran, dass wir die Umgebung durch "shopt -s
>>>>> nullglob" schon auf bash verengt hatten.
>>
>>
>> [Im «bash»‐Handbuch:]
>>
>> Da steht «word», nicht «words».  POSIX
>> (<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>,
>> <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446>)
>> hält es ebenso.
>>>
>>> Aber word ist als recht komplex definiert:
>>>

[…]

>> Ich verstehe das Zitat anders:  «Word» ist nicht das Ergebnis
>> mehrerer Ersetzungen, bei denen beliebige Wörter entstehen
>> können, sondern der Ausgangspunkt, aus dem, wenn er Ersetzungen
>> unterzogen wird, beliebige Wörter entstehen können.
>
> OK, aber was wäre dann die Konsequenz?
>

Dass zum POSIX‐Standard kompatible Shells tun und lassen dürfen,
was sie wollen, wenn man ihnen statt eines «word»s mehrere
«word»s vorsetzt?

[Thomas Dorner]

Oder daß "word" nicht immer mit einem Wort in natürlicher Sprache
gleichgesetzt werden darf. Ich habe mal ein bischen im Standard gesucht
...

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446

|3.446 Word
|
|In the shell command language, a token other than an operator. In some
|cases a word is also a portion of a word token: in the various forms of
|parameter expansion, such as ${name-word}, and variable assignment, such
|as name=word, the word is the portion of the token depicted by word. The
|concept of a word is no longer applicable following word expansions-only
|fields remain.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01
ist auch ganz interessant, Punkt 2:

|The shell breaks the input into tokens: words and operators; see Token Recognition.

Und bei "Token Recognition" findet man dann bei Punkt 5:

|If the current character is an unquoted '$' or '`', the shell shall
|identify the start of any candidates for parameter expansion (Parameter
|Expansion), command substitution (Command Substitution), or arithmetic
|expansion (Arithmetic Expansion) from their introductory unquoted
|character sequences: '$' or "${", "$(" or '`', and "$((",
|respectively. The shell shall read sufficient input to determine the
|end of the unit to be expanded (as explained in the cited
|sections). While processing the characters, if instances of expansions
|or quoting are found nested within the substitution, the shell shall
|recursively process them in the manner specified for the construct that
|is found. The characters found from the beginning of the substitution
|to its end, allowing for any recursion necessary to recognize embedded
|constructs, shall be included unmodified in the result token, including
|any embedded or enclosing substitution operators or quotes. The token
|shall not be delimited by the end of the substitution.
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03)

Für mich heißt das, das "word" in den diversen Ersetzungen hört mit der
zugehörigen schließenden Klammer auf, und zwar unabhängig von dazwischen
vorkommenden Leerzeichen (gemeint sind Blanks).

Viele Grüße und frohe Feiertage, Thomas

[Helmut Waitzmann]

Thomas Dorner
<de.comp.os.unix.s...@spamgourmet.com>:
> Helmut Waitzmann <nn.th...@xoxy.net> writes:
>
>> Thomas Dorner
>> <de.comp.os.unix.s...@spamgourmet.com>:
>>> Helmut Waitzmann <nn.th...@xoxy.net> writes:

>>>> Thomas Dorner
>>>> <de.comp.os.unix.s...@spamgourmet.com>:

>>>> [Im «bash»‐Handbuch:] Da steht «word», nicht «words».  POSIX
>>>> (<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>,
>>>> <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446>)
>>>> hält es ebenso.
>>>>>
>>>>> Aber word ist als recht komplex definiert:
>>>>>
>> […]
>>
>>>> Ich verstehe das Zitat anders:  «Word» ist nicht das Ergebnis
>>>> mehrerer Ersetzungen, bei denen beliebige Wörter entstehen
>>>> können, sondern der Ausgangspunkt, aus dem, wenn er
>>>> Ersetzungen unterzogen wird, beliebige Wörter entstehen
>>>> können.
>>>
>>> OK, aber was wäre dann die Konsequenz?
>>>
>>
>> Dass zum POSIX‐Standard kompatible Shells tun und lassen
>> dürfen, was sie wollen, wenn man ihnen statt eines «word»s
>> mehrere «word»s vorsetzt?
>
> Oder daß "word" nicht immer mit einem Wort in natürlicher
> Sprache gleichgesetzt werden darf. Ich habe mal ein bischen im
> Standard gesucht ...
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_446
>
> |3.446 Word
> |
> |In the shell command language, a token other than an operator.

So ist also jedes ‚word‘ ein ‚token‘.  Zum Begriff ‚token‘ meint
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_413>
(Zitat):

3.413 Token

In the shell command language, a sequence of characters that the
shell considers as a single unit when reading input. A token is
either an operator or a word.

Note:

The rules for reading input are defined in detail in XCU Token
Recognition
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03>).


Soweit das Zitat.

Der zitierte Abschnitt befreit im Ausdruck


${var+word}

«word» aber nicht davon, ein ‚word‘ (also eine bestimmte Art
‚token‘) sein zu müssen.

ls -- "$@"

ist (ebenfalls laut
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03>)
kein ‚word‘ oder ‚token‘ sondern besteht aus dreien.