Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #124865 > unrolled thread

Debian: abweichende Paketversionen finden

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-12 07:43 +0000
    Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-12 09:49 +0200
      Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-13 18:56 +0000
        Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 09:17 +0200
          Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-15 19:15 +0000
    Re: Debian: abweichende Paketversionen finden Marco Moock <mo01@posteo.de> - 2022-09-12 10:45 +0200
      Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-13 18:59 +0000
        Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 09:20 +0200
        Re: Debian: abweichende Paketversionen finden Marco Moock <mo01@posteo.de> - 2022-09-14 09:40 +0200
          Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-15 19:21 +0000
    Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-13 16:00 +0200
      Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-13 18:51 +0200
      Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-13 18:52 +0000
        Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-14 10:26 +0200
        Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-14 10:55 +0200
          Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-15 19:30 +0000
            Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-16 12:15 +0200
            Re: Debian: abweichende Paketversionen finden Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-16 11:11 +0000
              Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-17 12:45 +0200
                Re: Debian: abweichende Paketversionen finden Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-17 11:41 +0000
                  Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-17 21:43 +0200
                    Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-18 11:01 +0000
                      Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-19 12:11 +0200
                        Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-24 19:21 +0000
                          Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-25 16:48 +0200
                            Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-26 07:39 +0000
                              Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-26 10:54 +0200
                                Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-26 18:20 +0000
                                  Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-26 20:29 +0200
                                    Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-27 07:25 +0000
                                      Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-27 12:21 +0200
                                        Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-10-09 17:51 +0000
                                          Re: Debian: abweichende Paketversionen finden Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-12-27 17:37 +0100
                                      Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-27 18:49 +0200
                                        Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-27 19:29 +0200
                                        Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-28 16:36 +0200
                                        Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-03 23:59 +0200
                                          Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-04 09:49 +0200
                                            Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-06 19:57 +0200
                                  Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-03 23:58 +0200
                                    Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-04 09:49 +0200
                              Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-26 17:28 +0200
                                Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-26 18:18 +0000
                                  Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-27 15:54 +0200
                                    Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-27 19:58 +0000
                                    Re: Debian: abweichende Paketversionen finden Patrick Rudin <taxi_bs@gmx.ch> - 2022-09-27 23:04 +0200
                                      Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-28 15:01 +0200
                                        Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-28 18:44 +0000
                                          Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-29 11:55 +0200
                                            Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-29 15:16 +0000
                                              Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-29 20:30 +0200
                                                Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-29 21:28 +0000
                                                  Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-30 11:40 +0200
                                                    Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-30 21:05 +0000
                                                      Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-02 11:12 +0200
                                                        Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-10-02 19:13 +0000
                                                          Re: Debian: abweichende Paketversionen finden Martin Vaeth <martin@mvath.de> - 2022-10-02 20:51 +0000
                                                            Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-10-03 15:14 +0200
                                            Re: Debian: abweichende Paketversionen finden Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-09-29 20:46 +0200
                                              Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-30 11:48 +0200
                                      Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-29 21:13 +0000
                                        Re: Debian: abweichende Paketversionen finden Claus Reibenstein <creibens@gmail.com> - 2022-09-30 15:38 +0200
                                          Re: Debian: abweichende Paketversionen finden Claus Reibenstein <creibens@gmail.com> - 2022-09-30 15:51 +0200
                                            Re: Debian: abweichende Paketversionen finden Thomas Dorner <de.comp.os.unix.linux.misc.220930.dorner@spamgourmet.com> - 2022-09-30 20:40 +0200
                                              Re: Debian: abweichende Paketversionen finden Claus Reibenstein <creibens@gmail.com> - 2022-10-01 14:05 +0200
                                          Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-30 20:55 +0000
                Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-18 08:53 +0000
                  Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-18 11:28 +0200
              Re: Debian: abweichende Paketversionen finden Christian Garbs <mitch@cgarbs.de> - 2022-09-18 08:50 +0000
                Re: Debian: abweichende Paketversionen finden Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-18 11:19 +0200
                Re: Debian: abweichende Paketversionen finden Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-18 15:43 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#125450

Peter Scholz schrieb am Mon, 3 Oct 2022 23:58:20 +0200:

> Christian Garbs schrieb am Mon, 26 Sep 2022 18:20:46 -0000 (UTC):
> 
> > Böh :-(
> > 
> > Kann es sein, dass sowas wie "Dpkg::Options::=--force-confnew" von ucf
> > auch ignoriert wird?  Ich hatte einzelne Pakete, die trotz "nimm alle
> > neuen Conffiles" nachgefragt haben.  Das würde das erklären.
> 
> ja, wird von ucf ignoriert: soeben getestet

Testergebnis soeben in alle Systeme eingepflegt [✔]

Skript für Debian-Release-Wechsel optimiert.

Ergebnis: Optimierung und Beschleunigung der Abläufe.
Keine dpkg-Prompts.

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125285

Christian Garbs schrieb am Mon, 26 Sep 2022 07:39:31 -0000 (UTC):

> etckeeper führt nur Buch, das überschreibt keine Dateien.  Es wird Dir
> ein /etc/.git/ anlegen sowie seine eigenen Konfigurationsdateien nach
> /etc/etckeeper/ schreiben und ist ab dann unbemerkt hinter den
> Kulissen tätig.
> 
> Ich kann mir nicht vorstellen, dass das irgendwas kaputt machen
> könnte.

Habe gelesen: "... klinkt sich in Paketmanager wie Apt ein ..."
 
Hört sich so an, als ob das irgendwie gefährlich werden könnte :-)

