egrep depcreacted bei Debian sid?

[Marco Moock]

Hallo zusammen,

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.
Ist früher oder später das Entfernen von egrep vorgesehen?

https://manpages.debian.org/bullseye/grep/egrep.1.en.html

| In addition, the variant programs egrep, fgrep and rgrep are the same
| as grep -E, grep -F, and grep -r, respectively. These variants are
| deprecated, but are provided for backward compatibility.

Weiß jemand, wie lange das gehen soll?
Würde man egrep entfernen, würde das ganz viele Dinge massiv stören.

Warum wird es deprecated, wenn es bleiben soll, weil man es nicht
entfernen will?

--
Gruß
Marco

[Helmut Waitzmann]

Marco Moock <mo...@posteo.de>:

> 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.
> Ist früher oder später das Entfernen von egrep vorgesehen?
>

Wahrscheinlich eher später als früher.  Wenn du willst, kannst du
den Verantwortlichen die Meldung jeweils mitteilen und ihnen
empfehlen, dass sie, wenn sie das nächste Mal an der
entsprechenden Stelle Hand anlegen, nebenbei auch gleich noch
«fgrep» durch «grep» «-F» und «egrep» durch «grep» «-E»
ersetzen.  Aufwändig ist diese Änderung ja nicht.

> https://manpages.debian.org/bullseye/grep/egrep.1.en.html
>
> | In addition, the variant programs egrep, fgrep and rgrep are
> | the same as grep -E, grep -F, and grep -r, respectively. These
> | variants are deprecated, but are provided for backward
> | compatibility.
>
> Weiß jemand, wie lange das gehen soll?
>

Im POSIX‐Standard sind «egrep» und «fgrep» nicht enthalten.  In
der Beschreibung von «grep» steht dort aber im Abschnitt
«RATIONALE»
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html#tag_20_55_18>):

This grep has been enhanced in an upwards-compatible way to
provide the exact functionality of the historical egrep and fgrep
commands as well. It was the clear intention of the standard
developers to consolidate the three greps into a single command.

The old egrep and fgrep commands are likely to be supported for
many years to come as implementation extensions, allowing
historical applications to operate unmodified.

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

Vermute ich auch.

> Warum wird es deprecated, wenn es bleiben soll, weil man es
> nicht entfernen will?

Ich vermute, es soll nicht bleiben, und man will es entfernen –
man traut sich nur (noch) nicht, es zu tun.

Wenn alle Stricke reißen, kann man immer noch im Verzeichnis
«/usr/local/bin/» die Shell‐Skripte

#!/bin/sh -
# fgrep
exec grep -F "$@"

#!/bin/sh -
# egrep
exec grep -E "$@"

unterbringen.  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».)

[Marco Moock]

Am Thu, 08 Sep 2022 01:42:18 +0200
schrieb Helmut Waitzmann <nn.th...@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».)

In Bookworm gibt es kein eigenständiges Programm mehr.

