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

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

egrep depcreacted bei Debian sid?

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

Contents

  egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-07 21:47 +0200
    Re: egrep depcreacted bei Debian sid? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-08 01:42 +0200
      Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-08 06:56 +0200
        Re: egrep depcreacted bei Debian sid? Sven Hartge <sh-227@svenhartge.de> - 2022-09-08 09:24 +0200
          Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-08 08:51 +0000
            Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-08 08:53 +0000
          Re: egrep depcreacted bei Debian sid? Sven Hartge <sh-227@svenhartge.de> - 2022-09-08 11:03 +0200
            Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-08 11:47 +0200
              Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-08 11:28 +0000
                Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-08 14:07 +0200
                Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-08 15:37 -0400
                  Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-09 07:56 +0000
                Re: egrep depcreacted bei Debian sid? Andreas Karrer <ak-2a@gmx.ch> - 2022-09-09 10:28 +0000
                  Re: egrep depcreacted bei Debian sid? Ralph Angenendt <dein.name@strg-alt-entf.org> - 2022-09-09 10:41 +0000
                  egrep/fgrep deprecation warning in GNU grep 3.8 (was: egrep depcreacted bei Debian sid?) Ralph Angenendt <dein.name@strg-alt-entf.org> - 2022-09-09 10:43 +0000
                    Re: egrep/fgrep deprecation warning in GNU grep 3.8 Andreas Karrer <ak-2a@gmx.ch> - 2022-09-09 12:42 +0000
                    Re: egrep/fgrep deprecation warning in GNU grep 3.8 (was: egrep depcreacted bei Debian sid?) Thomas Klix <wotokl@web.de> - 2022-09-09 21:49 +0200
                      Re: egrep/fgrep deprecation warning in GNU grep 3.8 (was: egrep depcreacted bei Debian sid?) Marco Moock <mo01@posteo.de> - 2022-09-09 22:24 +0200
                      Re: egrep/fgrep deprecation warning in GNU grep 3.8 (was: egrep depcreacted bei Debian sid?) Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-09 21:29 +0000
                      Re: egrep/fgrep deprecation warning in GNU grep 3.8 Ralph Angenendt <dein.name@strg-alt-entf.org> - 2022-09-12 13:24 +0000
                        Re: egrep/fgrep deprecation warning in GNU grep 3.8 Thomas Klix <wotokl@web.de> - 2022-09-12 16:09 +0200
                          Re: egrep/fgrep deprecation warning in GNU grep 3.8 Thomas Klix <wotokl@web.de> - 2022-09-12 16:17 +0200
                        Re: egrep/fgrep deprecation warning in GNU grep 3.8 Andreas Kohlbach <ank@spamfence.net> - 2022-09-12 17:37 -0400
          Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-08 09:12 +0000
    Re: egrep depcreacted bei Debian sid? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-09 21:15 +0200
      Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-09 22:27 +0200
        Re: egrep depcreacted bei Debian sid? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-10 11:09 +0200
          Re: egrep depcreacted bei Debian sid? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-10 13:51 +0200
            Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-10 14:49 +0200
              Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-10 16:38 +0200
                Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-10 20:11 +0200
            Re: egrep depcreacted bei Debian sid? Peter Scholz <Peter_Scholz@vodafonmail.de> - 2022-09-12 07:34 +0200
              Re: egrep depcreacted bei Debian sid? Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-12 08:30 +0200
                Re: egrep depcreacted bei Debian sid? Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-12 09:45 +0200
          Re: egrep depcreacted bei Debian sid? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-10 23:19 +0200
            Re: egrep depcreacted bei Debian sid? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 14:05 +0200
              Re: egrep depcreacted bei Debian sid? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-11 17:27 +0200
                Re: egrep depcreacted bei Debian sid? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:08 +0200
                  Re: egrep depcreacted bei Debian sid? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-12 18:59 +0200
                    Re: egrep depcreacted bei Debian sid? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 07:44 +0200
            Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-11 15:40 +0200
              Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-11 18:04 +0000
                Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-11 19:31 +0000
                  Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-11 21:01 +0000
              Re: egrep depcreacted bei Debian sid? Andreas Karrer <ak-2a@gmx.ch> - 2022-09-12 21:44 +0000
            Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-11 18:08 +0000
              Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-11 20:26 +0200
                Re: egrep depcreacted bei Debian sid? Jens Schüßler <j.schuess@nurfuerspam.de> - 2022-09-11 20:55 +0200
                Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-11 19:40 +0000
                  Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-12 06:34 +0200
                    Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-12 06:59 +0000
                      Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-12 19:12 +0000
                        Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-12 20:49 +0000
                      Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-12 20:59 +0000
                      Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-12 17:34 -0400
                        Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-12 21:37 +0000
                          Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 06:42 +0000
                            Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-13 08:56 +0200
                              Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 07:14 +0000
                            Re: egrep depcreacted bei Debian sid? Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-13 08:14 +0000
                              Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 09:00 +0000
                                Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-13 12:10 +0200
                                  Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 11:12 +0000
                                    Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-13 13:41 +0200
                                Re: egrep depcreacted bei Debian sid? Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-13 15:24 +0000
                                  Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 18:19 +0000
                                    Re: egrep depcreacted bei Debian sid? Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-13 18:28 +0000
                                      Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 21:37 +0000
                                        Re: egrep depcreacted bei Debian sid? Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-13 22:03 +0000
                                        Re: egrep depcreacted bei Debian sid? Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-14 10:57 +0200
                                    Re: egrep depcreacted bei Debian sid? Jens Schüßler <j.schuess@nurfuerspam.de> - 2022-09-13 21:44 +0200
                                      Re: egrep depcreacted bei Debian sid? Claus Reibenstein <creibens@gmail.com> - 2022-09-15 16:40 +0200
                            Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-13 18:31 -0400
                              Re: egrep depcreacted bei Debian sid? Andreas Karrer <ak-2a@gmx.ch> - 2022-09-13 22:41 +0000
                                Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-13 20:48 -0400
                                  Re: egrep depcreacted bei Debian sid? Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 09:15 +0200
                                    Re: egrep depcreacted bei Debian sid? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-14 17:31 +0200
                                      Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-14 19:48 -0400
                                        Re: egrep depcreacted bei Debian sid? Christian Garbs <mitch@cgarbs.de> - 2022-09-15 18:57 +0000
                                        Re: egrep depcreacted bei Debian sid? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-15 22:30 +0200
                                          Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-15 19:44 -0400
                                          bunte Shell (was: Re: egrep depcreacted bei Debian sid?) Christian Garbs <mitch@cgarbs.de> - 2022-09-18 08:39 +0000
                                            Re: bunte Shell (was: Re: egrep depcreacted bei Debian sid?) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-22 09:02 +0200
                                            Re: bunte Shell Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2022-12-05 16:53 +0100
                                  Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-14 07:33 +0000
                                    Re: egrep depcreacted bei Debian sid? Andreas Kohlbach <ank@spamfence.net> - 2022-09-14 19:49 -0400
                                  Re: egrep depcreacted bei Debian sid? Marcus Jodorf <trap@killfile.de> - 2022-09-14 18:35 +0200
                                Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-14 07:44 +0000
                                  Re: egrep depcreacted bei Debian sid? Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-09-14 08:22 +0000
                                    Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-14 09:58 +0000
                                      Re: egrep depcreacted bei Debian sid? Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-14 10:18 +0000
                              Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-14 07:28 +0000
                        Re: egrep depcreacted bei Debian sid? Marcel Logen <333200007110-0201@ybtra.de> - 2022-09-12 23:44 +0200
                        ls (was: egrep depcreacted bei Debian sid?) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-13 00:00 +0200
                          Re: ls Andreas Kohlbach <ank@spamfence.net> - 2022-09-13 18:31 -0400
                            Re: ls Andreas Karrer <ak-2a@gmx.ch> - 2022-09-13 22:37 +0000
                              Re: ls Andreas Kohlbach <ank@spamfence.net> - 2022-09-13 20:37 -0400
                                Re: ls "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-14 17:19 +0200
                        Re: egrep depcreacted bei Debian sid? Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-09-13 05:54 +0000
                          Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-13 06:34 +0000
                            Re: egrep depcreacted bei Debian sid? Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-09-13 11:21 +0000
                            Re: egrep depcreacted bei Debian sid? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2022-09-13 11:42 +0000
                        Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-13 08:24 +0200
                        Re: egrep depcreacted bei Debian sid? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-09-13 06:27 +0000
                Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-11 21:15 +0000
              Re: egrep depcreacted bei Debian sid? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-11 19:32 +0000
                Re: egrep depcreacted bei Debian sid? Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-11 20:52 +0000
    Re: egrep depcreacted bei Debian sid? Thomas Klix <wotokl@web.de> - 2022-09-13 00:40 +0200
      Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-13 07:21 +0200
        Re: egrep depcreacted bei Debian sid? Patrick Rudin <taxi_bs@gmx.ch> - 2022-09-14 13:13 +0200
          Re: egrep depcreacted bei Debian sid? Marco Moock <mo01@posteo.de> - 2022-09-14 13:22 +0200
          Re: egrep depcreacted bei Debian sid? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-14 20:00 +0200
            Re: egrep depcreacted bei Debian sid? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-14 20:56 +0200

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

