Debian PATH für normale User nicht wie in /etc/profile

[Marco Moock]

Hallo zusammen,

ich habe ein Debian neu aufgesetzt und $PATH ist bei meinem User
/usr/local/bin:/usr/bin:/bin:/usr/games
statt
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
was ich in /etc/profile festgelegt habe (ich habe die if-Verzweigung
entfernt und nur eine Zeile mit allen Orten gelassen).

Warum wird das nicht übernommen bzw. vom was wird es überschrieben?

~/.profile sieht ok aus:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi

--
Gruß
Marco

[Ulli Horlacher]

Marco Moock <mo...@posteo.de> wrote:
> Hallo zusammen,
>
> ich habe ein Debian neu aufgesetzt und $PATH ist bei meinem User
> /usr/local/bin:/usr/bin:/bin:/usr/games
> statt
> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
> was ich in /etc/profile festgelegt habe (ich habe die if-Verzweigung
> entfernt und nur eine Zeile mit allen Orten gelassen).
>
> Warum wird das nicht übernommen bzw. vom was wird es überschrieben?

Guck mal in /etc/profile.d/

> ~/.profile sieht ok aus:

Gibts ~/.bash_profile ?
Wird in ~/.bashrc noch ueberfluessigerweise PATH veraendert?


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

[Marco Moock]

Am Mon, 3 Oct 2022 07:55:00 +0000 (UTC)
schrieb Ulli Horlacher <fram...@rus.uni-stuttgart.de>:

> Guck mal in /etc/profile.d/

Nix Passendes drin.

> > ~/.profile sieht ok aus:
>
> Gibts ~/.bash_profile ?

Nein.

> Wird in ~/.bashrc noch ueberfluessigerweise PATH veraendert?

Nein.

[Lutz Falke]