m@x40:~$ cat /bin/egrep
#!/bin/bash
cmd=${0##*/}
echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2
exec grep -E "$@"
m@x40:~$

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?

[Sven Hartge]

Marco Moock <mo...@posteo.de> wrote:
> Am Thu, 08 Sep 2022 01:42:18 +0200
> schrieb Helmut Waitzmann <nn.th...@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. Scripte, die "egrep" oder "fgrep" benutzen sind somit nicht
portabel. Um das nicht zu ermutigen ist es sinnvoll, diese Abweichungen
von der Norm zu tilgen.

S°

--
Sigmentation fault. Core dumped.

[Ulli Horlacher]

Sven Hartge <sh-...@svenhartge.de> wrote:

>>> 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. Scripte, die "egrep" oder "fgrep" benutzen sind somit nicht
> portabel. Um das nicht zu ermutigen ist es sinnvoll, diese Abweichungen
> von der Norm zu tilgen.

root@sp-i:~# rpm -qf /usr/bin/egrep
grep-2.20-3.el7.x86_64

root@sp-i:~# head -2 /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"

--
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/

[Ulli Horlacher]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>
>>>> 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. Scripte, die "egrep" oder "fgrep" benutzen sind somit nicht
>> portabel. Um das nicht zu ermutigen ist es sinnvoll, diese Abweichungen
>> von der Norm zu tilgen.
>
> root@sp-i:~# rpm -qf /usr/bin/egrep
> grep-2.20-3.el7.x86_64
>
> root@sp-i:~# head -2 /etc/os-release
> NAME="Red Hat Enterprise Linux Server"
> VERSION="7.9 (Maipo)"

root@ptm2:~# rpm -qf /usr/bin/egrep
grep-3.1-6.el8.x86_64

root@ptm2:~# head -2 /etc/os-release
NAME="CentOS Stream"
VERSION="8"

[Sven Hartge]

Ich muss mich korrigieren, die Entscheidung kommt von den grep-Machern
selbst, nicht von Debian.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996

Debian selbst wird diskutieren, die Wrapper beizubehalten. Für den
Moment, grep-3.8 wird aus Debian Testing ferngehalten:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019335

[Gerald E¡scher]

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

> Marco Moock <mo...@posteo.de> wrote:
>> Am Thu, 08 Sep 2022 01:42:18 +0200
>> schrieb Helmut Waitzmann <nn.th...@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

[Thomas Klix]

Sven Hartge wrote at Thu, 8 Sep 2022 11:03:07 +0200:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marco Moock <mo...@posteo.de> wrote:
>>> Am Thu, 08 Sep 2022 01:42:18 +0200
>>> schrieb Helmut Waitzmann <nn.th...@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. Scripte, die "egrep" oder "fgrep" benutzen sind somit nicht
>> portabel. Um das nicht zu ermutigen ist es sinnvoll, diese Abweichungen
>> von der Norm zu tilgen.
>
> Ich muss mich korrigieren, die Entscheidung kommt von den grep-Machern
> selbst, nicht von Debian.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604

Daraus:
| It is painful to see the unconditional complaint (grep 3.8) about
| [ef]grep usage when those programs have been present since the beginning
| of Unix. I have hundreds of scripts that use [ef]grep since for many
| years they were either the only, or then later the most portable, way to
| get the behavior.

IMO sind [ef]grep so uralt, dass man sie nicht mehr wegbekommt, so sinnvoll
das auch sein möge.
Ob man das jetzt als Shell-Script oder als Hardlink (mit argv[0] im Programm
auswerten) realisiert, ist dann auch egal. [ef]grep wird nicht totzukriegen
sein.

Thomas

[Ulli Horlacher]

Thomas Klix <wot...@web.de> wrote:

> IMO sind [ef]grep so uralt, dass man sie nicht mehr wegbekommt, so sinnvoll
> das auch sein möge.
> Ob man das jetzt als Shell-Script oder als Hardlink (mit argv[0] im Programm
> auswerten) realisiert, ist dann auch egal. [ef]grep wird nicht totzukriegen
> sein.

Die legt man dann halt in /usr/local/bin/ an, wo ist das Problem?

[Thomas Klix]

Ulli Horlacher wrote at Thu, 8 Sep 2022 11:28:57 +0000 (UTC):
> Thomas Klix <wot...@web.de> wrote:
>
>> IMO sind [ef]grep so uralt, dass man sie nicht mehr wegbekommt, so sinnvoll
>> das auch sein möge.
>> Ob man das jetzt als Shell-Script oder als Hardlink (mit argv[0] im Programm
>> auswerten) realisiert, ist dann auch egal. [ef]grep wird nicht totzukriegen
>> sein.
>
> Die legt man dann halt in /usr/local/bin/ an, wo ist das Problem?

Ich wüsste nicht, warum man sie nicht in /usr/bin belassen sollte.
Ein Problem sehe ich nicht.

Thomas

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

>>> Ob man das jetzt als Shell-Script oder als Hardlink (mit argv[0] im Programm
>>> auswerten) realisiert, ist dann auch egal. [ef]grep wird nicht totzukriegen
>>> sein.
>>
>> Die legt man dann halt in /usr/local/bin/ an,
>

> Das *muss* automatisch bei der Installation passieren.

Dafuer hat man ja sein Installations-Management wo man das eintraegt.
Eine Zeile mehr.

[Andreas Karrer]

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

> Thomas Klix <wot...@web.de> wrote:
>
>> IMO sind [ef]grep so uralt, dass man sie nicht mehr wegbekommt, so sinnvoll
>> das auch sein möge.
>> Ob man das jetzt als Shell-Script oder als Hardlink (mit argv[0] im Programm
>> auswerten) realisiert, ist dann auch egal. [ef]grep wird nicht totzukriegen
>> sein.
>
> Die legt man dann halt in /usr/local/bin/ an, wo ist das Problem?

Es gibt viele Skripte, die mit gutem Grund den PATH auf etwas ganz
einfaches wie /bin:/usr/bin setzen.

Seit 1988 verwende ich täglich Unix. Ich habe noch nie ein System
gesehen, auf dem nicht grep, egrep und fgrep im Basispaket mitgeliefert
wurden. Manchmal als separate Binaries, amnchmal als Hardlinks,
neuerdings als Wrapper-Skripte. Inklusive Mini-Systeme mit Busybox.

Ich bin mit Thomas einig: Wenn die Maintainer das abschaffen wollen,
dann sind sie ganz einfach dumme Hornochsen.

- Andi

[Ralph Angenendt]

Well, Andreas Karrer <ak...@gmx.ch> wrote:
> Ich bin mit Thomas einig: Wenn die Maintainer das abschaffen wollen,
> dann sind sie ganz einfach dumme Hornochsen.

Erzähl das den Leuten aus GNUistan:

grep 3.8, NEWS:

The egrep and fgrep commands, which have been deprecated since
release 2.5.3 (2007), now warn that they are obsolescent and should
be replaced by grep -E and grep -F.

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

[Ralph Angenendt]

Well, Andreas Karrer <ak...@gmx.ch> wrote:

> Ich bin mit Thomas einig: Wenn die Maintainer das abschaffen wollen,
> dann sind sie ganz einfach dumme Hornochsen.

[Andreas Karrer]

* Ralph Angenendt <dein...@strg-alt-entf.org>:

> Well, Andreas Karrer <ak...@gmx.ch> wrote:
>> Ich bin mit Thomas einig: Wenn die Maintainer das abschaffen wollen,
>> dann sind sie ganz einfach dumme Hornochsen.
>
> Erzähl das den Leuten aus GNUistan:
>
> grep 3.8, NEWS:
>
> The egrep and fgrep commands, which have been deprecated since
> release 2.5.3 (2007), now warn that they are obsolescent and should
> be replaced by grep -E and grep -F.

Sag ich ja, Hornochsen.

If it ain't broken, don't fix it.

Auf Slashdot hat Jamie Zawinski kommentiert:

Wake me up when grep sends email.



- Andi

[Marcel Mueller]

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

[Thomas Klix]

Ralph Angenendt wrote at Fri, 9 Sep 2022 10:43:51 -0000 (UTC):
> Well, Andreas Karrer <ak...@gmx.ch> wrote:
>> Ich bin mit Thomas einig: Wenn die Maintainer das abschaffen wollen,
>> dann sind sie ganz einfach dumme Hornochsen.
>
> Erzähl das den Leuten aus GNUistan:
>
> grep 3.8, NEWS:
>
> The egrep and fgrep commands, which have been deprecated since
> release 2.5.3 (2007), now warn that they are obsolescent and should
> be replaced by grep -E and grep -F.

Seit 15 Jahren (2007!) als "deprecated" geführt.
Naja, in nochmal 15 Jahren sprechen wir uns wieder. Ich wette, egrep und
fgrep wird es dann immer noch geben.

Thoma

[Marco Moock]

Am Freitag, 09. September 2022, um 21:49:25 Uhr schrieb Thomas Klix:

> Naja, in nochmal 15 Jahren sprechen wir uns wieder. Ich wette, egrep
> und fgrep wird es dann immer noch geben.

Na klar.
Und das Entfernen bringt jetzt auch nicht sooo viele Vorteile, die den
Schaden auch nur ansatzweise rechtfertigen würden.

[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.
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.

[Gerald E¡scher]

Bist du sicher? Bei der Queen hat auch niemand mehr erwartet, dass sie
eines Tages stirbt ;-(

--
Gerald

[Marcel Mueller]

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

[Peter J. Holzer]

On 2022-09-10 09:09, Marcel Mueller <news.5...@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

[Marco Moock]

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.

[Thomas Klix]

s/dauerhaft/tatsächlich/

Thomas

[Marco Moock]

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.

[Helmut Waitzmann]

Marcel Mueller <news.5...@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.

[Bonita Montero]

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;
}

[Thomas Klix]

Helmut Waitzmann wrote at Sat, 10 Sep 2022 23:19:42 +0200:
> [...]

> 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.

busybox!
busybox macht alles!

| BusyBox is a multi-call binary that combines many common Unix
| utilities into a single executable.

ls, grep ... busybox macht das schon. Hardlinked eben.

Thomas

[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.


Marcel

[Bonita Montero]

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

[Gerald E¡scher]

Thomas Klix schrieb am 11/9/2022 15:40:

> Helmut Waitzmann wrote at Sat, 10 Sep 2022 23:19:42 +0200:
>> [...]
>> 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.
>
> busybox!
> busybox macht alles!

Ich wage zu behaupten, das einzige, das man für eine lauffähige
Linuxdistribution benötigt, sind ein Kernel und BusyBox :-)

--
Gerald

[Gerald E¡scher]

Helmut Waitzmann schrieb am 10/9/2022 23:19:

> Andere beliebte Kandidaten für solche Verfahren sind
> «ls»/«ll»/«dir»/«l»,

Aber nicht bei Debian und Ubuntu? Dort kenne ich "ll", "dir" und "l" nur
als Aliases von ln in der .bashrc oder der optionalen .bash_aliases.

--
Gerald

[Marco Moock]

Am Sonntag, 11. September 2022, um 18:08:42 Uhr schrieb Gerald E¡scher:

> Aber nicht bei Debian und Ubuntu? Dort kenne ich "ll", "dir" und "l"
> nur als Aliases von ln in der .bashrc oder der optionalen
> .bash_aliases.

Bei Debian nicht standardmäßig, bei Ubuntu schon. Bei Debian trage ich
die in /etc/profile zusätzlich ein.

[Jens Schüßler]

* Marco Moock <mo...@posteo.de> [11-09-22 18:26]:

----[ cat /etc/skel/.bashrc ]-
| ....
| # enable color support of ls and also add handy aliases
| alias ls='ls --color=auto'
| # some more ls aliases
| #alias ll='ls -l'
| #alias la='ls -A'
| #alias l='ls -CF'
| ...
`----

[Ulli Horlacher]

Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:

> Ich wage zu behaupten, das einzige, das man für eine lauffähige
> Linuxdistribution benötigt, sind ein Kernel und BusyBox :-)

FREVLER!
Und systemd! ;-)

[Ulli Horlacher]

Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:

Was ln nicht alles kann! ;-)

[Ulli Horlacher]

Mit oder ohne subdiretory content?

framstag@juhu:/tmp: ls -l png
total 64
-rw-r--r-- 1 framstag users 51401 Sep 11 21:35 phoon.png
-rw-r--r-- 1 framstag users 11992 Sep 11 09:44 X.png

framstag@juhu:/tmp: ls -ld png
drwxr-xr-x 1 framstag users 28 Sep 11 21:35 png

Beides ist *ARGH*!

SO sollte das funktionieren:

framstag@juhu:/tmp: ll png
drwxr-xr-x framstag users - 2022-09-11 21:35:11 png

framstag@juhu:/tmp: ll png/
-rw-r--r-- framstag users 51,401 2022-09-11 21:35:04 png/phoon.png
-rw-r--r-- framstag users 11,992 2022-09-11 09:44:11 png/X.png

framstag@juhu:/tmp: l png/
-RW- 51,401 2022-09-11 21:35 png/phoon.png
-RW- 11,992 2022-09-11 09:44 png/X.png

User+Group Information brauch ich selten, deshalb reicht mir meistens der
output von "l".

[Gerald E¡scher]

Ulli Horlacher schrieb am 11/9/2022 21:32:

> Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:
>> Helmut Waitzmann schrieb am 10/9/2022 23:19:
>>
>>> Andere beliebte Kandidaten für solche Verfahren sind
>>> «ls»/«ll»/«dir»/«l»,
>>
>> Aber nicht bei Debian und Ubuntu? Dort kenne ich "ll", "dir" und "l" nur
>> als Aliases von ln in der .bashrc oder der optionalen .bash_aliases.
>
> Was ln nicht alles kann! ;-)

Sehr witzig ;-(
Auf meiner Tastatur liegt die [N]-Taste gleich neben der
[S]-Taste!!!!2 [1]


[1] Ahe rvar yäpureyvpur Unaqoervg Nofgnaq.

--
Gerald

[Gerald E¡scher]

Ulli Horlacher schrieb am 11/9/2022 21:31:

> Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:
>
>> Ich wage zu behaupten, das einzige, das man für eine lauffähige
>> Linuxdistribution benötigt, sind ein Kernel und BusyBox :-)
>
> FREVLER!
> Und systemd! ;-)

Beschwer dich bei den Machern von BusyBox, dass die die Zeichen der Zeit
nicht erkennen wollen und noch immer init anstatt systemd einbauen.
Wollen die BusyBox unnötigerweise auf einer Diskette anstatt einer
1-TB-Pestflatte unterbringen?

--
Gerald

[Gerald E¡scher]

Marco Moock schrieb am 11/9/2022 20:26:

> Am Sonntag, 11. September 2022, um 18:08:42 Uhr schrieb Gerald E¡scher:
>
>> Aber nicht bei Debian und Ubuntu? Dort kenne ich "ll", "dir" und "l"
>> nur als Aliases von ln in der .bashrc oder der optionalen
>> .bash_aliases.
>
> Bei Debian nicht standardmäßig, bei Ubuntu schon.

Soweit ich sehe, ist bei beiden die .bashrc (fast) identisch. Bei Debian
sind die Aliases auskommentiert.

> Bei Debian trage ich
> die in /etc/profile zusätzlich ein.

Ich würde eine ~/.bash_aliases anlegen, ~/.bashrc ruft eine existierende
~/.bash_aliases automagisch auf.
Änderungen der Konfigurationsdateien in /etc/ vermeide ich nach
Möglichkeit. Eine Konfigurationsdatei im Home-Verzeichnis wie ~/.profile
kann man einfach auf eine neue Installation mitnehmen, Zeug in /etc/
vergisst man gerne oder muss erst suchen, was man dort alles geändert
hat.

--
Gerald

[Marco Moock]

Am Sonntag, 11. September 2022, um 19:40:15 Uhr schrieb Ulli Horlacher:

> Mit oder ohne subdiretory content?

Bei Ubuntu: alias ll='ls -alF'

[Peter Scholz]

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

[Marc Haber]

Peter Scholz <Peter_...@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

[Ulli Horlacher]

framstag@juhu:/tmp: ls -alF *png
-rw-r--r-- 1 root root 49852 Sep 12 07:56 phoon.png

png:
total 64
drwxr-xr-x 1 framstag users 28 Sep 12 08:57 ./
drwxrwxrwt 1 root root 1304 Sep 12 08:57 ../
-rw-r--r-- 1 framstag users 49852 Sep 12 07:56 phoon.png
-rw-r--r-- 1 framstag users 11992 Sep 6 11:23 X.png

Das ist das, was ich mit ARGHH bezeichnet habe.

Erklaer das Verhalten mal einem Anfaenger!

[Dietz Proepper]

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

> Peter Scholz <Peter_...@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

[Ralph Angenendt]

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?

Ralph

[Thomas Klix]

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

[Thomas Klix]

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

Nochmals Danke.

Thomas

[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.


Marcel

[Gerald E¡scher]

Ulli Horlacher schrieb am 12/9/2022 08:59:

> Marco Moock <mo...@posteo.de> wrote:
>> Am Sonntag, 11. September 2022, um 19:40:15 Uhr schrieb Ulli Horlacher:
>>
>>> Mit oder ohne subdiretory content?
>>
>> Bei Ubuntu: alias ll='ls -alF'
>
> framstag@juhu:/tmp: ls -alF *png
> -rw-r--r-- 1 root root 49852 Sep 12 07:56 phoon.png
>
> png:
> total 64
> drwxr-xr-x 1 framstag users 28 Sep 12 08:57 ./
> drwxrwxrwt 1 root root 1304 Sep 12 08:57 ../
> -rw-r--r-- 1 framstag users 49852 Sep 12 07:56 phoon.png
> -rw-r--r-- 1 framstag users 11992 Sep 6 11:23 X.png
>
> Das ist das, was ich mit ARGHH bezeichnet habe.
>
> Erklaer das Verhalten mal einem Anfaenger!

Bitte erklären, ich kenn mich nicht aus :-)

--
Gerald

[Ulli Horlacher]

Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:

>>> Bei Ubuntu: alias ll='ls -alF'
>>
>> framstag@juhu:/tmp: ls -alF *png
>> -rw-r--r-- 1 root root 49852 Sep 12 07:56 phoon.png
>>
>> png:
>> total 64
>> drwxr-xr-x 1 framstag users 28 Sep 12 08:57 ./
>> drwxrwxrwt 1 root root 1304 Sep 12 08:57 ../
>> -rw-r--r-- 1 framstag users 49852 Sep 12 07:56 phoon.png
>> -rw-r--r-- 1 framstag users 11992 Sep 6 11:23 X.png
>>
>> Das ist das, was ich mit ARGHH bezeichnet habe.
>>
>> Erklaer das Verhalten mal einem Anfaenger!
>
> Bitte erklären, ich kenn mich nicht aus :-)

Komm in meinen Kurs, das dauert laenger :-}

[Ulli Horlacher]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Marco Moock <mo...@posteo.de> wrote:
>> Am Sonntag, 11. September 2022, um 19:40:15 Uhr schrieb Ulli Horlacher:
>>
>>> Mit oder ohne subdiretory content?
>>
>> Bei Ubuntu: alias ll='ls -alF'
>
> framstag@juhu:/tmp: ls -alF *png
> -rw-r--r-- 1 root root 49852 Sep 12 07:56 phoon.png
>
> png:
> total 64
> drwxr-xr-x 1 framstag users 28 Sep 12 08:57 ./
> drwxrwxrwt 1 root root 1304 Sep 12 08:57 ../
> -rw-r--r-- 1 framstag users 49852 Sep 12 07:56 phoon.png
> -rw-r--r-- 1 framstag users 11992 Sep 6 11:23 X.png
>
> Das ist das, was ich mit ARGHH bezeichnet habe.

Deshalb besser so:

framstag@juhu:/tmp: ll *png
drwxr-xr-x framstag users - 2022-09-12 08:57:10 png
-rw-r--r-- root root 49,852 2022-09-12 07:56:07 phoon.png

framstag@juhu:/tmp: ll png/
-rw-r--r-- framstag users 49,852 2022-09-12 07:56:07 png/phoon.png
-rw-r--r-- framstag users 11,992 2022-09-06 11:23:54 png/X.png

Oder:

framstag@juhu:/tmp: ll -R *png
-rw-r--r-- root root 49,852 2022-09-12 07:56:07 phoon.png
drwxr-xr-x framstag users - 2022-09-12 08:57:10 png
-rw-r--r-- framstag users 49,852 2022-09-12 07:56:07 png/phoon.png
-rw-r--r-- framstag users 11,992 2022-09-06 11:23:54 png/X.png

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive?

Ein weiterer (design) bug von ls.

[Marcel Logen]

Andreas Kohlbach in de.comp.os.unix.linux.misc:

>Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive? Es
>gibt auf "sensitive" keine Treffer in der man Page.
>
>Sicher, man könnte die Ausgabe sonst in "grep -i" pipen...

In solchen Fällen greife ich zu

find DIRECTORY -iname '*NAME*'

oder zu

find DIRECTORY -iname '*NAME*' -ls

Marcel 2f3a (81002)
--
╭─╮ ╭────╮ ╭───────────╮ ╭─╮ ╭──╮
─╮ ╭─╯ ╰─╯ ╭─╯ ╰──────╮ ╭─╯ ╭──────────╯ ╰─╮ │ │
╰───╮ ╭─╮ │ ╭─────╯ ╭───────╯ ╰──────╯ ╰──╯ ╰──╮
╰──╯ ╰─╯ ╰─────────╯ 800acd ╰────

[Andreas Karrer]

* Thomas Klix <wot...@web.de>:

> Helmut Waitzmann wrote at Sat, 10 Sep 2022 23:19:42 +0200:
>> [...]
>> 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.
>
> busybox!
> busybox macht alles!
>

>| BusyBox is a multi-call binary that combines many common Unix
>| utilities into a single executable.
>
> ls, grep ... busybox macht das schon. Hardlinked eben.

Neu ist die Methode nicht.

Ultrix (Digital Equipments BSD-Abkömmling) hatte keine Shared
Libraries. Alle Executables waren statisch gelinkt, es gab nichts
anderes.

Dann kam X11, und damit (für die damalige Zeit) grosse Libraries.
Traditionelle Unix-Programme wie cp, ls, mv usw. waren bloss ein par
zig oder wenige hundert kB gross, da spielte das keine Rolle. Aber die
X11-Programme waren alle einige MB gross; auch die kleinsten
X11-Programm wie xeyes, xlogo, xbiff, xclock usw hatten die gesamte
libX11.a reingelinkt. 1989 kam die DECstation 3100 mit dem
MIPS-R3000-Prozessor raus, und deren Objects, Libraries und Binaries
waren deutlich grösser als die VAX-Libraries. Und da Ultrix auch auf
einer DECstation 3100 mit bloss einer 300-MB-Platte laufen sollte,
hatte man ein Problem.

DEC hat das so gelöst, indem sie so ziemlich alles in /usr/bin/X11
zusammen mit einem Wrapper-Programm zu einen einzigen Binary
zusammengelinkt haben. Das Wrapper-Programm wertete argv[0] aus und
rief dann das entsprechende originale X11-Programm als Subroutine auf.
Poor man's shared libraries. Es waren wimre um die 30 hard links, und
so wurden um die 100 MB Plattenplatz eingespart,

- Andi

[Peter J. Holzer]

On 2022-09-12 21:34, Andreas Kohlbach <a...@spamfence.net> wrote:
> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive?

Was sollte das tun?

hp

[Thomas Klix]

Marco Moock wrote at Wed, 7 Sep 2022 21:47:05 +0200:
> 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.
> Ist früher oder später das Entfernen von egrep vorgesehen?

Entwarnung:
| grep (3.8-2) unstable; urgency=low
|
| This Debian grep release removes the deprecation warning about egrep and
| fgrep. These alternative programs will be still shipped by Debian.

Danke. Wirklich.

Thomas

[Marco Moock]

Es haben sich wohl zu viele Leute beschwert.

[Enrik Berkhan]

Andreas Kohlbach <a...@spamfence.net> wrote:
> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive? Es
> gibt auf "sensitive" keine Treffer in der man Page.

Was sollte `ls' damit anfangen?

Die bash kennt 'nocaseglob'. Suchst du sowas?

Gruß,
Enrik

[Marco Moock]

Am Montag, 12. September 2022, um 17:34:15 Uhr schrieb Andreas Kohlbach:

> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive? Es
> gibt auf "sensitive" keine Treffer in der man Page.

Warum keinen Thread aufmachen?
Ich fände die Sache interessant.

[Stefan Froehlich]

On Mon, 12 Sep 2022 23:34:15 Andreas Kohlbach wrote:
> [ls -alF *png]

> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive?
> Es gibt auf "sensitive" keine Treffer in der man Page.

Wie sollte ls das bewerkstelligen können?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan konnte schon immer mehr als Laune machen!
(Sloganizer)

[Ulli Horlacher]

Enrik Berkhan <Enrik....@inka.de> wrote:
> Andreas Kohlbach <a...@spamfence.net> wrote:
>> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive? Es
>> gibt auf "sensitive" keine Treffer in der man Page.
>
> Was sollte `ls' damit anfangen?

Vernuenftig sortieren.

[Ulli Horlacher]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Andreas Kohlbach <a...@spamfence.net> wrote:
>
>> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive?
>
> Ein weiterer (design) bug von ls.

Ich nehms zurueck, ls kann das inzwischen:

framstag@juhu:~: ls| head
48
Ae+P.jpg
aoldau
Askan-von-Schirnding.pdf
Ausweis
backup
BC700_main_g.pdf
Bilder
bin

War mir gar nicht aufgefallen, dass das inzwischen geht.
Ich verwende ls seit vielen Jahren nicht mehr.

Dafuer kann ls immer noch nicht 'directory first'.

[Marco Moock]

Am Dienstag, 13. September 2022, um 06:42:28 Uhr schrieb Ulli Horlacher:

> aoldau

Was ist in dieser Datei drin?

[Ulli Horlacher]

Geht dich nix an :-)

[Tim Landscheidt]

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

>>> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive?

>> Ein weiterer (design) bug von ls.

> Ich nehms zurueck, ls kann das inzwischen:

> framstag@juhu:~: ls| head
> 48
> Ae+P.jpg
> aoldau
> Askan-von-Schirnding.pdf
> Ausweis
> backup
> BC700_main_g.pdf
> Bilder
> bin

> War mir gar nicht aufgefallen, dass das inzwischen geht.
> Ich verwende ls seit vielen Jahren nicht mehr.

> Dafuer kann ls immer noch nicht 'directory first'.

| [tim@vagabond ~]$ ls --version; ls --help | fgrep -A 4 -- --group-directories-first
| ls (GNU coreutils) 8.32
| Copyright © 2020 Free Software Foundation, Inc.
| Lizenz GPLv3+: GNU GPL Version 3 oder höher <https://gnu.org/licenses/gpl.html>.
| Dies ist freie Software: Sie können sie ändern und weitergeben.
| Es gibt keinerlei Garantien, soweit wie es das Gesetz erlaubt.

| Geschrieben von Richard M. Stallman und David MacKenzie.
| --group-directories-first
| Verzeichnisse vor den Dateien gruppieren;
| kann zusammen mit der Option --sort benutzt
| werden, doch --sort=none (-U) schaltet
| Gruppierung ab
| [tim@vagabond ~]$

Tim

[Ulli Horlacher]

Tim Landscheidt <t...@tim-landscheidt.de> wrote:

>> Dafuer kann ls immer noch nicht 'directory first'.
>
> | [tim@vagabond ~]$ ls --version; ls --help | fgrep -A 4 -- --group-directories-first

Ahh.. das kommt davon wenn man nach "directory" statt "directories" sucht

Ok, schon mal besser so.
Weiterhin unbrauchbar ist der output von -R, man will das wie bei find
haben.
Und auch die filesize ist MIST:

framstag@fex:~/tmp: L -Rrs
(...)
./CCCC:
total 5456624
80292 -rw-r--r-- 1 framstag users 82215658 2019-12-30 20:44:16 X11_and_Wayland_A_tale_of_two_implementations.mp4
386792 -rw-r--r-- 1 framstag users 396071186 2019-12-30 20:35:10 Welches_Betriebssystem_hat_der_Bundestag_und_wie_kann_man_es_hacken.mp4

Da muss man erst Stellen abzaehlen um sich nicht in der Groessenordnung zu
vertun.

[Thomas Klix]

Ulli Horlacher wrote at Tue, 13 Sep 2022 09:00:19 +0000 (UTC):
> [ls Output]

> Und auch die filesize ist MIST:
>
> framstag@fex:~/tmp: L -Rrs
> (...)
> ./CCCC:
> total 5456624
> 80292 -rw-r--r-- 1 framstag users 82215658 2019-12-30 20:44:16 X11_and_Wayland_A_tale_of_two_implementations.mp4
> 386792 -rw-r--r-- 1 framstag users 396071186 2019-12-30 20:35:10 Welches_Betriebssystem_hat_der_Bundestag_und_wie_kann_man_es_hacken.mp4
>
> Da muss man erst Stellen abzaehlen um sich nicht in der Groessenordnung zu
> vertun.

Wie lange nutzt du jetzt Linux?
Option -h (human readable) gibt dir die Größen in sinnvollen k-, M- oder
GByte an.

Thomas

[Ulli Horlacher]

Ich will das aber Byte-genau haben!

Also so:

framstag@fex:~/tmp/CCCC: ll
(...)
-rw-r--r-- framstag users 396,071,186 2019-12-30 20:35:10 Welches_Betriebssystem_hat_der_Bundestag_und_wie_kann_man_es_hacken.mp4
-rw-r--r-- framstag users 82,215,658 2019-12-30 20:44:16 X11_and_Wayland_A_tale_of_two_implementations.mp4


Geht doch. Nur eben nicht mit ls.

framstag@fex:~/tmp/CCCC: type ll
ll is /client/bin/ll

[Enrik Berkhan]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Enrik Berkhan <Enrik....@inka.de> wrote:
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive? Es
>>> gibt auf "sensitive" keine Treffer in der man Page.
>>
>> Was sollte `ls' damit anfangen?
>
> Vernuenftig sortieren.

Tut es:

#v+
$ touch a A b B
$ LC_COLLATE=en_US.UTF-8 ls
a A b B
$ LC_COLLATE=C ls
A B a b
a$
#v-

Man muss `ls' eben sagen, was man will.

Gruß,
Enrik

[Thomas Klix]

Ulli Horlacher wrote at Tue, 13 Sep 2022 11:12:30 +0000 (UTC):
> Thomas Klix <wot...@web.de> wrote:
>> Ulli Horlacher wrote at Tue, 13 Sep 2022 09:00:19 +0000 (UTC):
>>> [ls Output]
>>> Und auch die filesize ist MIST:
>>>
>>> framstag@fex:~/tmp: L -Rrs
>>> (...)
>>> ./CCCC:
>>> total 5456624
>>> 80292 -rw-r--r-- 1 framstag users 82215658 2019-12-30 20:44:16 X11_and_Wayland_A_tale_of_two_implementations.mp4
>>> 386792 -rw-r--r-- 1 framstag users 396071186 2019-12-30 20:35:10 Welches_Betriebssystem_hat_der_Bundestag_und_wie_kann_man_es_hacken.mp4
>>>
>>> Da muss man erst Stellen abzaehlen um sich nicht in der Groessenordnung zu
>>> vertun.
>>
>> Wie lange nutzt du jetzt Linux?
>> Option -h (human readable) gibt dir die Größen in sinnvollen k-, M- oder
>> GByte an.
>
> Ich will das aber Byte-genau haben!

Du hast aber auch spezielle Wünsche...
Gut, du kannst ja gut Shell-scripten, dann passt das schon.

Thomas

[Peter Heitzer]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Enrik Berkhan <Enrik....@inka.de> wrote:
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive? Es
>>> gibt auf "sensitive" keine Treffer in der man Page.
>>
>> Was sollte `ls' damit anfangen?

>Vernuenftig sortieren.

Ist das nicht eine Eigenschaft der locale, LC_COLLATE?

Mit LC_COLLATE="en_IE.utf8":
ls -l
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 a
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 A
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 b
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 B

Mit LC_COLLATE="C":
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 A
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 B
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 a
-rw-r--r-- 1 ph ph 0 2022-09-13 13:37 b


--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Tim Landscheidt]

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

>>> Dafuer kann ls immer noch nicht 'directory first'.

>> | [tim@vagabond ~]$ ls --version; ls --help | fgrep -A 4 -- --group-directories-first

> Ahh.. das kommt davon wenn man nach "directory" statt "directories" sucht

> Ok, schon mal besser so.
> Weiterhin unbrauchbar ist der output von -R, man will das wie bei find
> haben.
> Und auch die filesize ist MIST:

> framstag@fex:~/tmp: L -Rrs
> (...)
> ./CCCC:
> total 5456624
> 80292 -rw-r--r-- 1 framstag users 82215658 2019-12-30 20:44:16 X11_and_Wayland_A_tale_of_two_implementations.mp4
> 386792 -rw-r--r-- 1 framstag users 396071186 2019-12-30 20:35:10 Welches_Betriebssystem_hat_der_Bundestag_und_wie_kann_man_es_hacken.mp4

> Da muss man erst Stellen abzaehlen um sich nicht in der Groessenordnung zu
> vertun.

Dafür muss man (bei GNU ls) in die info-Dokumentation von
coreutils schauen, in Gänze unter „Block size“, in Kürze un-
ter ls’ „What information is listed“:

| […]

| ‘-l’
| ‘--format=long’
| ‘--format=verbose’
| In addition to the name of each file, print the file type, file
| mode bits, number of hard links, owner name, group name, size, and
| timestamp (*note Formatting file timestamps::), normally the
| modification timestamp (the mtime, *note File timestamps::). If
| the owner or group name cannot be determined, print the owner or
| group ID instead, right-justified as a cue that it is a number
| rather than a textual name. Print question marks for other
| information that cannot be determined.

| Normally the size is printed as a byte count without punctuation,
| but this can be overridden (*note Block size::). For example, ‘-h’
| prints an abbreviated, human-readable count, and
| ‘--block-size="'1"’ prints a byte count with the thousands
| separator of the current locale.

| […]

(Nein, bis gerade wusste ich das auch nicht.)

Tim

[Ulli Horlacher]

Tim Landscheidt <t...@tim-landscheidt.de> wrote:

>> framstag@fex:~/tmp: L -Rrs
>> (...)
>> ./CCCC:
>> total 5456624
>> 80292 -rw-r--r-- 1 framstag users 82215658 2019-12-30 20:44:16 X11_and_Wayland_A_tale_of_two_implementations.mp4
>> 386792 -rw-r--r-- 1 framstag users 396071186 2019-12-30 20:35:10 Welches_Betriebssystem_hat_der_Bundestag_und_wie_kann_man_es_hacken.mp4
>
>> Da muss man erst Stellen abzaehlen um sich nicht in der Groessenordnung zu
>> vertun.
>
> Dafür muss man (bei GNU ls) in die info-Dokumentation von

> coreutils schauen, in Gänze unter ?Block size?, in Kürze un-
> ter ls? ?What information is listed?:
>
> | [?]
>
> | ?-l?
> | ?--format=long?
> | ?--format=verbose?

> | In addition to the name of each file, print the file type, file
> | mode bits, number of hard links, owner name, group name, size, and
> | timestamp (*note Formatting file timestamps::), normally the
> | modification timestamp (the mtime, *note File timestamps::). If
> | the owner or group name cannot be determined, print the owner or
> | group ID instead, right-justified as a cue that it is a number
> | rather than a textual name. Print question marks for other
> | information that cannot be determined.
>
> | Normally the size is printed as a byte count without punctuation,

> | but this can be overridden (*note Block size::). For example, ?-h?

> | prints an abbreviated, human-readable count, and

> | ?--block-size="'1"? prints a byte count with the thousands

> | separator of the current locale.

Funktioniert bei mir nicht:

framstag@juhu:/tmp: ls -l --block-size=1 *mp3
-rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3

framstag@juhu:/tmp: ls --version
ls (GNU coreutils) 8.28

[Tim Landscheidt]

^^^^^^^^^^^^^^^^^

>> | separator of the current locale.

> Funktioniert bei mir nicht:

> framstag@juhu:/tmp: ls -l --block-size=1 *mp3
> -rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3

> framstag@juhu:/tmp: ls --version
> ls (GNU coreutils) 8.28

Die Option muss „'1“ bekommen, das heißt,
„--block-size="'1"“ oder „--block-size=\'1“ oder …

Tim

[Jens Schüßler]

* Ulli Horlacher <fram...@rus.uni-stuttgart.de> [13-09-22 18:19]:

> Tim Landscheidt <t...@tim-landscheidt.de> wrote:
>
>>
>> | Normally the size is printed as a byte count without punctuation,
>> | but this can be overridden (*note Block size::). For example, ?-h?
>> | prints an abbreviated, human-readable count, and
>> | ?--block-size="'1"? prints a byte count with the thousands
>> | separator of the current locale.
>
> Funktioniert bei mir nicht:
>
> framstag@juhu:/tmp: ls -l --block-size=1 *mp3
> -rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3

Genauer lesen hilft:
s/--block-size=1/--block-size="'1"/

[Ulli Horlacher]

Tim Landscheidt <t...@tim-landscheidt.de> wrote:

>>> | Normally the size is printed as a byte count without punctuation,
>>> | but this can be overridden (*note Block size::). For example, ?-h?
>>> | prints an abbreviated, human-readable count, and
>>> | ?--block-size="'1"? prints a byte count with the thousands
> ^^^^^^^^^^^^^^^^^
>>> | separator of the current locale.
>
>> Funktioniert bei mir nicht:
>
>> framstag@juhu:/tmp: ls -l --block-size=1 *mp3
>> -rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3
>
>> framstag@juhu:/tmp: ls --version
>> ls (GNU coreutils) 8.28
>

> Die Option muss ?'1? bekommen, das heißt,
> ?--block-size="'1"? oder ?--block-size=\'1? oder ?

ARGH! Das ist ja gruslig! Wer kommt denn auf SOWAS?!

Ok, ja, damit funktionierts.

Bescheuert ists trotzdem :-)