--- --- ---

1) Auf den "großen Commit" will ich nicht warten:

Heute deshalb ein Bookworm auf meinem "großen Rechner" zu Testzwecken
eingerichtet.

2) Dort hinein etckeeper installiert:

etckeeper (1.18.18-1 Debian:testing [all])
git (1:2.35.1-1 Debian:testing [amd64])
git-man (1:2.35.1-1 Debian:testing [all])
liberror-perl (0.17029-1 Debian:testing [all]

3) Eine kleine Text-Änderung in /etc erzeugt.

4) Standard-Modus unverändert belassen:

Der automatische Modus soll Etckeeper veranlassen einmal täglich
ohne mein Zutun alle Änderungen in /etc zu sichern.

5) Dann git und etckeeper initialisiert.

6) Ersten Commit mit einer Beschreibung erstellt.

7) Überprüfung:

git log
git log /etc/hosts
git show [...]

--- --- ---

Scheint alles zu funktionieren :-)

Jetzt werde ich die nächsten Tage mein neues Bookworm täglich
updaten und abwarten, wie sich etckeeper verhält.

Dann werde ich mir mal die History ansehen und schaun, was man da sonst
noch eventuell dran rumschrauben kann :-) 

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125291

Mahlzeit!

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
> Christian Garbs schrieb am Mon, 26 Sep 2022 07:39:31 -0000 (UTC):
> 
>> etckeeper führt nur Buch, das überschreibt keine Dateien.  Es wird Dir
>> ein /etc/.git/ anlegen sowie seine eigenen Konfigurationsdateien nach
>> /etc/etckeeper/ schreiben und ist ab dann unbemerkt hinter den
>> Kulissen tätig.
>> 
>> Ich kann mir nicht vorstellen, dass das irgendwas kaputt machen
>> könnte.
> 
> Habe gelesen: "... klinkt sich in Paketmanager wie Apt ein ..."
>  
> Hört sich so an, als ob das irgendwie gefährlich werden könnte :-)

Das ist nichts wildes, weil apt/aptitude für genau sowas eine
Infrastruktur haben.

etckeeper hat einfach die Datei /etc/apt/apt.conf.d/05etckeeper
angelegt und das dort eingetragene wird jetzt automatisch vor und nach
der Paketinstallation aufgerufen.

Über diesen Mechanismus könntest Du ggf. auch Deine eigenen Skripte
dort einhängen, je nachdem, was die machen und wann die aufgerufen
werden sollen.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft.

[toc] | [prev] | [next] | [standalone]

#125312

Christian Garbs schrieb am Mon, 26 Sep 2022 18:18:16 -0000 (UTC):

> etckeeper hat einfach die Datei /etc/apt/apt.conf.d/05etckeeper
> angelegt und das dort eingetragene wird jetzt automatisch vor und nach
> der Paketinstallation aufgerufen.

Danke für den Hinweis!

Wird ja immer besser :-)

> Über diesen Mechanismus könntest Du ggf. auch Deine eigenen Skripte
> dort einhängen, je nachdem, was die machen und wann die aufgerufen
> werden sollen.

Die dort verwendete Syntax:

{ "if [ $a = $b ]; then $c ; fi"; };

gilt ganz grundsätzlich?

Eine solche Syntax für Bedingungen suche ich nämlich schon lange auch in
anderen Zusammenhängen für einzeilige Befehlsketten.

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125320

Mahlzeit!

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:

[ Es geht um /etc/apt/apt.conf.d/05etckeeper ]

> Die dort verwendete Syntax:
> 
> { "if [ $a = $b ]; then $c ; fi"; };
> 
> gilt ganz grundsätzlich?

Der Teil

| { "                            "; };

ist apt.conf-spezifische Konfigurations-Syntax.

Der Teil

>    if [ $a = $b ]; then $c ; fi     

ist ganz normales POSIX-konformes Shellskript.  Das lässt sich in der
Form überall nutzen, wo Shellskript möglich ist.  Ganz grob gesagt
ersetzen die Semikolons die Zeilenumbrüche.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Jetzt habe ich schon 5 Mal Linux installiert und immer wenn ich fertig bin,
stürzt es mit "login:" ab!                         (SuSE Installations-FAQ)

[toc] | [prev] | [next] | [standalone]

#125321

Peter Scholz wrote:
> Die dort verwendete Syntax:
> 
> { "if [ $a = $b ]; then $c ; fi"; };

Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als 
Vergleichsoperator benutzen??

Warum ärgere ich BASIC-verdorbener Amateur mich mit dummen Vertippern in 
R rum?