#124874 — Re: egrep/fgrep deprecation warning in GNU grep 3.8

Ralph Angenendt wrote at Mon, 12 Sep 2022 13:24:44 -0000 (UTC):
>
> Moin, du schriebst
>
> 	Subject: Re: egrep/fgrep deprecation warning in GNU grep 3.8 (was: egrep depcreacted bei Debian sid?)
> 	User-Agent: slrn/1.0.3 (Linux)
>
> Irgendwie ist bei deinem slrn
>
> strip_was_regexp " ?(was:.*)$" " ?(war:.*)$"
>
> kaputt, kann das sein? 

Stimmt, nach deinem Subject-Wechsel hätte mein slrn das was: weglassen
sollen. Danke für den Hinweis - ich suche gerade wie wild, wo das zu stehen
hat.

Thomas

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

#124875 — Re: egrep/fgrep deprecation warning in GNU grep 3.8

Thomas Klix wrote at Mon, 12 Sep 2022 16:09:01 +0200:
> Ralph Angenendt wrote at Mon, 12 Sep 2022 13:24:44 -0000 (UTC):
>>
>> Moin, du schriebst
>>
>> 	Subject: Re: egrep/fgrep deprecation warning in GNU grep 3.8 (was: egrep depcreacted bei Debian sid?)
>> 	User-Agent: slrn/1.0.3 (Linux)
>>
>> Irgendwie ist bei deinem slrn
>>
>> strip_was_regexp " ?(was:.*)$" " ?(war:.*)$"
>>
>> kaputt, kann das sein? 
>
> Stimmt, nach deinem Subject-Wechsel hätte mein slrn das was: weglassen
> sollen. Danke für den Hinweis - ich suche gerade wie wild, wo das zu stehen
> hat.