Rant loading: [################....]

Dieses Problem hat mich auch schon einiges an Nerven gekostet.
Wahrscheinliche Lösung ganz unten.

Marco Moock schrieb:

> ich habe ein Debian neu aufgesetzt und $PATH ist bei meinem User
> /usr/local/bin:/usr/bin:/bin:/usr/games
> statt
> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
> was ich in /etc/profile festgelegt habe (ich habe die if-Verzweigung
> entfernt und nur eine Zeile mit allen Orten gelassen).
>
> Warum wird das nicht übernommen bzw. vom was wird es überschrieben?

Kommt drauf an. Da müsstest du noch verraten, in welcher Umgebung das
nicht funktioniert. Beim Login auf der nackten (virtuellen) Textkonsole
oder per SSH müsste das eigentlich so funktionieren. Praktisch überall
da, wo das Login über einen einfachen login(1) Prozess läuft.

Das Environment kann auch noch mittels PAM (mit dem Modul pam_env)
verändert werden. Das dürfte aber hier keine Rolle spielen. Zum einen
ist das AFAIK in einem reinen Debian nicht aktiv, das müsste man
selbst konfigurieren. Und dann wirkt das auch bevor die *Login*-Shell
(dazu kommt gleich noch was) ihre Startup-Dateien auswertet. Ein
Setzen von PATH in /etc/profile würde das also ggf. Übersteuern.

> ~/.profile sieht ok aus:
>
> # set PATH so it includes user's private bin if it exists
> if [ -d "$HOME/bin" ] ; then
> PATH="$HOME/bin:$PATH"
> fi
>
> # set PATH so it includes user's private bin if it exists
> if [ -d "$HOME/.local/bin" ] ; then
> PATH="$HOME/.local/bin:$PATH"
> fi

Meine Kristallkugel sagt noch was von einer X-Session und bash.

Wenn du in deiner X-Sitzung ein xterm o.Ä. startest, läuft darin
normalerweise *keine* Login-Shell, sondern eine normale interaktive
Shell. Die erbt die Umgebung aus der sie aufgerufen wurde. Die bash
wertet dabei nur die bashrc-Dateien, nicht die profile-Dateien aus.
Du bekommst dann den gleichen PATH, der für die restliche
Desktop-Umgebung auch gilt. Das ist die Umgebung, die der
Display-Manager nach dem Login für die Session hinterlassen hat.
(Meine Kristallkugel geht davon aus, dass du einen verwendest.)

Und hier kommt jetzt der WTF-Moment: Praktisch alle Display-Manager
pfuschen hinterrücks an der PATH-Umgebungsvariable rum. D.h. egal, was
der Administrator in /etc/login.defs[1] oder z.B. per pam_env[2]
vorgibt ist wirkungslos, da der Elefant im Porzellanladen alles wieder
einreißt.

Bei lightdm ist das hart im Quellcode codiert und nicht
konfigurierbar. Bei xdm ist der gesetzte Pfad über die X-Ressource
"DisplayManager*userPath" einstellbar[3].

Das ist IMNSHO der vollkommen Falsche Ort, um so eine Änderung am
Environment zu machen.

aus xdm(1):
| DisplayManager.DISPLAY.userPath
| Xdm sets the PATH environment variable for the session to this
| value. It should be a colon separated list of directories; see
| sh(1) for a full description. The default value is
| "/usr/local/bin:/usr/bin:/bin:/usr/games".

Die Dokumentation von lightdm erwähnt das Verhalten nicht. Bei den
anderen Verdächtigen habe ich jetzt nicht nochmal nachgesehen.


Die sinnvollste Möglichkeit, den PATH für die gesamte X-Session zu
setzen, scheint mir am Ende einfach der letzte zu sein, der am Pfad
rumfummelt. Damit hat man dann unter allen Umständen, wo eine Shell
gestartet wird oder z.B. in Sachen wie dem "Application Finder" den
gewünschten Pfad gesetzt.

Erreichen kann man das über die Xsession(5)-Mechanismen.
Vorausgesetzt, der DM startet nach dem Login die Session so.
Entweder unter /etc/etc/X11/Xsession.d/ in der Reihung vor
"99x11-common_start" einen Skriptschnipsel anlegen, der den PATH setzt
oder den PATH unter ~/.xsessionrc setzen. Die Datei wird dann während
des Starts bzw. der Vorbereitung des Starts der
Desktop-Umgebung/XSession gesourct. Danach fummelt hoffentlich keines
der Skripte nochmal am PATH rum.

aus Xsession(5):
| /etc/X11/Xsession.d/40x11-common_xsessionrc
| Source global environment variables. This script will source
| anything in $HOME/.xsessionrc if the file is present. This
| allows the user to set global environment variables for their
| X session, such as locale information.

HTH,
Lutz

[1] Das ist der historische Ort, um die PATH-Vorgabe zu ändern;
Option ENV_PATH
[2] Die modernere, flexiblere Variante. Liest normalerweise aus
/etc/environment
[3] in /etc/X11/xdm/xdm-config

[Marco Moock]

Am Mon, 3 Oct 2022 12:29:40 -0000 (UTC)
schrieb Lutz Falke <lutz...@gmx.de>:

> Die sinnvollste Möglichkeit, den PATH für die gesamte X-Session zu
> setzen, scheint mir am Ende einfach der letzte zu sein, der am Pfad
> rumfummelt. Damit hat man dann unter allen Umständen, wo eine Shell
> gestartet wird oder z.B. in Sachen wie dem "Application Finder" den
> gewünschten Pfad gesetzt.

Ich habe es jetzt über ~/.xsessionrc gemacht.

[Helmut Waitzmann]

Lutz Falke <lutz...@gmx.de>:

> Rant loading: [################....]
>

Du sprichst mir aus der Seele.

> Dieses Problem hat mich auch schon einiges an Nerven gekostet.
> Wahrscheinliche Lösung ganz unten.
>
> Marco Moock schrieb:
>
>> ich habe ein Debian neu aufgesetzt und $PATH ist bei meinem User
>> /usr/local/bin:/usr/bin:/bin:/usr/games
>> statt
>> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
>> was ich in /etc/profile festgelegt habe (ich habe die
>> if-Verzweigung entfernt und nur eine Zeile mit allen Orten
>> gelassen).
>>
>> Warum wird das nicht übernommen bzw. vom was wird es
>> überschrieben?
>
> Kommt drauf an. Da müsstest du noch verraten, in welcher
> Umgebung das nicht funktioniert. Beim Login auf der nackten
> (virtuellen) Textkonsole oder per SSH müsste das eigentlich so
> funktionieren. Praktisch überall da, wo das Login über einen
> einfachen login(1) Prozess läuft.

Genauer:  Es funktioniert überall dort, wo ein Shell als
Login‐Shell gestartet wird.  Das muss nicht mit dem Programm
«login» sein.  Die Bezeichnung «Login‐Shell» rührt natürlich
daher, dass Shells beim Login an einer Textkonsole auf diese
spezielle Weise gestartet werden.  Siehe beispielsweise in der
Handbuchseite «bash(1)» den Satz «This is what login(1) does.»

Ein Shell wird immer dann als Login‐Shell gestartet, wenn das
erste Element im «argv[]»‐Vektor‐Parameter des Systemaufrufs
«execve» (siehe die Handbuchseite «execve(2)»), also das Element
«argv[0]», mit einem Minuszeichen beginnt.

Normalerweise ist es bei der Verwendung des Systemaufrufs
«execve» Konvention, dass das Vektor‐Element «argv[0]» der
letzten Pfadkomponente des Pfades, der im Parameter «filename»
übergeben wird, entspricht.

Eine Ausnahme davon ist das Programm «login»:  Es ändert diese
Konvention insofern ab, als es dem der Konvention entsprechenden
Wert, der in «argv[0]» hineinkommt, noch ein Minuszeichen
voranstellt.  («su», aufgerufen mit «-» als dem ersten Parameter
nach eventuell vorhandenen Aufrufoptionen, tut ähnliches.)

Beispiele:

Starte einen «bash» als Nicht‐Login‐Shell:


execve("/bin/bash", {"bash", 0}, environ)


Starte einen «bash» als Login‐Shell:


execve("/bin/bash", {"-bash", 0}, environ)

>> ~/.profile sieht ok aus:
>>
>>
>> # set PATH so it includes user's private bin if it exists
>> if [ -d "$HOME/bin" ] ; then
>> PATH="$HOME/bin:$PATH"
>> fi
>>
>> # set PATH so it includes user's private bin if it exists
>> if [ -d "$HOME/.local/bin" ] ; then
>> PATH="$HOME/.local/bin:$PATH"
>> fi
>
> Meine Kristallkugel sagt noch was von einer X-Session und bash.
>

Ja, genau.  Da wäre es interessant, zu wissen, ob die X‐Sitzung
einen (nicht‐interaktiven) Login‐Shell oder Nicht‐Login‐Shell
startet, der schließlich «/etc/X11/Xsession» starten könnte.

Marco, wenn du dich grafisch einloggst und dann mit dem Kommando


ps -u "$LOGNAME" -o ppid -o sid -o pgid -o pid \
-o ruser -o args --forest

deine Prozesse anzeigen lässest, siehst du dann irgendwo einen
Login‐Shell, etwa einen Login‐«bash», bei dem in der mit «args»
bezeichneten Spalte beispielsweise «-bash» steht?

> Und hier kommt jetzt der WTF-Moment: Praktisch alle
> Display-Manager pfuschen hinterrücks an der
> PATH-Umgebungsvariable rum. D.h. egal, was der Administrator in
> /etc/login.defs[1] oder z.B. per pam_env[2] vorgibt ist
> wirkungslos, da der Elefant im Porzellanladen alles wieder
> einreißt.
>
> Bei lightdm ist das hart im Quellcode codiert und nicht
> konfigurierbar.

Das ist übel und völlig inakzeptabel.  Damit wäre «lightdm» bei
mir als Administrator durchgefallen.

> Bei xdm ist der gesetzte Pfad über die X-Ressource
> "DisplayManager*userPath" einstellbar[3].
>
> Das ist IMNSHO der vollkommen Falsche Ort, um so eine Änderung am
> Environment zu machen.

Genau.  Denn mit X11‐Resources hat der PATH ja wirklich überhaupt
nichts zu tun.

> Die sinnvollste Möglichkeit, den PATH für die gesamte X-Session zu
> setzen, scheint mir am Ende einfach der letzte zu sein, der am Pfad
> rumfummelt. Damit hat man dann unter allen Umständen, wo eine Shell
> gestartet wird oder z.B. in Sachen wie dem "Application Finder" den
> gewünschten Pfad gesetzt.

Im Prinzip stimme ich zu, möchte es aber etwas einschränken:  In
einem gut konfigurierten System sollte es für den Anwender nicht
nötig sein, in den Konfigurationsdateien in seinem
HOME‐Verzeichnis noch die vom Systemadministrator schlecht
gemachten Hausaufgaben zu korrigieren.

In diesem Fall meine ich damit, dass es nicht die Aufgabe des
Anwenders sein sollte, PATH mit Verzeichnissen, die der
Systemadministrator vergessen hat, hineinzutun, bestücken zu
müssen.

X11 kommt traditionell mit dem Anspruch daher, in Umgebungen, an
denen mehrere Rechner – auch mit unterschiedlichen
Betriebssystemen – beteiligt sind, zu funktionieren.  Das schließt
auch Umgebungen ein, in denen beispielsweise BSD, HP-UX, Solaris,
GNU/Linux, … zusammenarbeiten.

Da kann es dann schon mal dazu kommen, dass der Anwender ein und
das selbe HOME‐Verzeichnis über NFS oder auf andere Weise auf den
verschiedenen Systemen wiederfindet.  Wie soll er da in seiner
Datei "$HOME"/.profile vernünftig entscheiden können, die
Hausaufgaben welches Systemadministrators er nun noch machen
soll:  Muss beispielsweise «/usr/xpg4bin/» in den PATH oder
nicht?

Wenn freilich der Distributor seine Hausaufgaben nicht gemacht
hat und auch den Administrator daran hindert, seine Hausaufgaben
zu machen, bleibt es doch am Anwender hängen.


Vor Jahren habe ich mal gesehen, dass eine X11‐Umgebung (weiß
nicht mehr, auf welcher Sorte von Unix) beim Start nach dem
Login‐Manager schließlich

ksh -c -- '"$@"' ksh \
exec -a -"${SHELL##*/}" -- "${SHELL}" -c -- '"$@"' \
-"${SHELL##*/}" /etc/X11/Xsession …

oder so ähnlich gestartet hat.  Dabei wird die Eigenschaft des
«ksh»‐«exec»‐Kommandos, dem zu startenden Programm (hier: dem
«"$SHELL"» des Anwenders) einen mit einem Minuszeichen
beginnenden Aufrufnamen (den Parameter der «exec»‐Option «-a»)
verpassen zu können, verwendet.  Sie bewirkt, dass sich der
aufzurufende «"$SHELL"» des Anwenders als Login‐Shell (s. o.)
verhält.  Das «ksh»‐Kommando «exec» ist daher eine gute
Entsprechung der Funktion «execlp(3)» aus der Laufzeitbibliothek
und damit letztlich des Systemaufrufs «execve(2)».  Aber auch im
«bash» hat das «exec»‐Kommando diese Fähigkeiten inzwischen. 
(Leider bricht genau diese Erweiterung der Fähigkeiten des
«exec»‐Kommandos die Kompatibilität zum POSIX‐Standard.)

Das war meiner Meinung nach die sauberste Möglichkeit, in einer
X11‐Umgebung den PATH zu setzen (und alles andere, was
Login‐Shells so machen, um eine ordentliche Umgebung
hochzuziehen, hinzubekommen).

Allerdings erfordert das vom Anwender große Sorgfalt beim
Erstellen seiner Datei «"$HOME"/.profile»:  Macht er darin einen
Fehler, kommt ihm unter Umständen seine X‐Sitzung nicht mehr
hoch.

In letzter Zeit habe ich den Kniff mit «exec -a …» beim
X‐Sitzungs‐Start auch nicht mehr gesehen – wahrscheinlich
deshalb, weil Anwender häufig ja schon mit

case "$-" in
(*i*)
# Kommandos fuer den interaktiven Shell
# kommen hier hin:
esac

überfordert sind und der Distributor deshalb annimmt, dass man
sich nicht darauf verlassen kann, dass nicht‐interaktive
Login‐Shells bei den Anwendern, die ihre Datei «"$HOME"/.profile»
bearbeitet haben, noch funktionieren.  Schade eigentlich.

> Erreichen kann man das über die Xsession(5)-Mechanismen.
> Vorausgesetzt, der DM startet nach dem Login die Session so.
> Entweder unter /etc/etc/X11/Xsession.d/ in der Reihung vor
> "99x11-common_start" einen Skriptschnipsel anlegen, der den PATH
> setzt oder den PATH unter ~/.xsessionrc setzen. Die Datei wird
> dann während des Starts bzw. der Vorbereitung des Starts der
> Desktop-Umgebung/XSession gesourct. Danach fummelt hoffentlich
> keines der Skripte nochmal am PATH rum.
>
> aus Xsession(5):
> | /etc/X11/Xsession.d/40x11-common_xsessionrc
> | Source global environment variables. This script will source
> | anything in $HOME/.xsessionrc if the file is present. This
> | allows the user to set global environment variables for their
> | X session, such as locale information.

Das ist dann so eine Art Arme‐Leute‐Login‐Shell‐Ersatz.


Es wäre auch eine Überlegung wert, in der Datei
«"$HOME"/.xsessionrc die Shell‐Kommandos

. /etc/profile
. "$HOME"/.profile

ausführen zu lassen, um wenigstens einen Teil dessen, was ein
Login‐Shell tut, zu simulieren.

[Marco Moock]

Am 03.10.2022 um 12:29:40 Uhr schrieb Lutz Falke:

> Dieses Problem hat mich auch schon einiges an Nerven gekostet.

Das Thema hört nicht auf. :-)
Ich habe es zwar gelöst, würde aber gerne wissen, wer der Verursacher
dessen ist. Da ich gerade die LPIC-Unterlagen durchgehe:

Könnte /etc/login.defs da auch noch reinpfuschen beim Erstellen des
Users?

Unter Ubuntu steht da das drin, unter Debian muss ich nachschauen:

ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

[Lutz Falke]

Marco Moock schrieb:

> Am 03.10.2022 um 12:29:40 Uhr schrieb Lutz Falke:
>
>> Dieses Problem hat mich auch schon einiges an Nerven gekostet.
>
> Das Thema hört nicht auf. :-)
> Ich habe es zwar gelöst, würde aber gerne wissen, wer der Verursacher
> dessen ist.