database %>% filter(p_number = 11200)
Fehler: Problem with `filter()` input `..1`.
✖ Input `..1` is named.
ℹ This usually means that you've used `=` instead of `==`.
ℹ Did you mean `p_number == 11200`?

Ehrlich, passiert mir täglich. Falls es einen Gott gibt, dann schmort 
Sinclair(ja, der vom ZX-81) in der Hölle...


Erstaunt

Patrick

[toc] | [prev] | [next] | [standalone]

#125328

Patrick Rudin schrieb am Tue, 27 Sep 2022 23:04:31 +0200:

> Peter Scholz wrote:
>> Die dort verwendete Syntax:
>> 
>> { "if [ $a = $b ]; then $c ; fi"; };
> 
> Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als 
> Vergleichsoperator benutzen??

Als BASH-verdorbener Amateur würde ich sagen, dass das zumindest als
string comparison funktionieren sollte:

https://tldp.org/LDP/abs/html/comparison-ops.html
 
> Warum ärgere ich BASIC-verdorbener Amateur mich mit dummen Vertippern in 
> R rum?
> 
> database %>% filter(p_number = 11200)

Als Database nutze ich dann gerne einfache Text-Dateien oder
Verzeichnisinhalte mit Text-Dateien. Als Frontend gebrauche ich für
solche Datenbank-Skripte vorzugsweise smenu und fzf (CLI) oder dmenu und
rofi (GUI).

Solche Befehlsketten lassen sich dann als Datensätze (=Zeilen)
speichern und die Datensätze als Befehlsketten executieren, ohne sie
als Bash-Skript ausführen zu müssen. Man könnte so etwas einfach ins
Terminal eintippen und Enter-Taste: Läuft ab als Stapelverarbeitung,
wie ein Bash-Skript. Macht natürlich keiner, deshalb fzf oder rofi :-)

Jetzt war ich aber hocherfreut in /etc/apt/apt.conf.d/05etckeeper
u.a. dies zu lesen: 

{ "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };

Diese Syntax habe ich bisher noch nirgendwo so gelesen.

Hiermit bin ich bisher immer gescheitert:

[...]; if [ $a = $b ]; then $c ; fi; [...];

Natürlich kann ich eine solche Zeile in ein Bash-Skript einfügen.
Als Bedingung in einer "reinen" einzeiligen Befehlskette - außerhalb
einer Bash-Datei - funktioniert es so aber nicht.

Entscheidend sind hier die Klammern und Anführungszeichen:

[...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Der Joey Hess ist schon ziemlich pfiffig und ich vermute, es
funktioniert auch ganz grundsätzlich. Werde ich jedenfalls bei nächster
Gelegenheit ausprobieren...

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125343

Mahlzeit!

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:

> Jetzt war ich aber hocherfreut in /etc/apt/apt.conf.d/05etckeeper
> u.a. dies zu lesen: 
> 
> { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };
> 
> Diese Syntax habe ich bisher noch nirgendwo so gelesen.
> 
> Hiermit bin ich bisher immer gescheitert:
> 
> [...]; if [ $a = $b ]; then $c ; fi; [...];

Was für eine Shell benutzt Du, dass Du sowas wie

if [ foo = bar ]; then echo A; else echo B; fi

nicht einfach direkt am Prompt eintippen kannst?
Das sollte auf jeder Posix-kompatiblen Shell funktionieren.

> Natürlich kann ich eine solche Zeile in ein Bash-Skript einfügen.
> Als Bedingung in einer "reinen" einzeiligen Befehlskette - außerhalb
> einer Bash-Datei - funktioniert es so aber nicht.

Es gibt da erstmal keinen Unterschied, ob Du diese Zeile

a) in eine Datei schreibst und diese dann durch eine Shell ausführen
   lasst, z.B. 'bash datei.txt'

b) in eine Datei schreibst und diese Datei dann der Shell auf stdin
   zuführst, z.B. 'bash < datei.txt'

c) diese Zeile am interaktiven Prompt der Shell selber eintippst