In de.alt.test hat es jetzt geklappt. :-)

Nochmals Danke.

Thomas

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

#124885 — Re: egrep/fgrep deprecation warning in GNU grep 3.8

On Mon, 12 Sep 2022 13:24:44 -0000 (UTC), Ralph Angenendt wrote:
>
> strip_was_regexp " ?(was:.*)$" " ?(war:.*)$"

Make subject-change, not war. ;-)
-- 
Andreas

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

#124794

Sven Hartge schrieb am 8/9/2022 09:24:

> Marco Moock <mo01@posteo.de> wrote:
>> Am Thu, 08 Sep 2022 01:42:18 +0200
>> schrieb Helmut Waitzmann <nn.throttle@xoxy.net>:
>
>>> In Debian 10 liegen solche Shell‐Skripte im Verzeichnis «/usr/bin/»,
>>> und ich nehme an, dass sie das auch noch eine ganze Weile tun
>>> werden:  Sie stören ja nicht.  (In Debian 6 gab es noch eigenständige
>>> Binärprogramme «egrep» und «fgrep».)
>
>> Jetzt wäre nur die Frage, was der Vorteil vom Entfernen dieser Skripte
>> für Debian wäre. Ein paar KB Speicherplatz, weniger Einträge in /bin.
>> Wo liegt da der Große Vorteil?
>
> Weil es ein Debianismus ist und in anderen Distributionen so nicht
> vorkommt.