[Tim Landscheidt]

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

>>>> | Normally the size is printed as a byte count without punctuation,
>>>> | but this can be overridden (*note Block size::). For example, ?-h?
>>>> | prints an abbreviated, human-readable count, and
>>>> | ?--block-size="'1"? prints a byte count with the thousands
>> ^^^^^^^^^^^^^^^^^
>>>> | separator of the current locale.

>>> Funktioniert bei mir nicht:

>>> framstag@juhu:/tmp: ls -l --block-size=1 *mp3
>>> -rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3

>>> framstag@juhu:/tmp: ls --version
>>> ls (GNU coreutils) 8.28

>> Die Option muss ?'1? bekommen, das heißt,
>> ?--block-size="'1"? oder ?--block-size=\'1? oder ?

> ARGH! Das ist ja gruslig! Wer kommt denn auf SOWAS?!

> Ok, ja, damit funktionierts.

> Bescheuert ists trotzdem :-)

Wahrscheinlich ist es inspiriert von printf(3)s „'“-Flag.

Tim

[Andreas Karrer]

* Andreas Kohlbach <a...@spamfence.net>:

> Mein Fehler. Ich meinte "case sensitive".

Was sollte das tun?

- Andi

[Andreas Karrer]

* Andreas Kohlbach <a...@spamfence.net>:

> On Tue, 13 Sep 2022 06:42:28 +0000 (UTC), Ulli Horlacher wrote:
>>
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>>
>>>> Ohne einen neues Thread aufzumachen: kennt "ls" case insensitive?
>>>
>>> Ein weiterer (design) bug von ls.
>>
>> Ich nehms zurueck, ls kann das inzwischen:
>>
>> framstag@juhu:~: ls| head
>> 48
>> Ae+P.jpg
>> aoldau
>> Askan-von-Schirnding.pdf
>> Ausweis
>> backup
>> BC700_main_g.pdf
>> Bilder
>> bin
>>
>> War mir gar nicht aufgefallen, dass das inzwischen geht.
>

> Ich meinte "case sensitive", sorry. Also an Deinem Verzeichnis
>
> ls -IRGENDWAS a*
>
> sollte nur
>
> aoldau
>
> ausgeben, nicht aber was mit "A" anfängt.

Das hat nichts mit ls zu tun. Denn die Wildcard a* wird von der Shell
aufgelöst, bevor ls überhaupt aufgerufen wird.

Vermutlich verwendest du bash und du hast irgendwo in .bashrc oder so

shopt -s nocaseglob

gesetzt.

- Andi

[Bonita Montero]

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].

[Marc Haber]

Andreas Kohlbach <a...@spamfence.net> wrote:
>Ich muss mir mal verschiedene Farben für die Prompts der verschiedenen
>Rechner einfallen lassen.