> Entscheidend sind hier die Klammern und Anführungszeichen:
> 
> [...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Die Anführungszeichen gehören aber zu den Konfigurations-Direktiven
innerhalb der apt-Konfiguration, das hat mit dem Shellskript nichts
mehr zu tun.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
* Progress (n.): The process through which Usenet has evolved from
  smart people in front of dumb terminals to dumb people in front of
  smart terminals.

[toc] | [prev] | [next] | [standalone]

#125354

Christian Garbs schrieb am Wed, 28 Sep 2022 18:44:50 -0000 (UTC):

> Was für eine Shell benutzt Du, dass Du sowas wie
> 
> if [ foo = bar ]; then echo A; else echo B; fi
> 
> nicht einfach direkt am Prompt eintippen kannst?

bash

> Das sollte auf jeder Posix-kompatiblen Shell funktionieren.

Unverkettet macht dein Beispiel keinen Sinn, verkettet hat es bei mir
nicht funktioniert. Habe jetzt leider kein Beispiel; kann mir aber auch
keines aus den Fingern saugen. 

Meine derzeit genutzten Verkettungen sind als Beispiel für diesen
Kontext hier auch ungeeignet, da zur allgemeinen Verständlichmachung,
eine Erklärung dieser komplexen Datenbank-Skripte den Rahmen dieses
Threads hier sprengen würden. Soviel zum UseCase: Es handelt sich u.a.
um einen selbst gebasteltes Bash-Skript als CLI- und GUI-Launcher
fürs Terminal oder ganz ohne x-Server u.a. z.B. mit einer
Import-Funktion aus der Bash-History und einer Export-Funktion ins
Primary/Clipbord oder einfach zur menügesteuerten Ausführung
(Debugging im Zusammenwirken mit der Bash-History) von Linux-Befehlen
aus einer oder mehreren Datenbanken, wozu auch die allgemeine Bash-
History zählt.

> Die Anführungszeichen gehören aber zu den Konfigurations-Direktiven
> innerhalb der apt-Konfiguration, das hat mit dem Shellskript nichts
> mehr zu tun.

Ja, dass ist so.

Entscheidend sind innerhalb der Verkettung [...]; ... ; [...]; die
Klammern und möglicherweise auch die Anführungszeichen, also nicht für
eine bloße Nutzung innerhalb von Shell-Skripten (als alleiniger
Stapelverarbeitungsprozess), sondern als separater Befehl außerhalb
des in Gang setzenden Skript-Prozesse als separater unabhängiger
(zweiter) (Hintergrund- oder Kind-)Prozess gespeist aus einer Database:

[...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Aus dem von dir Gesagten lässt sich für mich nicht zwingend herleiten,
dass es allgemein nicht funktionieren könnte. Immerhin schließt die
geschweifte Klammer mit einem zusätzlichen Semikolon, wodurch die
If-Then-Bedingung als (einheitlicher) Command ausgeführt wird. Das
könnte nämlich genau der Grund sein, warum ein solches eingebettetes
Verkettungs-Konstrukt ohne geschweifete Klammern und zusätzliches
Semikolon bei mir bisher nicht funktioniert hat.

Es geht mir nicht ums recht haben wollen. Werde es bei nächster
Gelegenheit einfach ausprobieren, wenn sich das Problem noch einmal
stellen sollte. Wenn es weiterhin nicht funktioniert, habe ich eben
Pech gehabt und es funktioniert dann eben nicht :-)

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125360

Mahlzeit!
Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
> Christian Garbs schrieb am Wed, 28 Sep 2022 18:44:50 -0000 (UTC):
 
>> Was für eine Shell benutzt Du, dass Du sowas wie
>> 
>> if [ foo = bar ]; then echo A; else echo B; fi
>> 
>> nicht einfach direkt am Prompt eintippen kannst?
> 
> bash
> 
>> Das sollte auf jeder Posix-kompatiblen Shell funktionieren.
> 
> Unverkettet macht dein Beispiel keinen Sinn, verkettet hat es bei mir
> nicht funktioniert. Habe jetzt leider kein Beispiel; kann mir aber auch
> keines aus den Fingern saugen.

Ich weiß nicht, was Du mit verkettet meinst.

Mehrere Bedingungen in einem if verkettet man über && oder ||, z.B.

   if [ 1 -gt 3 ] && [ 0 -ne 2 ]; then ...

Statt test (bzw. [ ) aufzurufen, kannst Du auch einfach den Returncode
eines anderen Kommandos abfragen:

   if grep suche datei; then ...


Zur Sinnhaftigkeit des Beispiels: Dass 'foo' ungleich 'bar' ist, ist
klar, dafür brauche ich kein Skript - es ging um die Demonstration der
Syntax.  Immerhin ließ es sich ja wohl eingeben und brachte das
erwartete Ergebnis ;-)

> Entscheidend sind innerhalb der Verkettung [...]; ... ; [...]; die
> Klammern und möglicherweise auch die Anführungszeichen, also nicht für
> eine bloße Nutzung innerhalb von Shell-Skripten (als alleiniger
> Stapelverarbeitungsprozess), sondern als separater Befehl außerhalb
> des in Gang setzenden Skript-Prozesse als separater unabhängiger
> (zweiter) (Hintergrund- oder Kind-)Prozess gespeist aus einer Database:

Ja, Klammern, Semikolons usw. sind wichtig für die Shell-Syntax.
Ansonsten kann ich Dir nur bedingt folgen.  Vermutlich brauchst Du
irgendwo ein eval und hast ggf. Probleme mit verschachteltem Quoting.

Nimm ein konkretes Beispiel (idealerweise etwas vereinfacht), zeig es
in de.comp.os.unix.shell und Dir wird höchstwahrscheinlich geholfen
werden.

Ein "Ergebnis aus einer Datenbankabfrage" könntest Du ja z.B. durch
ein echo mit fester Ausgabe ersetzen.

Ich lese da auch mit und bin neugierig.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Wusstet Ihr, daß ein Hellseher durchaus auch ein Schwarzseher sein kann?

[toc] | [prev] | [next] | [standalone]

#125362

Christian Garbs schrieb am Thu, 29 Sep 2022 15:16:55 -0000 (UTC):

> [...] und bin neugierig.

Allein, weil du neugierig bist, versuche ich dir eine Vorstellung zu
vermitteln und antworte auf dein Posting. Ansonsten sind wir jetzt
ziemlich weit vom eigentlichen Thema entfernt. Macht ja nix :-)