Sieht mir eher nach einem BSDismus aus:
  gerald@mac-mini-m1:~$ which egrep
  /usr/bin/egrep
Dort ist egrep ein Hardlink auf grep.

-- 
Gerald

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

#124827

Am 07.09.22 um 21:47 schrieb Marco Moock:
> heute habe ich meinen X40 von Debian stable auf sid aktualisiert und im
> apt-stdout war es voll mit Meldungen, dass egrep deprecated sei und man
> grep -E nutzen soll.

> Würde man egrep entfernen, würde das ganz viele Dinge massiv stören.

Würde ein einfaches Skript mit Parameterweiterleitung an grep -e die 
Probleme nicht im Einzelfall lösen?


Marcel

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

#124831

Am Freitag, 09. September 2022, um 21:15:28 Uhr schrieb Marcel Mueller:

> Würde ein einfaches Skript mit Parameterweiterleitung an grep -e die 
> Probleme nicht im Einzelfall lösen?

Schon, das ist ja der aktuelle Stand bei Debian, wenn ich mich nicht
irre.
Bei Ubuntu ist das einfach ein Skript, was grep -E samt Parametern
aufruft.
Wenn das für immer so bleibt ist auch alles ok.
Problematisch wird es aber, wenn das nicht mehr standardmäßig der Fall
ist und der Aufruf von egrep/fgrep zu einem Fehler führt und nicht
funktioniert.

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

#124834

Am 09.09.22 um 22:27 schrieb Marco Moock:
> Am Freitag, 09. September 2022, um 21:15:28 Uhr schrieb Marcel Mueller:
> 
>> Würde ein einfaches Skript mit Parameterweiterleitung an grep -e die
>> Probleme nicht im Einzelfall lösen?
> 
> Schon, das ist ja der aktuelle Stand bei Debian, wenn ich mich nicht
> irre.
> Bei Ubuntu ist das einfach ein Skript, was grep -E samt Parametern
> aufruft.

Ah, das war mir gar nicht bewusst.
Ich kenne es noch aus der Zeit, umbenennen der Programmdatei Wirkung 
zeigte. Seltsam, aber hat auch funktioniert.

> Wenn das für immer so bleibt ist auch alles ok.
> Problematisch wird es aber, wenn das nicht mehr standardmäßig der Fall
> ist und der Aufruf von egrep/fgrep zu einem Fehler führt und nicht
> funktioniert.

Den Einwand mit der Posix-Kompatibilität verstehe ich aber schon.
Solche (unnötigen) Inkompatibilitäten erzeugen halt immer an irgendeiner 
Stelle Maintaining-Aufwand, zumal solcher Code häufig an verschiedenen 
Stellen und Distributionen verwendet wird.


Marcel

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

#124836

On 2022-09-10 09:09, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> Am 09.09.22 um 22:27 schrieb Marco Moock:
>> Wenn das für immer so bleibt ist auch alles ok.
>> Problematisch wird es aber, wenn das nicht mehr standardmäßig der Fall
>> ist und der Aufruf von egrep/fgrep zu einem Fehler führt und nicht
>> funktioniert.
>
> Den Einwand mit der Posix-Kompatibilität verstehe ich aber schon.
> Solche (unnötigen) Inkompatibilitäten erzeugen halt immer an irgendeiner 
> Stelle Maintaining-Aufwand, zumal solcher Code häufig an verschiedenen 
> Stellen und Distributionen verwendet wird.

An dieser Stelle ist es aber POSIX, das mutwillig die Kompatibilität
gebrochen hat. Ende der 80er-Jahre waren egrep und fgrep Teil aller
Unix-Varianten, und das auch nicht erst seit gestern (laut Wikipedia
wurden egrep und fgrep mit Version 7 Unix (1979) eingeführt). Die nicht
zu standardisieren, war schon eine zweifelhafte Entscheidung.