Ich hatte bei mir, wie gesagt, den Display-Manager als Übeltäter
identifiziert. Welchen hast du denn in Verwendung? Ich hatte dazu auch
schon gesucht und gesehen, dass die sich durchaus im Detail
unterschiedlich verhalten. Gewissheit bringt dann wahrscheinlich nur
ein Blick in den entsprechenden Quellcode.

> Da ich gerade die LPIC-Unterlagen durchgehe:
>
> Könnte /etc/login.defs da auch noch reinpfuschen beim Erstellen des
> Users?

Nicht beim Erstellen des Nutzers. Die Einstellungen werden von «login»
und «su» benutzt, um den initialen PATH einzustellen. Das kann aber
halt später noch überschrieben werden.

Man kann einen neuen User ja auf verschiedene Arten anlegen. Die
«login.defs» wirkt erstmal direkt nur auf «useradd». Das ist das
Low-Level-Tool aus den «shadow-utils». Unter Debian(-derivaten) sollte
man normalerweise «adduser» verwenden. Das ist das
distributionsspezifische Werkzeug und wird über «/etc/adduser.conf»
konfiguriert. Ist komfortabler und so erzeugt man auch keine
Konflikte, wenn das System später bei der Paketinstallation
selbständig noch weitere Nutzer anlegt.