> [...] zeig es in de.comp.os.unix.shell [...]

Nein, es existiert kein Problem. Ich werde die Syntax bei passender
Gelegenheit einfach ausprobieren und gut ist.

> Vermutlich brauchst Du irgendwo ein eval.

Genau, am Ende werden die enthaltenen Kommandos in der Shell als
Argumente dieser Zeichen- und Befehlsverkettungen mit 'eval' ausgeführt.

> Ich weiß nicht, was Du mit verkettet meinst.

Vorher kommt etwas (zumindest $a, $b und $c) müssen deklariert worden
sein und hinterher kommt etwas ($c muss eine erkennbare Auswirkung haben
oder nicht).

Genau wie in /etc/apt/apt.conf.d/05etckeeper: Pre-Invoke und Post-Invoke

Vermutlich ist es gleichgültig, ob der Datenstrom wie bei mir aus
einer Verkettung allgemeiner Befehle besteht, der Programme startet oder
einer Verkettung spezieller etckeeper-Befehle, die einen Commit
generieren.

Vermutlich hat Joey Hess bei seiner Programm-Entwicklung auch erkannt,
dass es nur funktioniert, die If-Then-Bedingung als ganzheitlichen
Command auszuführen (durch Verpackung in geschweifte Klammern und
Hinzufügung eines Semikolon). 

> Nimm ein konkretes Beispiel (idealerweise etwas vereinfacht) [...]

In dem Thread '[aptitude] Suche nach direktem Programm' hatte ich
einmal ein einfaches Skript-Beispiel am Wed, 27 Jul 2022 12:52:09 +0200
beschrieben, welches durch Christoph 'Mehdorn' Weber am Sat, 6 Aug 2022
12:25:45 +0200 kommentiert wurde.

Es wird eine Variable deklariert: Hier sollte z.B. cal eingegeben
werden. Dann erfolgt die Treffer-Ausgabe unmittelbar im Firefox.

> #!/bin/bash
> read -e -p "Bitte einen Binary-Namen eingeben und Enter-Taste drücken >" var
> firefox --new-tab"https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=$var" &

So etwas funktioniert natürlich auch ohne Bash-Skript als einfacher
Befehl (=Befehls-Verkettung) unmittelbar in einer Bash-Shell:

>  read -e -p "Bitte einen Binary-Namen eingeben und Enter-Taste drücken >" var ; firefox --new-tab "https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=$var" &

Ich hoffe, der Sylpheed hat jetzt beim Senden nicht umgebrochen. Wen es
interessiert, mag die Befehlsverkettung (ohne Zitatzeichen '> ')
kopieren, in einen Terminal (als ganzheitlichen, einzeiligen Befehl)
einfügen und zur Stabelverarbeitung die Enter-Taste drücken.

--- --- ---

So - nun glaube ich, wir haben das Teil-Thema jetzt endgültig
totgeritten :-)

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125371

Mahlzeit!

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
> Christian Garbs schrieb am Thu, 29 Sep 2022 15:16:55 -0000 (UTC):

>> [...] zeig es in de.comp.os.unix.shell [...]
> 
> Nein, es existiert kein Problem.

Dann habe ich das 'bei mir funktioniert das mit der Befehlsverkettung
nicht' falsch verstanden.


>> Ich weiß nicht, was Du mit verkettet meinst.
> 
> Vorher kommt etwas (zumindest $a, $b und $c) müssen deklariert worden
> sein und hinterher kommt etwas ($c muss eine erkennbare Auswirkung haben
> oder nicht).
> 
> Genau wie in /etc/apt/apt.conf.d/05etckeeper: Pre-Invoke und Post-Invoke
> 
> Vermutlich ist es gleichgültig, ob der Datenstrom wie bei mir aus
> einer Verkettung allgemeiner Befehle besteht, der Programme startet oder
> einer Verkettung spezieller etckeeper-Befehle, die einen Commit
> generieren.
> 
> Vermutlich hat Joey Hess bei seiner Programm-Entwicklung auch erkannt,
> dass es nur funktioniert, die If-Then-Bedingung als ganzheitlichen
> Command auszuführen (durch Verpackung in geschweifte Klammern und
> Hinzufügung eines Semikolon). 

Ich habe eine Vermutung:

Du wolltest ein if-then-Shellkonstrukt auf Pre-Invoke und Post-Invoke
verteilen?  Das kann nicht gehen, weil sowohl das eine als auch das
andere getrennt durch eine Shell ausgeführt werden.  Dann würden beide
Shellaufrufe mit "das ist aber kein valides Skript" abbrechen.

Daskönnte theoretisch gehen, wenn ganz apt den gesamten von
Pre-Invoke und Post-Invoke umrahmten Code am Stück an eine Shell
übergibt - aber so wird das nicht implementiert sein, alleine schon
damit Pre-Invoke keine direkte Auswirkung (Shell-Variablen,
Environment-Variablen, Shell-Funktionen usw.) auf den Rest des
ausgeführten Codes haben kann.