Und diese Entscheidung hat jetzt offenbar 34 Jahre niemanden gekümmert.
Ich habe dieser Tage keine aktuellen Erfahrungen mit Nicht-Linux-Unixen
mehr, aber ich wäre überrascht, wenn ich diese Tools auf einem Unix
nicht vorfinde.

Die Kompatibilität wird sicher nicht besser, wenn man Tools, die seit 40
Jahren de-facto-Standard sind, löscht.

        hp

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

#124837

Am Samstag, 10. September 2022, um 13:51:49 Uhr schrieb Peter J. Holzer:

> Die Kompatibilität wird sicher nicht besser, wenn man Tools, die seit
> 40 Jahren de-facto-Standard sind, löscht.

Ich glaube auch nicht, dass sowas dauerhaft passieren wird, da es
sicherlich viele Nutzer gäbe, die meckern würden.

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

#124838

Marco Moock wrote at Sat, 10 Sep 2022 14:49:32 +0200:
> Am Samstag, 10. September 2022, um 13:51:49 Uhr schrieb Peter J. Holzer:
>
>> Die Kompatibilität wird sicher nicht besser, wenn man Tools, die seit
>> 40 Jahren de-facto-Standard sind, löscht.
>
> Ich glaube auch nicht, dass sowas dauerhaft passieren wird, da es
> sicherlich viele Nutzer gäbe, die meckern würden.

s/dauerhaft/tatsächlich/

Thomas

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

#124840

Am Samstag, 10. September 2022, um 16:38:04 Uhr schrieb Thomas Klix:

> Marco Moock wrote at Sat, 10 Sep 2022 14:49:32 +0200:
> > Am Samstag, 10. September 2022, um 13:51:49 Uhr schrieb Peter J.
> > Holzer: 
> >> Die Kompatibilität wird sicher nicht besser, wenn man Tools, die
> >> seit 40 Jahren de-facto-Standard sind, löscht.  
> >
> > Ich glaube auch nicht, dass sowas dauerhaft passieren wird, da es
> > sicherlich viele Nutzer gäbe, die meckern würden.  
> 
> s/dauerhaft/tatsächlich/

Ich könnte es mir in Beta-Versionen schon vorstellen, aber wenn dann
die stabilen Linux-Distris rauskommen, die für den Produktivbetrieb
gedacht sind, wird es sicher wieder nen Rückzieher geben.

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

#124861

Peter J. Holzer schrieb am Sat, 10 Sep 2022 13:51:49 +0200:

> Und diese Entscheidung hat jetzt offenbar 34 Jahre niemanden gekümmert.
> Ich habe dieser Tage keine aktuellen Erfahrungen mit Nicht-Linux-Unixen
> mehr, aber ich wäre überrascht, wenn ich diese Tools auf einem Unix
> nicht vorfinde.

Wer hat diese Entscheidung jetzt auf Debian-Ebene letztlich getroffen?

Verläuft die Entscheidungsfindung im Vorfeld irgendwie transparent?

-- 
Gruß Peter

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

#124863

Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
>Peter J. Holzer schrieb am Sat, 10 Sep 2022 13:51:49 +0200:
>> Und diese Entscheidung hat jetzt offenbar 34 Jahre niemanden gekümmert.
>> Ich habe dieser Tage keine aktuellen Erfahrungen mit Nicht-Linux-Unixen
>> mehr, aber ich wäre überrascht, wenn ich diese Tools auf einem Unix
>> nicht vorfinde.
>
>Wer hat diese Entscheidung jetzt auf Debian-Ebene letztlich getroffen?

Der Paketmaintainer. Ich würde an seiner Stelle die
Upstream-Entscheidungen erst einmal mitgehen. Debian wird zu sehr
dafür gegeißelt, dass es angeblich an so vielen Stellen eigene
Sonderwege geht.

>Verläuft die Entscheidungsfindung im Vorfeld irgendwie transparent?

Nein.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