Spielt aber eigentlich hier keine Rolle, da der «PATH» nicht direkt an
den User gebunden ist. Höchstens indirekt, indem er in den
Startup-Dateien verändert/ersetzt wird.

>
> Unter Ubuntu steht da das drin, unter Debian muss ich nachschauen:
>
> ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Unter «Debian/bullseye» auch. Und direkt darüber steht der Kommentar,
dass die Pfade minimal sind und man möge den Rest in den "shell
startup files" regeln. Was, wie du ja gesehen hast, nicht in jedem
Fall zum erwarteten Ergebnis führt.

Die Wirkung kannst du aber trotzdem ausprobieren. Wenn du die
Einstellungen mal abänderst und dann mal mit «su -» den Benutzer
wechselst oder dich per SSH oder auf dem virtuellen Terminal direkt
einloggst, müsste sich die Änderung eigentlich bemerkbar machen.

Lutz

[Stefan Froehlich]

On Tue, 11 Oct 2022 00:42:38 Lutz Falke wrote:
> Man kann einen neuen User ja auf verschiedene Arten anlegen. Die
> «login.defs» wirkt erstmal direkt nur auf «useradd». Das ist das
> Low-Level-Tool aus den «shadow-utils». Unter Debian(-derivaten)
> sollte man normalerweise «adduser» verwenden.