Du hast eindeutig nur wenige Rechner ;-)

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

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

> Ich meinte "case sensitive", sorry. Also an Deinem Verzeichnis
>
> ls -IRGENDWAS a*
>
> sollte nur
>
> aoldau
>
> ausgeben, nicht aber was mit "A" anfängt.

Das tut es doch. ls weiss gar nicht, dass du "a*" eingegeben hast, es
sieht nur -IRGENDWAS aoldau als Argumente.

>> Ich verwende ls seit vielen Jahren nicht mehr.
>

> Was dann?

Hatte ich schon geschrieben:

https://fex.belwue.de/fstools/#l

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

> Apropos Prompt-Farbe: Ist die .bash_profile der beste Ort zu ihrer Definition?

Du meinst PS1?
Du kannst Environment Variablen in .bash_profile setzen.

[Ulli Horlacher]

Andreas Karrer <ak...@gmx.ch> wrote:

> Vermutlich verwendest du bash und du hast irgendwo in .bashrc oder so
>
> shopt -s nocaseglob

Das kannte ich noch gar nicht.
Das halte ich fuer recht gefaehrlich, da kommen dann u.U. ganz seltsame
Ergebnisse heraus, die man bestimmt nicht haben will.

[Enrik Berkhan]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Andreas Karrer <ak...@gmx.ch> wrote:
>
>> Vermutlich verwendest du bash und du hast irgendwo in .bashrc oder so
>>
>> shopt -s nocaseglob
>
> Das kannte ich noch gar nicht.
> Das halte ich fuer recht gefaehrlich, da kommen dann u.U. ganz seltsame
> Ergebnisse heraus, die man bestimmt nicht haben will.