#124866

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> Peter Scholz <Peter_Scholz@vodafonmail.de> wrote:
> >Peter J. Holzer schrieb am Sat, 10 Sep 2022 13:51:49 +0200:  
> >> Und diese Entscheidung hat jetzt offenbar 34 Jahre niemanden
> >> gekümmert. Ich habe dieser Tage keine aktuellen Erfahrungen mit
> >> Nicht-Linux-Unixen mehr, aber ich wäre überrascht, wenn ich diese
> >> Tools auf einem Unix nicht vorfinde.  
> >
> >Wer hat diese Entscheidung jetzt auf Debian-Ebene letztlich
> >getroffen?  
> 
> Der Paketmaintainer. Ich würde an seiner Stelle die
> Upstream-Entscheidungen erst einmal mitgehen.

Grundsätzlich auf jeden Fall.

-- 
 SIC SEMPER
+--|=======>
  TYRANNIS

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

#124841

 Marcel Mueller <news.5.maazl@spamgourmet.org>: 

> Am 09.09.22 um 22:27 schrieb Marco Moock: 
>
>> Am Freitag, 09. September 2022, um 21:15:28 Uhr schrieb Marcel 
>> Mueller:
>>
>>> Würde ein einfaches Skript mit Parameterweiterleitung an grep 
>>> -e die Probleme nicht im Einzelfall lösen?

[…]

>> Bei Ubuntu ist das einfach ein Skript, was grep -E samt 
>> Parametern aufruft.
>
> Ah, das war mir gar nicht bewusst. 
>
> Ich kenne es noch aus der Zeit, umbenennen der Programmdatei 
> Wirkung zeigte. Seltsam, aber hat auch funktioniert.

 Dass hardlinken der Programmdatei auf die zusätzlichen Namen 
 «fgrep» und «egrep» funktioniert hat, liegt daran, dass (per 
 Konvention) Programmaufrufe mit dem Systemaufruf «execve» als 
 erstes Element des Aufrufparametervektors «argv[]», also als 
 «argv[0]» den Namen der aufgerufenen Programmdatei erhalten.

 Deshalb kann das Programm (wenn es entsprechend programmiert ist) 
 selber nachschauen, unter welchem Namen es aufgerufen worden ist 
 und entsprechend verfahren.

 Andere beliebte Kandidaten für solche Verfahren sind 
 «ls»/«ll»/«dir»/«l», «cp»/«mv»/«ln» oder 
 «bash»/«sh»/«-bash»/«-sh»/«-su», wobei die Shell‐Varianten mit 
 dem Minuszeichen nicht als Hardlink ins Dateisystem gestellt 
 werden sondern traditionell von «login» und «su» unter Abwandlung 
 der Aufrufkonvention beim Aufruf der Dateien «bash» oder «sh» 
 verwendet werden, wenn ein Login‐Shell (daher der Name!) 
 gestartet werden soll.

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

#124843

Am 10.09.2022 um 23:19 schrieb Helmut Waitzmann:

> Dass hardlinken der Programmdatei auf die zusätzlichen Namen «fgrep»
> und  «egrep» funktioniert hat, liegt daran, dass (per Konvention) 
> Programmaufrufe mit dem Systemaufruf «execve» als erstes Element
> des Aufrufparametervektors «argv[]», also als «argv[0]» den Namen
> der aufgerufenen Programmdatei erhalten.

Ne, das geht auch so:

#include <iostream>
#include <climits>
#include <cstdlib>
#include <dlfcn.h>

using namespace std;

int main()
{
	Dl_info dlInfo;
	char exePath[PATH_MAX];
	if( !dladdr( (void *)main, &dlInfo ) || !realpath( dlInfo.dli_fname, 
exePath ) )
		return EXIT_FAILURE;
	cout << exePath << endl;
}

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

#124845

Am 11.09.22 um 14:05 schrieb Bonita Montero:
> Ne, das geht auch so:
> 
> #include <iostream>
> #include <climits>
> #include <cstdlib>
> #include <dlfcn.h>
> 
> using namespace std;
> 
> int main()
> {
>      Dl_info dlInfo;
>      char exePath[PATH_MAX];
>      if( !dladdr( (void *)main, &dlInfo ) || !realpath( 
> dlInfo.dli_fname, exePath ) )
>          return EXIT_FAILURE;
>      cout << exePath << endl;
> }