Diese beiden Bezeichnungen sind auch so ein Unding - ich versuche
mir das seit sicherlich zwei Jahrzehnten zu merken, bislang ohne
jeglichen Erfolg :-/

Servus,
Stefan

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

Stefan - die vollkommenste Bejahung der Sünde!
(Sloganizer)

[Marco Moock]

Am 10.10.2022 um 22:42:38 Uhr schrieb Lutz Falke:

> Ich hatte bei mir, wie gesagt, den Display-Manager als Übeltäter
> identifiziert. Welchen hast du denn in Verwendung? Ich hatte dazu auch
> schon gesucht und gesehen, dass die sich durchaus im Detail
> unterschiedlich verhalten. Gewissheit bringt dann wahrscheinlich nur
> ein Blick in den entsprechenden Quellcode.

xdm unter Debian. Über dessen Datei (müsste ~/.xsession-rc sein, bin
gerade am anderen PC) funktioniert es.

[Marc Haber]

Lutz Falke <lutz...@gmx.de> wrote:
>Man kann einen neuen User ja auf verschiedene Arten anlegen. Die
>«login.defs» wirkt erstmal direkt nur auf «useradd». Das ist das
>Low-Level-Tool aus den «shadow-utils». Unter Debian(-derivaten) sollte
>man normalerweise «adduser» verwenden. Das ist das
>distributionsspezifische Werkzeug und wird über «/etc/adduser.conf»
>konfiguriert. Ist komfortabler und so erzeugt man auch keine
>Konflikte, wenn das System später bei der Paketinstallation
>selbständig noch weitere Nutzer anlegt.