Ich würde es wenn überhaupt auf jeden Fall nur interaktiv verwenden
wollen.

Gruß,
Enrik

[Dietz Proepper]

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

> Tim Landscheidt <t...@tim-landscheidt.de> wrote:
>
> >>> | Normally the size is printed as a byte count without
> >>> | punctuation, but this can be overridden (*note Block size::).
> >>> | For example, ?-h? prints an abbreviated, human-readable count,
> >>> | and ?--block-size="'1"? prints a byte count with the thousands
> > ^^^^^^^^^^^^^^^^^
> >>> | separator of the current locale.
> >
> >> Funktioniert bei mir nicht:
> >
> >> framstag@juhu:/tmp: ls -l --block-size=1 *mp3
> >> -rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3
> >
> >> framstag@juhu:/tmp: ls --version
> >> ls (GNU coreutils) 8.28
> >
> > Die Option muss ?'1? bekommen, das heißt,
> > ?--block-size="'1"? oder ?--block-size=\'1? oder ?
>
> ARGH! Das ist ja gruslig! Wer kommt denn auf SOWAS?!
>
> Ok, ja, damit funktionierts.
>
> Bescheuert ists trotzdem :-)

Ich habe mir abgewöhnt, bei den GNU-Varianten davon auszugehen, dass
sie *irgendwas* nicht können ;-).