Ich mag nicht erahnen, ob Joey Hess diesen Fall speziell erkannt hat
(hat er apt überhaupt geschrieben?), aber wenn man solche Callbacks
defensiv und vorsichtig implementiert, wird man vermutlich
(hoffentlich?) gar nicht auf die Idee kommen, alles zusammen innerhalb
eines Shellkontextes auszuführen.

>> Nimm ein konkretes Beispiel (idealerweise etwas vereinfacht) [...]

>  read -e -p "Bitte einen Binary-Namen eingeben und Enter-Taste drücken >" var ; firefox --new-tab "https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=$var" &

Ja, da erinnere ich mich an den Thread.  Ich hätte schreiben sollen "nimm
ein Beispiel, wo etwas nicht funktioniert" ;-)
Das da oben sieht ja unproblematisch aus.

> So - nun glaube ich, wir haben das Teil-Thema jetzt endgültig
> totgeritten :-)

Wenn es gar kein Problem gibt, dann ist ja auch nichts mehr zu
ergründen :)

Alles gut.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Die Basis jeder gesunden Ordnung ist ein Papierkorb.  (Kurt Tucholsky)

[toc] | [prev] | [next] | [standalone]

#125376

Christian Garbs schrieb am Thu, 29 Sep 2022 21:28:37 -0000 (UTC):

> Ja, da erinnere ich mich an den Thread. Ich hätte schreiben sollen "nimm
> ein Beispiel, wo etwas nicht funktioniert" ;-)



Joey Hess hat Recht: der apt-Stream ist ein Daten-Strom, wie jeder
andere:

| peter@x:~$ A="abc" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
| Bedingung ist wahr.

| peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
| Bedingung ist falsch.



Du hast auch Recht: die geschweiften Klammern mit dem zusätzlichen
Semikolon sind - zumindest in der Bash-Shell - überflüssig: 

| peter@x:~$ A="abc" ; if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi
| Bedingung ist wahr.

| peter@x:~$ A="abb" ; if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi
| Bedingung ist falsch.



Probieren geht über studieren :-)

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125390

Mahlzeit!

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:

> Joey Hess hat Recht: der apt-Stream ist ein Daten-Strom, wie jeder
> andere:
> 
> | peter@x:~$ A="abc" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
> | Bedingung ist wahr.
> 
> | peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
> | Bedingung ist falsch.

Nur zur Sicherheit:

Wenn in der /etc/apt/apt.conf.d/05etckeeper diese Zeile steht,

| DPkg::Pre-Invoke { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };

dann ist ist das aus apt-Sicht erst einmal nur dieses Konstrukt:

| Konfiguration::Option1 { "konfigurierter Wert"; };

Die geschweiften Klammern und die Anführungszeichen sind _nicht_ Teil
des Shellcodes, sondern reine apt.conf-Syntax.

Wenn ich mir die anderen Konfigurationsdateien in dem Verzeichnis
angucke, scheint es Strings und Listen von Strings zu geben:

| Einfacher::String "hallo";
| Liste::von::Werten { "ich"; "bin"; "ein"; "Frosch"; };

Und wenn ich in apt.conf(5) schaue, steht es da sogar erklärt.
D'oh ;-)  Immerhin hab ich es korrekt reverse-engineered.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Er nahm sie beim Händel, führte sie über die Haydn zum Bach und
verBrahmste ihr eine mit Liszt... Und nun weiß er nicht woHindemith
dem Mendelssöhnchen.

[toc] | [prev] | [next] | [standalone]

#125433

Christian Garbs schrieb am Fri, 30 Sep 2022 21:05:25 -0000 (UTC):

> Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
> 
>> Joey Hess hat Recht: der apt-Stream ist ein Daten-Strom, wie jeder
>> andere:
>> 
>> | peter@x:~$ A="abc" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
>> | Bedingung ist wahr.
>> 
>> | peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
>> | Bedingung ist falsch.
> 
> Nur zur Sicherheit:

Nun, die Bash-Syntax ist jetzt immerhin geklärt [✔]

Ich habe für den von mir beschriebenen UseCase daraus gelernt, dass man
nach dem 'then' kein ';' setzen darf.

Die Bash ist an dieser Stelle vielleicht nicht konsequent, aber der
Shell-Code ist in diesem Zusammenhang zugegebenermaßen einfacher und
schöner :-)
 
> Wenn in der /etc/apt/apt.conf.d/05etckeeper diese Zeile steht,
> 
> | DPkg::Pre-Invoke { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };

Bei mir stehen da zwei Zeilen, die der Konvention entsprechen:

| DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt";};

> Und wenn ich in apt.conf(5) schaue, steht es da sogar erklärt.
> D'oh ;-)  Immerhin hab ich es korrekt reverse-engineered.

Nun, damit sollte jetzt auch die Syntax der "Apt-Konfigurationssprache"
geklärt sein [✔]