Korrigiere mich, aber ich glaube das geht bei Hardlinks in die Hose, 
spätestens dann, wenn dieselbe ausführbare Datei zweimal geladen wird 
und die r/o-Segmente der ersten wiederverwendet werden.


Marcel

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

#124846

Am 11.09.2022 um 17:27 schrieb Marcel Mueller:
> Am 11.09.22 um 14:05 schrieb Bonita Montero:
>> Ne, das geht auch so:
>>
>> #include <iostream>
>> #include <climits>
>> #include <cstdlib>
>> #include <dlfcn.h>
>>
>> using namespace std;
>>
>> int main()
>> {
>>      Dl_info dlInfo;
>>      char exePath[PATH_MAX];
>>      if( !dladdr( (void *)main, &dlInfo ) || !realpath( 
>> dlInfo.dli_fname, exePath ) )
>>          return EXIT_FAILURE;
>>      cout << exePath << endl;
>> }
> 
> Korrigiere mich, aber ich glaube das geht bei Hardlinks in die Hose, 
> spätestens dann, wenn dieselbe ausführbare Datei zweimal geladen wird 
> und die r/o-Segmente der ersten wiederverwendet werden.

Was für ein Quatsch. Als würde der Kernel bei obigen Aufrufen
einem nicht korrekt sagen, welches Image geladen wurde.

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

#124879

Am 11.09.22 um 18:08 schrieb Bonita Montero:
>> Korrigiere mich, aber ich glaube das geht bei Hardlinks in die Hose, 
>> spätestens dann, wenn dieselbe ausführbare Datei zweimal geladen wird 
>> und die r/o-Segmente der ersten wiederverwendet werden.
> 
> Was für ein Quatsch. Als würde der Kernel bei obigen Aufrufen
> einem nicht korrekt sagen, welches Image geladen wurde.

Das tut er bestimmt, aber bei Hardlinks ist es ja _dasselbe_ Image.
Aber natürlich kann jede Programminstanz ihre eigene Dl_info Struktur haben.

Spätestens aber, wenn dasselbe shared object von verschiedenen anderen 
Libraries derselben Anwendung über unterschiedliche Hardlinks geladen 
wird, könnte es spannend werden. Es sei denn, der Kernel lädt die 
verschiedenen Hard-Links immer mehrfach. Das würde zumindest erklären, 
warum man für die Links von Shared Objects auf die aktuelle Version 
immer Softlinks nimmt.


Marcel

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

#124935

Am 12.09.2022 um 18:59 schrieb Marcel Mueller:
> Am 11.09.22 um 18:08 schrieb Bonita Montero:
>>> Korrigiere mich, aber ich glaube das geht bei Hardlinks in die Hose, 
>>> spätestens dann, wenn dieselbe ausführbare Datei zweimal geladen wird 
>>> und die r/o-Segmente der ersten wiederverwendet werden.
>>
>> Was für ein Quatsch. Als würde der Kernel bei obigen Aufrufen
>> einem nicht korrekt sagen, welches Image geladen wurde.
> 
> Das tut er bestimmt, aber bei Hardlinks ist es ja _dasselbe_ Image.
> Aber natürlich kann jede Programminstanz ihre eigene Dl_info Struktur 
> haben.
> 
> Spätestens aber, wenn dasselbe shared object von verschiedenen anderen 
> Libraries derselben Anwendung über unterschiedliche Hardlinks geladen 
> wird, könnte es spannend werden. Es sei denn, der Kernel lädt die 
> verschiedenen Hard-Links immer mehrfach. Das würde zumindest erklären, 
> warum man für die Links von Shared Objects auf die aktuelle Version 
> immer Softlinks nimmt.

Ne, meine Lösung funktioniert mit Hardlinks aber nicht mit Softlinks.
Für Softlinks benötigt man dann halt doch wieder argv[0].

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

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

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

csiph-web