Und häufig Syntaxen haben, die von meinen Idealen abweichen.

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

[Ulli Horlacher]

Enrik Berkhan <Enrik....@inka.de> wrote:

>>> shopt -s nocaseglob

>>
>> Das halte ich fuer recht gefaehrlich, da kommen dann u.U. ganz seltsame
>> Ergebnisse heraus, die man bestimmt nicht haben will.
>
> Ich würde es wenn überhaupt auf jeden Fall nur interaktiv verwenden
> wollen.

framstag@fex:/sw/share/fstools-0.0/env: l B*
l: cannot access 'B*' - No such file or directory

framstag@fex:/sw/share/fstools-0.0/env: caseglob
nocaseglob on

framstag@fex:/sw/share/fstools-0.0/env: l B*
-RW- 5,257 2022-09-14 11:54 bashrc

framstag@fex:/sw/share/fstools-0.0/env: caseglob
nocaseglob off

framstag@fex:/sw/share/fstools-0.0/env: type caseglob
caseglob is a function
caseglob ()
{
if shopt nocaseglob | grep -q off; then
shopt -s nocaseglob;
else
shopt -u nocaseglob;
fi;
shopt nocaseglob

[Tim Landscheidt]

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

>>>> shopt -s nocaseglob

>>> Das halte ich fuer recht gefaehrlich, da kommen dann u.U. ganz seltsame
>>> Ergebnisse heraus, die man bestimmt nicht haben will.

>> Ich würde es wenn überhaupt auf jeden Fall nur interaktiv verwenden
>> wollen.

> framstag@fex:/sw/share/fstools-0.0/env: l B*
> l: cannot access 'B*' - No such file or directory

> framstag@fex:/sw/share/fstools-0.0/env: caseglob
> nocaseglob on

> framstag@fex:/sw/share/fstools-0.0/env: l B*
> -RW- 5,257 2022-09-14 11:54 bashrc

> framstag@fex:/sw/share/fstools-0.0/env: caseglob
> nocaseglob off

> framstag@fex:/sw/share/fstools-0.0/env: type caseglob
> caseglob is a function
> caseglob ()
> {
> if shopt nocaseglob | grep -q off; then

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> shopt -s nocaseglob;
> else
> shopt -u nocaseglob;
> fi;
> shopt nocaseglob
> }

Mir war langweilig: Das sollte sich durch „! shopt -q
nocaseglob“ ersetzen lassen.

Tim

[Patrick Rudin]

Marco Moock wrote:
> Es haben sich wohl zu viele Leute beschwert.

Angesichts dieses Monsterthreads fragt man sich schon, ob man nicht
durch ein simples Suchen/Ersetzen die betroffenen Skripte einfach hätte
anpassen können...


Gruss

Patrick

[Marco Moock]

Am Mittwoch, 14. September 2022, um 13:13:03 Uhr schrieb Patrick Rudin:

> Angesichts dieses Monsterthreads fragt man sich schon, ob man nicht
> durch ein simples Suchen/Ersetzen die betroffenen Skripte einfach
> hätte anpassen können...

Keine Chance, da auch Skripte Dritter betroffen sind, die mit Debian
nichts zu tun haben.

[Peter J. Holzer]

On 2022-09-14 00:37, Andreas Kohlbach <a...@spamfence.net> wrote:

> Wenn in einem Verzeichnis beispielsweise
>
> Andi
> andi
>
> ist. Dann sollte
>
> ls -IRGENDWAS a*
>
> nur "andi" ausgeben.

Bei mir[1] passiert das. Wenn bei Dir Andi und andi ausgegeben werden, dann
hast Du vermutlich:
1) eine Shell, die die Collation (LC_COLLATE) berücksichtigt und
2) eine Collation, die case-insensitiv ist.

> Diese Funktion scheint ls selbst aber nicht zu besitzen. Kann man ja
> mal brauchen... :-)
>
> Das mit dem Shell-Globbing und grep wurde ja schon genannt. Wäre halt
> schön gewesen, wenn ls das selbst könnte.

Das macht aber eben die Shell. Wenn Du
ls -IRGENDWAS a*
eintippst, wird
"ls" "-IRGENDWAS" "andi"
aufgerufen, und ls hat keinen Anhaltspunkt, dass Du etwas anderes als
"andi" sehen wolltest.

hp

[1] Ubuntu 22.04, zsh 5.8.1, LC_COLLATE=POSIX (LC_COLLATE=en_US.UTF-8
ändert aber auch nichts)

[Peter J. Holzer]

On 2022-09-14 07:15, Marc Haber <mh+usene...@zugschl.us> wrote:
> Andreas Kohlbach <a...@spamfence.net> wrote:
>>Ich muss mir mal verschiedene Farben für die Prompts der verschiedenen
>>Rechner einfallen lassen.
>
> Du hast eindeutig nur wenige Rechner ;-)

Bei mir sinds ein paar Dutzend (und typischerweise auf jedem mehrere
Accounts).

Ich lasse mir die Hintergrundfarbe des Terminals beim ersten Einloggen
zufällig setzen (wenn die gar zu grauslich ist, kann ich sie noch
ändern). In den meisten Fällen führt das dazu, dass ich nicht zwei
Terminals mit verschiedenen Accounts auch erkennbar unterschiedliche
Farben haben. Und bei Accounts, die ich häufig verwende, ist mir die
Farbe soweit ins Unterbewusstsein eingesickert, dass mit (meistens)
auffällt, wenn ich im falschen Fenster bin.

hp

[Rupert Haselbeck]

Patrick Rudin schrieb:

Derlei "Probleme" gab es auch vor zwanzig oder dreißig Jahren schon
(z.B. beim Umstieg/Upgrade von SINIX 5.40/5.41 zu Pyramid Unix 5.45) bei
dem ein oder anderen Progrämmchen. Aber statt darum einen Glaubenskrieg
anzuzetteln hat man derlei Probleme damals einfach mit ein paar Zeilen
zu Pfadanpassungen oder (Hard)Links umschifft, welche anhand einer
schriftlichen Installationsanleitung abzuarbeiten waren oder,
komfortabler, nach erfolgter Systeminstallation per Skript
drübergebügelt wurden.
Wenn Skripte aus unterschiedlichen Quellen zum Einsatz kommen sollen, so
ist es wünschenswert, wenn diese sämtlich ohne Anpassungen auf einem
neuen System lauffähig sind. Man passt also im Zweifel lieber einmal das
BS an statt jedes einzelne einer mehr oder minder großen Zahl von
Skripten, gar dann, wenn es sich lediglich um derart einfache Dinge wie
einen Einzeiler zum Aufruf von grep als fgrep oder egrep bei gleicher
Syntax handelt. (Natürlich wird aber auch das nicht uferlos und bis in
alle Ewigkeit funktionieren können...)
Allerdings war "damals" der Kreis derjenigen, welche sich mit derlei
Fragen beschäftigen konnten/mussten, /deutlich/ kleiner als er das heute
ist. Und der Kenntnisstand dieses eher kleinen Kreises könnte
durchschnittlich höher gewesen sein, so dass für die auf der Hand
liegende Inkompatibilität nach der ersten Fehlermeldung "xyz not found"
rasch eine Lösung bzw. ein Workaround zu finden war.