Ein neuer Geltungsbereich kann mit geschweiften Klammern geöffnet
werden, ev. mit eingefügten Zeilenumbrüchen, um es leserlicher zu
gestalten. Listen können erstellt werden, indem ein Geltungsbereich
geöffnet wird und eine einzelne, von Anführungszeichen, denen ein
Schrägstrich folgt, eingeschlossene Zeichenkette eingefügt werden. Es
können mehrere Einträge eingefügt werden, jeweils getrennt durch einen
Schrägstrich. Die Anführungszeichen und abschließenden Strichpunkte
werden benötigt. Der Wert muss in einer Zeile stehen und es gibt keine
Möglichkeit Zeichenketten aneinander zu hängen.

--- --- ---

Damit werde ich jetzt zu meiner ursprünglich aufgeworfenen Frage
zurückkehren, was es bedeutet, dass sich der etckeeper in APT einfach so
reinhängt. Bevor ich die interne Verarbeitungslogik nicht verstanden
habe, halte ich den etckeeper für potenziell gefährlich.

Ich werde da in den nächsten Woche einmal an einigen Schaltern drehen,
um zu sehen, was passiert.

Was der etckeeper bis jetzt in meiner Test-Installation veranstaltet
hat, kann mich so recht nicht überzeugen.

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125439

Mahlzeit!

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
> Christian Garbs schrieb am Fri, 30 Sep 2022 21:05:25 -0000 (UTC):
> 
>> Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:

>>> | peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
>>> | Bedingung ist falsch.
>> 
>> Nur zur Sicherheit:
> 
> Nun, die Bash-Syntax ist jetzt immerhin geklärt [✔]
> 
> Ich habe für den von mir beschriebenen UseCase daraus gelernt, dass man
> nach dem 'then' kein ';' setzen darf.
> 
> Die Bash ist an dieser Stelle vielleicht nicht konsequent

Das ist ziemlich konsequent:

| if BEFEHL; then BEFEHL; else BEFEHL; fi

Jeder BEFEHL (da könnten auch jeweils mehrere stehen) wird mit einem
Semikolon (oder Zeilenumbruch) beendet.

Das gesamte if/then/else-Konstrukt ebenfalls, das ist quasi auch ein
BEFEHL.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Winzer 1: Ich probier mal den Wein.
Winzer 2: Bist Du verrückt?
Winzer 1: Egal, ich riskier' mal ein Auge!

[toc] | [prev] | [next] | [standalone]

#125441

Christian Garbs <mitch@cgarbs.de> schrieb:
>>>
>>> Nur zur Sicherheit:
>>
>> Nun, die Bash-Syntax ist jetzt immerhin geklärt [✔]

Diesbezüglich verhält sich die Bash gemäß POSIX.

>> Ich habe für den von mir beschriebenen UseCase daraus gelernt, dass
>> man nach dem 'then' kein ';' setzen darf.
>>
>> Die Bash ist an dieser Stelle vielleicht nicht konsequent
>
> Das ist ziemlich konsequent:

Nein, ist es nicht. Wie meist bei POSIX ist es nur historisch
bedingtes Kraut-und-Rüben.

>| if BEFEHL; then BEFEHL; else BEFEHL; fi
>
> Jeder BEFEHL (da könnten auch jeweils mehrere stehen) wird mit einem
> Semikolon (oder Zeilenumbruch) beendet.

Das erklärt nicht, weshalb woanders - z.B. nach dem "then"
(worum es hier ging; für "if" und "else" gilt aber Ähnliches)
*kein* Semikolon stehen darf, wohl aber ein Zeilenumbruch.
Und bei "for" muss das Semikolon vor dem "do" stehen, wo gar kein
BEFEHL endet.

Aber es kommt noch dicker: Bei einigen Fällen (im Zusammenhang
mit Umleitungen, Details habe ich vergessen; vielleicht gilt es
auch nur im Zusammenhang mit "for"), *muss* das Semikolon wiederum
durch einen Zeilenumbruch ersetzen werden.

Das folgende ist meine Interpretation für den Anachronismus:
Historisch war die Idee wohl die, dass man prinzipiell so schreiben
*muss*:

if U
then V
elif W
then X
else Y
fi

Dabei kann (wie sonst in der Bourne-shell oft üblich) das Zeilenende
*meist* auch durch ein ";" ersetzt werden (wie gesagt: von dem *meist*
gibt es in bestimmten Zusammenhängen hier Ausnahmen).
Und weil U, V, W, X, Y oft aus mehreren Teilen bestehen, sollte man
vermutlich auch so setzen können

if
   U1
   U2
then
   V1
   V2
elif
   W1
   W2
then
   X1
   X2
else
   Y1
   Y2
fi

Insbesondere darf man also nach "if", "then", usw. redundante
Zeilenumbrüche benutzen. Man hat aber "vergessen", dass es
konsequenterweise auch erlaubt sein müsste, diese durch
redundante ";" zu ersetzen.

[toc] | [prev] | [next] | [standalone]

#125446