Unter adduser liegen allerdings auch nur useradd-Aufrufe.

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

[Hans Crauel]

Stefan Froehlich schrieb

> On Tue, 11 Oct 2022 00:42:38 Lutz Falke wrote:
> > Man kann einen neuen User ja auf verschiedene Arten anlegen. Die
> > «login.defs» wirkt erstmal direkt nur auf «useradd». Das ist das
> > Low-Level-Tool aus den «shadow-utils». Unter Debian(-derivaten)
> > sollte man normalerweise «adduser» verwenden.
>
> Diese beiden Bezeichnungen sind auch so ein Unding - ich versuche
> mir das seit sicherlich zwei Jahrzehnten zu merken, bislang ohne
> jeglichen Erfolg :-/

Na, adduser kommt alphabetisch vor useradd, ist also vorzuziehen.

Und wenn man dann doch unsicher ist, guckt man halt einfach in der
man-page nach. Bei useradd heißt es direkt unter DESCRIPTION

| useradd is a low level utility for adding users. On Debian,
| administrators should usually use adduser(8) instead.

Und bei adduser steht nichts dergleichen. Sicherheitshalber gucke
ich aber im Fall, dass ich auf der ersten man-page nichts finde
(das ist dann adduser) auch nochmal bei - dann - useradd nach.

Hans

[Stefan Froehlich]

On Wed, 12 Oct 2022 01:44:58 Hans Crauel wrote:
> Stefan Froehlich schrieb
>> [adduser vs. useradd]

>> Diese beiden Bezeichnungen sind auch so ein Unding - ich versuche
>> mir das seit sicherlich zwei Jahrzehnten zu merken, bislang ohne
>> jeglichen Erfolg :-/

> Na, adduser kommt alphabetisch vor useradd, ist also vorzuziehen.

Hm, mal ausprobieren. Vielleicht klappt das ja endlich.

> Und wenn man dann doch unsicher ist, guckt man halt einfach in der
> man-page nach. Bei useradd heißt es direkt unter DESCRIPTION

Genau *das* mache ich auch, aber wenn man das auf jeder Maschine für
jeden User neu tut (tun muss), kommt man sich im Lauf der Jahre ein
bisserl blöd vor... das müsste auch besser gehen.

Servus,
Stefan

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

Freiheit jenseits aller Erfahrung: Stefan!
(Sloganizer)