MfG
Rupert

[Peter J. Holzer]

On 2022-09-14 18:00, Rupert Haselbeck <mein-re...@gmx.de> wrote:
> Patrick Rudin schrieb:
>> Marco Moock wrote:
>>> Es haben sich wohl zu viele Leute beschwert.
>>
>> Angesichts dieses Monsterthreads fragt man sich schon, ob man nicht
>> durch ein simples Suchen/Ersetzen die betroffenen Skripte einfach hätte
>> anpassen können...
>
> Derlei "Probleme" gab es auch vor zwanzig oder dreißig Jahren schon
> (z.B. beim Umstieg/Upgrade von SINIX 5.40/5.41 zu Pyramid Unix 5.45) bei
> dem ein oder anderen Progrämmchen.

Es gibt natürlich Unterschiede zwischen verschiedenen Betriebssystemen,
auch wenn alle POSIX-kompatibel zu sein behaupten. Etliche meine alten
Scripts haben Varianten für HP-UX und Linux (und manche vielleicht noch
für Solaris, OSF/1, Ultrix, ...).

Aber egrep und fgrep gehören für mich zum Unix-Kanon. Jedes Unix, das
ich jemals verwendet habe, hatte diese Kommandos (gerade nachgeschaut:
auch PC/IX). Ein System ohne diese Kommandos ist für mich kein Unix. Ja,
natürlich kann man sie ersetzen. Man kann jedes Kommando ersetzen.
Interaktiv verwende ich meistens ag statt grep. Jemand hat hierzugroups
erwähnt, dass er ls kaum mehr verwendet. Wahrscheinlich gibt es für
jedes "Standard"-Unix-Kommando einen (besseren?) Ersatz. Aber es ist
eben dieser Standard-Werkzeugkasten, auf dessen Vorhandensein man sich
weitgehend verlassen kann, der Unix zu Unix macht. Und der deckt sich
(zumindest für mich) nicht unbedingt 100%ig mit dem POSIX-Standard: Da
stehen halt manche Sachen nicht drin, die ich sehr wohl erwarte, und
vielleicht gibt es einige, auf die ich mich nicht verlassen würde (und
zu Zeiten, als ich noch regelmäßig mit verschiedenen Unixen gearbeitet
habe, war diese Vorsicht auch gerechtfertigt).

Das heißt nicht immer, dass unbedingt alles per default installiert sein
muss. Ich habe es einmal geschafft, eine minimale Installation von
Redhat (weiß nicht mehr, ob das noch Redhat "classic" oder oder schon
RHEL war) hinzubekommen, bei der es kein grep gab. Hat mich etwas
irritiert, aber "minimal" heißt eben nicht vollständig, und ich habe das
RPM halt nachinstalliert - kein Malheur.

hp

[Claus Reibenstein]

Jens Schüßler schrieb am 13.09.2022 um 21:44:

> * Ulli Horlacher <fram...@rus.uni-stuttgart.de> [13-09-22 18:19]:
>

>> framstag@juhu:/tmp: ls -l --block-size=1 *mp3
>> -rw-r--r-- 1 framstag users 4194317 Sep 13 09:15 swr1.mp3
>
> Genauer lesen hilft:
> s/--block-size=1/--block-size="'1"/

Das kannte ich auch noch nicht. Was es alles gibt...

Gruß
Claus

[Christian Garbs]

Mahlzeit!

Andreas Kohlbach <a...@spamfence.net> wrote:

> On Wed, 14 Sep 2022 17:31:32 +0200, Peter J. Holzer wrote:

>> Ich lasse mir die Hintergrundfarbe des Terminals beim ersten Einloggen
>> zufällig setzen (wenn die gar zu grauslich ist, kann ich sie noch
>> ändern).
>

> Interessanter Ansatz. Es scheint PURPLE, CYAN und so zu kennen. Hast Du
> die in einer Tabelle, aus der dann ein Zeile zufällig gewählt wird?

Ich (nicht Peter) mache das vom Rechnernamen abhängig (meine
Skriptsammlung clone ich auf alle Systeme, auf denen ich aktiv bin),
färbe aber nur den Hostnamen innerhalb des Prompts. Die üblichen 16
Farben (bzw. 8 für den Hintergrund) waren mir zu wenig, ich habe das
auf 256-Farben-Modus getrimmt:

https://github.com/mmitch/mitchscripts/blob/ba2ba80df3cc9a8f53459ba6e1aaf7c1292a0390/config/.bashrc#L38-L83

Du solltest vermutlich irgendwie eine handverlesene Liste an
Farbkombinationen pflegen (sonst siehst Du evtl. nichts), aber da
könntest Du dann entweder mit $RANDOM rangehen oder du mappst
irgendwie den Rechnernamen auf die Länge Deiner Liste – im einfachsten
Fall Quersumme der Ascii-Werte module Länge, aber das ist nicht
gleichverteilt, da sollten die Kryptographen ran ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
Misstrauensvotum gegen den lieben Gott. (Karl Krauss)

[Peter J. Holzer]

On 2022-09-14 23:48, Andreas Kohlbach <a...@spamfence.net> wrote:
> On Wed, 14 Sep 2022 17:31:32 +0200, Peter J. Holzer wrote:

>> Ich lasse mir die Hintergrundfarbe des Terminals beim ersten Einloggen
>> zufällig setzen (wenn die gar zu grauslich ist, kann ich sie noch
>> ändern).
>

> Interessanter Ansatz. Es scheint PURPLE, CYAN und so zu kennen. Hast Du
> die in einer Tabelle, aus der dann ein Zeile zufällig gewählt wird?

Nein, die drei RGB-Komponenten werden in einem bestimmten Bereich
zufällig gewählt:

#v+
if [[ $TERM = xterm || $TERM = xterm-256color ]]
then
if [ -f ~/.zxtermcolors ]
then
. ~/.zxtermcolors
else
perl -e 'printf(qq{if whence xtermcontrol >/dev/null\nthen\nxtermcontrol --bg "#%02X%02X%02X" --fg "#CCCCCC"\nexport BG=dark\nfi\n}, map { rand(128) } qw(1 1 1))' > ~/.zxtermcolors
fi
fi
#v-

Theoretisch ergibt das ca. 2 Millionen mögliche Hintergrundfarben, das
sollte für die absehbare Zukunft reichen, auch wenn ich gelegentlich
eine Farbe wegen akuter Augenkrebsgefahr ändern muss.

hp

[Christian Garbs]

Mahlzeit!

Peter J. Holzer <hjp-u...@hjp.at> wrote:

> perl -e 'printf(qq{if whence xtermcontrol >/dev/null\nthen\nxtermcontrol --bg "#%02X%02X%02X" --fg "#CCCCCC"\nexport BG=dark\nfi\n}, map { rand(128) } qw(1 1 1))' > ~/.zxtermcolors

Falls Du bash (oder irgendwas anderes mit $RANDOM) benutzt, kämst Du
ohne Perl aus:

#v+
if command -v xtermcontrol >/dev/null; do
xtermcontrol --bg $(printf "#%02x%02x%02x" $((RANDOM % 128)) $((RANDOM % 128)) $((RANDOM % 128))) --fg "#CCCCCC"
export BG=dark
done
#v-

Dann kann es vielleicht auch in der ~/.bashrc stehen, statt an die
~/.zxtermcolors angehängt zu werden.

Da $RANDOM bis 32767 geht, machen wir bei dem modulo 128 die
Gleichverteilung der Zufallszahlen nicht kaputt ;-)

Und woher gibt's whence, das klingt so fancy?

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Never test for an error condition you don't know how to handle.
-- Steinbach