Martin Vaeth schrieb am Sun, 2 Oct 2022 20:51:39 -0000 (UTC):

[ if BEFEHL; then BEFEHL; else BEFEHL; fi ]
 
> Das erklärt nicht, weshalb woanders - z.B. nach dem "then"
> (worum es hier ging; für "if" und "else" gilt aber Ähnliches)
> *kein* Semikolon stehen darf, wohl aber ein Zeilenumbruch.
> Und bei "for" muss das Semikolon vor dem "do" stehen, wo gar kein
> BEFEHL endet.
> 
> Aber es kommt noch dicker: Bei einigen Fällen (im Zusammenhang
> mit Umleitungen, Details habe ich vergessen; vielleicht gilt es
> auch nur im Zusammenhang mit "for"), *muss* das Semikolon wiederum
> durch einen Zeilenumbruch ersetzen werden.
> 
> Das folgende ist meine Interpretation für den Anachronismus:
> Historisch war die Idee wohl die, dass man prinzipiell so schreiben
> *muss*:
> 
> if U
> then V
> elif W
> then X
> else Y
> fi
> 
> Dabei kann (wie sonst in der Bourne-shell oft üblich) das Zeilenende
> *meist* auch durch ein ";" ersetzt werden (wie gesagt: von dem *meist*
> gibt es in bestimmten Zusammenhängen hier Ausnahmen).
> Und weil U, V, W, X, Y oft aus mehreren Teilen bestehen, sollte man
> vermutlich auch so setzen können
> 
> if
>    U1
>    U2
> then
>    V1
>    V2
> elif
>    W1
>    W2
> then
>    X1
>    X2
> else
>    Y1
>    Y2
> fi
> 
> Insbesondere darf man also nach "if", "then", usw. redundante
> Zeilenumbrüche benutzen. Man hat aber "vergessen", dass es
> konsequenterweise auch erlaubt sein müsste, diese durch
> redundante ";" zu ersetzen.

Vielen Dank, dass du dir die Mühe gemacht hast, das Problem in
allgemeiner Form in dieser Weise geradezu lehrbuchmäßig und
hundertprozentig auf den Punkt brillant aus zu formulieren.

Alle Linux-User müssen mit diesen Ungereimtheiten leben. 

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

#125366

Hallo Peter Scholz,

> [...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Sag'mal, welche Programmiersprache soll das sein, in der es sowas gibt?
Wenn ich richtig verstaden haben sollte, kam mir das vor, als ob das
ein Shell-Ausdruck sein sollte.
Der kann so aber gleich aus mehreren Gründen nicht funktionieren.
Zunächst mal - ohne Berücksichtigung der Umgebung in den "[]", ist das
ein Shell-Befehl. Die "{}" übergeben den gleich mal einer Sub-Shell,
die dann den Inhalt der Klammern als ihren Befehl ausführt.
Dieser ist dann mit den Anführungszeichen ('""') zu _einem_ Shell-
"Wort" zusammengefasst und wird von der dzf., weil als erstes Wort des
Befehls, als aufzurufendes Programm oder eingebauter Befehl
interpretiert. Es _gibt_ aber kein aufrufbares Programm oder ingebauten
Befehl mit diesem Namen, also meldet die Shell nur diesen Umstand und
tut sonst nichts.
Würde irgendwie erreicht, daß aber der Inhalt der Anführungszeichen als
Shell-Befehl verarbeitet würde (könnte ggfs. per "eval" gehen), kann
das immer noch gehörig schiefgehen, wenn die Shell-Variablen a, b und c
nicht passend gesetzt sind. "Passend" bedeutet hier
Für a und b: es müssen _einfache_ Strings _ohne_ Leerzeichen sein, die
_nicht leer_ sein dürfen. Anderenfalls ist die Syntax des Vergleichs
verletzt, bei Leerzeichen im Inhalt einer der Variablen sind zuviele
Operanden vorhanden, bei einem Leerstring zuwenige.
Für c gilt, daß die Variable einen gültigen Shell-Befehl darstellt. Der
könnte da sogar Leerzeichen enthalten, wenn .B. dem Befehls-Wort am
Anfang Parameter mitgegeben werden sollen. c="ls *" könnte z.B. evtl.
funktionieren. Ein Leerstring an dieser Stelle ist aber auch ein
Syntax- Fehler, da der Inhalt des Ausführungsteils des "if"-Statements
nicht leer sein darf.

Ich weiß, lesen, und das noch von Handbüchern und ähnlichen
Beschreibungen gilt inzwischen als unfein und ist unüblich, wenn nicht
sogar schändlich. Aber es gilöt halt immer noch "Lesen bildet", und
zwar _aus_ und nicht ein wie die sonst oft üblichen Vorgehensweisen...

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

[toc] | [prev] | [next] | [standalone]

#125377

Sieghard Schicktanz schrieb am Thu, 29 Sep 2022 20:46:20 +0200:

> Wenn ich richtig verstanden haben sollte, kam mir das vor, als ob das
> ein Shell-Ausdruck sein sollte.

ja

-- 
Gruß Peter

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web