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

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

[lightdm] Kein grafisches User-Login

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

Contents

  [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 08:29 -0500
    Re: [lightdm] Kein grafisches User-Login Tim Ritberg <tim@server.invalid> - 2022-01-01 15:09 +0100
      Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 08:30 +0100
        Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 11:24 -0500
    Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-01 15:14 +0100
      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 15:09 -0500
        Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-01 22:07 +0100
          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 16:22 -0500
            Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-01 23:14 +0100
              Re: [lightdm] Kein grafisches User-Login Arno Lutz <invalid@freakmail.de> - 2022-01-02 00:32 +0100
                Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 23:18 -0500
              Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 22:13 -0500
                Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-02 08:54 +0100
                  Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 09:55 +0100
                    Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-02 10:18 +0100
                      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 10:30 -0500
                        Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-02 21:08 +0100
                          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 10:56 -0500
                        Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-03 03:30 +0100
                          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 11:02 -0500
                Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 09:36 +0100
                  Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 10:54 -0500
                Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-02 21:13 +0100
                  Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 11:44 -0500
                    Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-03 20:37 +0100
    Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 08:17 +0100
      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 11:08 -0500
        Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-03 02:59 +0100
          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 11:36 -0500
            Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-03 21:31 +0100
              [Gelöst] [lightdm] Kein grafisches User-Login (was: [lightdm] Kein grafisches User-Login) Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 18:07 -0500
                Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 19:25 -0500
                  Debian bullseye xkbset-gui defekt? (was: [Gelöst] [lightdm] Kein grafisches User-Login) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-04 08:27 +0100
                    Re: Debian bullseye xkbset-gui defekt? Andreas Kohlbach <ank@spamfence.net> - 2022-01-04 08:58 -0500
                      Re: Debian bullseye xkbset-gui defekt? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-05 03:36 +0100
                        Re: Debian bullseye xkbset-gui defekt? Andreas Kohlbach <ank@spamfence.net> - 2022-01-05 06:05 -0500
                Wie funktioniert "${HOME}/.xsession"? (was: [Gelöst] [lightdm] Kein grafisches User-Login) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-04 08:58 +0100
                  Re: Wie funktioniert "${HOME}/.xsession"? (was: [Gelöst] [lightdm] Kein grafisches User-Login) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-04 20:29 +0100
                    Re: Wie funktioniert "${HOME}/.xsession"? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-05 03:30 +0100
                      Re: Wie funktioniert "${HOME}/.xsession"? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-05 22:11 +0100
                        Re: Wie funktioniert "${HOME}/.xsession"? Juergen Ilse <news@usenet-verwaltung.de> - 2022-01-05 21:37 +0000
                        Re: Wie funktioniert "${HOME}/.xsession"? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-06 23:24 +0100
                          Re: Wie funktioniert "${HOME}/.xsession"? Friedhelm Waitzmann <usenetf2022.fwnsp@spamgourmet.com> - 2022-01-07 01:03 +0000
                Re: [Gelöst] [lightdm] Kein grafisches User-Login (was: [lightdm] Kein grafisches User-Login) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-04 20:24 +0100
                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-04 18:32 -0500
                    Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-05 22:38 +0100
                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-05 19:20 -0500
                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-07 20:55 +0100
                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-07 18:23 -0500
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Thomas Noll <-_tn_-@web.de> - 2022-01-08 12:56 +0000
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-08 22:29 +0100
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-08 19:28 -0500
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-09 08:16 +0100
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-09 08:25 -0500
                                    Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-09 22:47 +0100
                                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-09 18:34 -0500
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Thomas Dorner <de.comp.os.unix.linux.misc.220110.dorner@spamgourmet.com> - 2022-01-10 18:52 +0100
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-10 19:56 +0100
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-10 20:24 +0100
                                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-10 19:44 -0500
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Thomas Dorner <de.comp.os.unix.linux.misc.220111.dorner@spamgourmet.com> - 2022-01-11 18:05 +0100
                                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-11 15:33 -0500
                                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-12 01:08 +0100
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-12 00:04 +0100
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-08 22:33 +0100
                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-08 22:45 +0100
                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-08 19:37 -0500
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-09 03:02 +0100
                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-08 22:18 +0100
                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-09 21:05 +0100
                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-10 20:48 +0100
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-12 19:53 +0100
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-13 07:04 -0500
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-13 23:37 +0100
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Hans CraueI <crauel_usenet@freenet.de> - 2022-01-13 23:40 +0000
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 04:13 -0500
                                    Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-15 21:46 +0100
                                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-16 09:53 -0500
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-17 23:39 +0100
                                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-21 23:01 -0500
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Paul Muster <exp-311222@news.muster.net> - 2022-01-22 08:11 +0100
                                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-22 15:12 -0500
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-23 01:19 +0100
                                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-22 22:59 -0500
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-14 20:24 +0100
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-13 23:12 +0100
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 03:50 -0500
                                  apthängigkeiten (was: Re: [Gelöst] [lightdm] Kein grafisches User-Login) Thomas Noll <-_tn_-@web.de> - 2022-01-14 15:57 +0000
                                    Re: apthängigkeiten (was: Re: [Gelöst] [lightdm] Kein grafisches User-Login) Paul Muster <exp-311222@news.muster.net> - 2022-01-14 17:11 +0100
                                      Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 12:07 -0500
                                        Re: apthängigkeiten Paul Muster <exp-311222@news.muster.net> - 2022-01-14 21:31 +0100
                                          Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 18:09 -0500
                                            Re: apthängigkeiten Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-01-16 11:15 +0100
                                        Re: apthängigkeiten Bernd Mayer <beam.bam.boom@knuut.de> - 2022-01-14 22:07 +0100
                                          Re: apthängigkeiten Bernd Mayer <beam.bam.boom@knuut.de> - 2022-01-14 22:19 +0100
                                            Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 18:21 -0500
                                        Re: apthängigkeiten Jens Schüßler <j.schuess@nurfuerspam.de> - 2022-01-14 23:39 +0100
                                          Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-15 07:03 -0500
                                      Re: apthängigkeiten Thomas Noll <-_tn_-@web.de> - 2022-01-14 19:39 +0000
                                        Re: apthängigkeiten Paul Muster <exp-311222@news.muster.net> - 2022-01-14 21:31 +0100
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-14 20:35 +0100
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-15 21:46 +0100
            Wer mit "root" zuendelt... (was: [lightdm] Kein grafisches User-Login) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-04 09:11 +0100
              Re: Wer mit "root" zuendelt... Andreas Kohlbach <ank@spamfence.net> - 2022-01-04 09:17 -0500
                Re: Wer mit "root" zuendelt... Kay Martinen <usenet@martinen.de> - 2022-01-04 22:42 +0100
                  Re: Wer mit "root" zuendelt... Andreas Kohlbach <ank@spamfence.net> - 2022-01-05 05:30 -0500
                Re: Wer mit "root" zuendelt... Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-05 03:37 +0100
    Re: [lightdm] Kein grafisches User-Login Gert Link <gertlink_nospam@gmx.de> - 2022-01-02 08:49 +0100
      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 11:09 -0500
        Re: [lightdm] Kein grafisches User-Login Tim Ritberg <tim@server.invalid> - 2022-01-03 18:50 +0100

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

#120767 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net> writes:

> Wenn am Ende der .xsession keine
>
> exec $IRGENDWAS
>
> steht, sollten alle Einträge in .xsession verworfen werden, um X trotzdem
> zu starten.

Und jemand, der nach dem Beenden der Session $IRGENDWAS in seiner
.xsession noch Aufräumarbeiten implementiert hat darf sich dann bei Dir
bedanken, daß das plötzlich nicht mehr funktioniert.

> Ganz platt: eine kaputte .bash_profile erlaubt es jedem Benutzer eine
> Shell zu erlangen. Eine kaputte .xsession verwehrt einem User aber das
> Einloggen in eine GUI.

Das ist FALSCH, probiere aus, was ich dazu geschrieben habe!

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

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

#120777 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Tue, 11 Jan 2022 18:05:40 +0100, Thomas Dorner wrote:
>
> Andreas Kohlbach <ank@spamfence.net> writes:
>
>> Wenn am Ende der .xsession keine
>>
>> exec $IRGENDWAS
>>
>> steht, sollten alle Einträge in .xsession verworfen werden, um X trotzdem
>> zu starten.
>
> Und jemand, der nach dem Beenden der Session $IRGENDWAS in seiner
> .xsession noch Aufräumarbeiten implementiert hat darf sich dann bei Dir
> bedanken, daß das plötzlich nicht mehr funktioniert.

AFAIK wird die .xsession nach Starten von X nicht mehr ausgewertet. Zum
Aufräumen ist das der falsche Ort.

>> Ganz platt: eine kaputte .bash_profile erlaubt es jedem Benutzer eine
>> Shell zu erlangen. Eine kaputte .xsession verwehrt einem User aber das
>> Einloggen in eine GUI.
>
> Das ist FALSCH, probiere aus, was ich dazu geschrieben habe!

Hast Du es selbst ausprobiert?

Ich habe ich meine .bash_profile mal die Zeile

meh;

eingefuegt, dann auf einer freien TTY eingeloggt:

==============
kitchensink login: ank
Password:
Linux kitchensink 5.15.0-2-686-pae #1 SMP Debian 5.15.5-2 (2021-12-18) i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Jan  9 08:00:57 EST 2022 on tty8
You have mail.
-bash: meh: command not found
================

und bin in einer Bash-Shell.

Daher bleibe ich dabei; eine kaputte .xsession verhindert den Start von
X, eine kaputte .bash_profile verhindert dagegen *nicht* den Start einer
Bash-Shell.
-- 
Andreas

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

#120789 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Tue, 11 Jan 2022 18:05:40 +0100, Thomas Dorner wrote: 
>
>>
>> Andreas Kohlbach <ank@spamfence.net> writes:
>>
>>> Wenn am Ende der .xsession keine
>>>
>>> exec $IRGENDWAS
>>>
>>> steht, sollten alle Einträge in .xsession verworfen werden, um X 
>>> trotzdem zu starten.
>>
>> Und jemand, der nach dem Beenden der Session $IRGENDWAS in seiner 
>> .xsession noch Aufräumarbeiten implementiert hat darf sich dann 
>> bei Dir bedanken, daß das plötzlich nicht mehr funktioniert.
>
>AFAIK wird die .xsession nach Starten von X nicht mehr ausgewertet. 
>Zum Aufräumen ist das der falsche Ort.

Meine räumt auf, und zwar heftig, und schickt mir danach auch noch 
ein Protokoll.  Deshalb endet sie auch nicht mit

   exec $IRGENDWAS

sondern mit «mailx». 


Die Datei «~/.xsession» startet nicht die Grafiksitzung sondern ist 
die Grafiksitzung:  Kommt sie zu Ende, beendet beispielsweise 
«xinit» den X‐Server.  Der informiert alle X-Programme, die mit ihm 
angebändelt haben, dass alles aus ist, und macht die Tür zu.  Da 
hilft auch kein Stalking mehr.


Wenn die Datei als letztes in der Tat 


   exec $IRGENDWAS

stehen hat, wird $IRGENDWAS zur X‐Sitzung.  Aber das ist nur ein 
einfacher Spezialfall einer Datei «~/.xsession» (siehe mein Beitrag 
nebenan).

>
>>> Ganz platt: eine kaputte .bash_profile erlaubt es jedem Benutzer 
>>> eine Shell zu erlangen. Eine kaputte .xsession verwehrt einem 
>>> User aber das Einloggen in eine GUI.
>>
>> Das ist FALSCH, probiere aus, was ich dazu geschrieben habe! 
>>
>
>Hast Du es selbst ausprobiert? 
>
>
>Ich habe ich meine .bash_profile mal die Zeile 
>
>
>meh;
>
>eingefuegt, dann auf einer freien TTY eingeloggt: 
>
>
>==============
>kitchensink login: ank
>Password:

[…]

>Last login: Sun Jan  9 08:00:57 EST 2022 on tty8
>You have mail.
>-bash: meh: command not found
>================
>
>und bin in einer Bash-Shell. 
>
>
>Daher bleibe ich dabei; eine kaputte .xsession verhindert den Start 
>von X, eine kaputte .bash_profile verhindert dagegen *nicht* den 
>Start einer Bash-Shell.

Nicht jede kaputte Datei «~/.bash_profile» lässt den «bash»‐Shell am 
Leben.  Nimm das Beispiel von Thomas Dorner oder auch die folgende 
Datei «~/.bash_profile»:

   set -e; meh;

=> Fehlertoleranz hat man nur in gewissen Fällen – sowohl bei 
«~/.bash_profile» als auch bei «~/.xsession».

Aber, wie bereits geschrieben, müsstest du «~/.xsession» nicht mit 
«~/.bash_profile» sondern mit dem Feld «user command interpreter» in 
der Datei «/etc/passwd» vergleichen.  «~/.bash_profile» könnte man 
in gewisser Hinsicht eher mit der Autostart‐Funktion der 
Grafikumgebung vergleichen.

Zurück zur Praxis:  Wenn du von X11 verlangst, dass deine X‐Sitzung 
am Leben bleiben soll, obwohl «~/.xsession» zu Ende gekommen ist, 
machst du es falsch:  «~/.xsession» ist nicht der richtige Adressat 
deines Wunsches.

Der richtige Adressat ist die Auto‐Start‐Funktion der 
Grafik‐Umgebung, die du nutzst.  Dort mach deine Einträge, nicht in 
«~/.xsession».  Dann erhältst du die Robustheit gegenüber 
fehlerhaften Einträgen, die du möchtest.

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

#120787 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Mon, 10 Jan 2022 20:24:07 +0100, Helmut Waitzmann wrote:
>

>> Also momentan ist es ja so, dass eine Datei «~/.xsession», in der
>> nur ein «xkbset»‐Aufruf (hineingesetzt von «xkbset-gui»)
>> drinsteht, dem Benutzer eine X‐Sitzung gibt, die nur den
>> «xkbset»‐Aufruf macht und sich danach sofort beendet, anstatt
>> eine Grafik‐Umgebung hochzuziehen.  Dadurch ist sie kaputt.
>>
>> Wie müsste ein System konkret reagieren, das so eine Datei
>> «~/.xsession», in der nur dieser eine «xkbset»‐Aufruf drinsteht,
>> vorfindet?
>>
>> Müsste es die Datei beim Einloggen untersuchen?  Welche Fragen
>> müsste es bei der Untersuchung stellen und beantworten?  Wie
>> müssten die Antworten ausfallen, damit das System Handlungsbedarf
>> sieht?
>
>Wenn am Ende der .xsession keine
>
>exec $IRGENDWAS
>
>steht, sollten alle Einträge in .xsession verworfen werden, um X
>trotzdem zu starten.

Danke.  Du kommst der Sache näher.


Deine Fehlererkennungsregel würde mindestens eine
«~/.xsession»‐Datei als defekt erkennen, die in Wirklichkeit in
Ordnung ist: meine.  Denn die endet mit den folgenden drei Zeilen:

     mailx -s "xsession log from ${MY_DISPLAYFQDN}" -- \
       "${USERMAILADDRESS:-"${LOGNAME}"}"
   )

Ich würde einen geharnischten Fehlerbericht einreichen, d. h., den
Maintainern das Halteproblem um die Ohren schlagen, wenn Debian
Deine Fehlererkennungsregel als Kriterium nähme.

>Es sollte einfach eine existieren und möglicherweise kaputte
>.xsession ignorieren.
>
>> Kannst du – meinetwegen gerne in eigenen Worten oder als
>> Shell‐Skript‐Idee – beschreiben, wonach beispielsweise das System
>> in der Datei «~/.xsession» suchen soll?  Wie kommt es zum
>> Ergebnis «die Datei ist in Ordnung» oder «die Datei ist defekt»?
>
>Wenn eine Xsession (oder .xsession eines Users) Fehler aufweist und
>damit nicht zuverlässig geparst werden kann, sollte X deren Inhalt
>ignorieren, und trotzdem starten.

Meine kann zuverlässig vom Shell geparst werden und weist keine
Fehler auf.  Trotzdem würde sie von deinem Vorschlag der
Fehlererkennung fälschlicherweise als fehlerhaft erkannt und
ignoriert.

Aber in Wirklichkeit willst du etwas anderes, denn du schreibst oben
(nochmal zitiert): 

>Wenn am Ende der .xsession keine
>
>exec $IRGENDWAS
>
>steht, sollten alle Einträge in .xsession verworfen werden, um X
>trotzdem zu starten.

Deine Worte sind wohlgewählt, denn in der Datei «~/.xsession» stehen
keine Einträge:  Sie ist keine Liste von abzuarbeitenden
Programmaufrufen sondern ein vollständiges eigenständiges Programm,
das den ganzen Werkzeugkasten (die Touring‐Vollständigkeit, siehe
<https://de.wikipedia.org/wiki/Turing-Vollst%C3%A4ndigkeit#Beispiele>),
beispielsweise Programm‐Schleifen, zur Verfügung hat.  (Meine Datei
«~/.xsession» ist ein Shell‐Skript und enthält eine
«until‐do‐done»‐Schleife.)

Du willst keine Datei «~/.xsession» schreiben, sondern eine fix und
fertig vorgegebene Grafikumgebung nutzen.  Dazu musst du nur
sicherstellen, dass du keine Datei «~/.xsession» (oder
«~/.Xsession») hast, oder eine hast, die aus nichts anderem als
einem Aufruf der gewünschten Grafikumgebung besteht, etwa:

   #!/bin/sh
   exec gnome-session

Beides dürftest du fehlerfrei hinkriegen.


Irgendwelche Programmaufrufe («Einträge», beispielsweise «xkbset»)
schreibst du dann auch nicht in die Datei «~/.xsession» hinein,
sondern nützst die Autostart‐Fähigkeiten der von dir gewünschten
Grafikumgebung:  Dort gibt es sicher irgendwo die Möglichkeit,
Programmaufrufe, die beim Sitzungsstart erfolgen sollen,
einzutragen.

Das sind dann in der Tat Einträge in einer Liste von
Programmaufrufen.  Da muss das System kein Halteproblem lösen:  Es
startet einfach jeden Programmaufruf im Hintergrund.  Sollte der
dann im Lauf der Grafiksitzung mit Exit‐Status ungleich 0 zu Ende
kommen (Ungleich 0 bedeutet:  Das aufgerufene Programm meldet einen
Fehler.), wirft sie dir eine Meldung auf den Bildschirm, die dich
darüber informiert.  Das ist alles.

Das unlösbare Halteproblem ist übrigens auch der Grund, warum nicht
längst alle Hersteller von Anti‐Malware‐Programmen bankrott sind: 

Man kann kein (Anti‐Malware‐) Programm schreiben, das alle
zukünftige Computer‐Malware erkennt, weil es jedes beliebige
Programm untersuchen könnte und dadurch herausbekommen könnte, ob es
Malware ist.

Anti‐Malware‐Programme können immer nur nach ihnen bekannten Teilen
von Malware suchen.  Wenn sie solche sehen, können sie Alarm
schlagen.  Aber auch da kann es passieren, dass sie Programme
fälschlicherweise als Malware erkennen, obwohl sie keine Malware
sind, weil die zufälligerweise etwas enthalten, was auch in einem
bekannten Malware‐Programm vorkommt.  Und natürlich haben sie keine
Chance, noch unbekannte Malware‐Programme sicher zu erkennen.

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

#120658 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Hallo Andreas Kohlbach,

Du schriebst am Fri, 07 Jan 2022 18:23:22 -0500:

> > solltest Du schon mal überlegen. Weitere Kommentare spar' ich mir
> > dann...

Aber dazu möchte ich schon naoch was anmerken:

> Also sollte der X-Server auch mit einer "kaputten" .xsession starten.
> So wie beispielsweise Linux selbst in der Regel auch durchbootet,
> wenn der eine oder andere dabei aufgerufene Service eine kaputte
> Konfig, oder ein anderes Problem hat.

Da schmeißt Du nämlich völlig unterschiedliche Katagorien in einen
Topf. Der Vergleich ist so unsinnig, daß er weder richtig noch falsch
ist.
Die .xsession für X wäre für den Linux-Kernel eher mit einer Liste zu
ladender Treiber zu vergleichen, wie es die früher mal gab. Dienste
kommen erst viel später, wenn das System schon läuft.
Auf Deiner Maschine konnte X ja mit der falschen .xsession nichtmal
starten, vergleichsweise hätte da der falsche Satz Treiber den Kernel
gleich in eine Panik getrieben.

...
> Wer immer der Maintainer der .xsession ist, sollte sich daran IMO ein
> Beispiel nehmen: X starten, egal ob die .xsession kaputt ist, auch
> wenn nur ein "exec"-Aufruf am Ende fehlt.

Die .xsesion hat aber keinen Maintainer. Wenn sie bei der Installation
nicht gebraucht wird, ist der dafür zuständig, der sie anlegt. Wenn das
mit einem wie auch immer gearteten Programm passiert, dann ist
allenfalls dessen Maintainer dafür zuständig, aber jedenfalls auch der,
der das Programm benutzt - er hätte sich ja infomieren können, was das
macht und kontrollieren, ob es das auch richtig macht.

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

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

#120656 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>Hmm. Aus der Ferne betrachtet scheint das derzeitige Konzept einer 
>.xsession fragwürdig. Meiner bescheidenen Meinung nach sollte eine 
>existierende .xsession beachtet werden, auch wenn am Ende keine 
>"exec"-Zeile steht.

Sie wird beachtet – und zwar penibelst.  Deine war halt, von 
«xkbset-gui» unsinnigerweise angelegt, so, dass die X‐Sitzung nur 
aus einem «xkbset»‐Aufruf bestand.  Der Fehler liegt also nicht beim 
Konzept «~/.xsession» sondern bei «xkbset-gui»:  «xkbset-gui» hat 
weder eine «~/.xsession» anzulegen noch an einer bestehenden 
herumzufummeln.  Da ist ein Bug‐Report gegen «xkbset-gui» 
angebracht.

>Und das System einfach nach derer Abarbeitung selbst die GUI 
>starten sollte.

Da würden sich Anwender, die ihre eigene Grafiksitzung mittels 
«~/.xsession» starten wollen, schön bedanken, wenn ihnen nach ihrem 
Logout die Standard‐Desktop‐Umgebung starten würde.

Es verhält sich so:  «~/.xsession» ist die vom Anwender selbst 
bereitgestellte X‐Sitzung, nicht mehr und nicht weniger.  Wer als 
Anwender keine bereitstellen will, darf keine Datei «~/.xsession» 
haben.

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

#120663 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Sat, 08 Jan 2022 22:45:11 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> Hmm. Aus der Ferne betrachtet scheint das derzeitige Konzept einer
>> .xsession fragwürdig. Meiner bescheidenen Meinung nach sollte eine 
>> existierende .xsession beachtet werden, auch wenn am Ende keine
>> "exec"-Zeile steht.
>
> Sie wird beachtet – und zwar penibelst.  Deine war halt, von
> «xkbset-gui» unsinnigerweise angelegt, so, dass die X‐Sitzung nur 
> aus einem «xkbset»‐Aufruf bestand.  Der Fehler liegt also nicht beim
> Konzept «~/.xsession» sondern bei «xkbset-gui»:  «xkbset-gui» hat 
> weder eine «~/.xsession» anzulegen noch an einer bestehenden
> herumzufummeln.  Da ist ein Bug‐Report gegen «xkbset-gui» 
> angebracht.

Einverstanden.

>> Und das System einfach nach derer Abarbeitung selbst die GUI starten
>> sollte.
>
> Da würden sich Anwender, die ihre eigene Grafiksitzung mittels
> «~/.xsession» starten wollen, schön bedanken, wenn ihnen nach ihrem 
> Logout die Standard‐Desktop‐Umgebung starten würde.
>
> Es verhält sich so:  «~/.xsession» ist die vom Anwender selbst
> bereitgestellte X‐Sitzung, nicht mehr und nicht weniger.  Wer als 
> Anwender keine bereitstellen will, darf keine Datei «~/.xsession»
> haben.

Ich bleibe hier dabei, dass X bei vorhandener .xsession, die aber
*keinen* Aufruf einer Grafiksitzung am Ende hat, trotzdem eine zu
starten. So wie (aus meinem anderen Artikel eben) trotz einer kaputten
.bash_profile/.bashrc man zu einer Bash-Shell kommt.
-- 
Andreas

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

#120664 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>Ich bleibe hier dabei, dass X bei vorhandener .xsession, die aber 
>*keinen* Aufruf einer Grafiksitzung am Ende hat, trotzdem eine zu 
>starten.

Das System ist weder in der Lage – denn dazu müsste es das 
Halteproblem (<https://de.wikipedia.org/wiki/Halteproblem#top>) 
lösen –, zu überprüfen, ob der Anwender vielleicht vergessen hat, 
einen Grafik‐Desktop‐Start hineinzuschreiben, damit es nach 
Beendigung von «~/.xsession» stillschweigend einen für ihn starten 
könnte, noch willens, den Anwender zu gängeln:  «Der Anwender hat 
sich eine ‹~/.xsession› installiert?  Der Anwender will es so!  Also 
sei es so».

«~/.xsession» ruft aus Sicht des Systems nicht erst eine 
Grafiksitzung auf.  Aus Sicht des Systems ist «~/.xsession» bereits 
die vom Anwender für sich installierte Grafiksitzung, die er erhält, 
wenn er beim Einloggen im Auswahlmenü keine andere Grafiksitzung 
auswählt.

Anders betrachtet:  «~/.xsession» ist der Einhängepunkt, der es dem 
Anwender ermöglicht, eine eigene Grafiksitzung, die nicht bereits 
vom Systemadministrator im Auswahlmenü bereitgestellt wird, zu 
starten.  Deshalb ist es dem Anwender vollständig freigestellt, was 
er damit macht:  Er kann es als Shell‐Skript gestalten oder auch 
beispielsweise als symbolic link auf ein installiertes 
Desktop‐System.

Und wenn er es nicht im voraus weiß, kann er es sich auch von 
«xkbset-gui» kaputt machen lassen.

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

#120654 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de>:
>Hallo Andreas Kohlbach, 
>Du schriebst am Tue, 04 Jan 2022 18:32:58 -0500:
>
>>>> Es war die .xsession. Die habe ich nach /tmp geschoben und nun 
>>>> kann
>...
>> Das Tool hatte keinen Aufruf für den Start der GUI in der Datei 
>> angefügt.
>
>Na, offenbar hat es ja die Datei überhaupt einfach völlig 
>übergebügelt, ohne Rücksicht auf irgendwas, was dort ggfs. vorher 
>drinstand.

Nein, es hat den «xkbset»‐Aufruf hinten drangehängt und dabei die 
Datei «~/.xsession», weil es sie nicht gegeben hat, nebenbei 
erzeugt.

>Das könnte man IMHO wohl durchaus der Kategorie "schwerwiegender 
>Software-Fehler" zuordnen.

Allerdings.  Es ist prinzipiell nicht in jedem Fall möglich, mit 
einem Programm zu ermitteln, wo in einem anderen Programm (hier: 
«~/.xsession») welche Änderung vorgenommen werden muss, um einen 
gewünschten Effekt zu erreichen.  Weil «xkbset-gui» nicht wissen 
kann, ob das Programm «~/.xsession» so einen Fall darstellt, darf es 
nicht stumpfsinnig einfach etwas an die Datei anhängen.  Das 
einzige, was es tun sollte, ist, dem Anwender vorzuschlagen, den 
ermittelten «xkbset»‐Aufruf in seine X11‐Startup‐Datei (wo auch 
immer die liegt) zu übernehmen und ihn zu diesem Zweck zu fragen, in 
welche Datei er ihn (zwischen‐)speichern soll, damit der Anwender 
ihn daraus kopiere und in seiner X11‐Startup‐Datei am richtigen Ort 
eintrage.

>BTW, wie sieht denn eine _funktionierende_ .xsession aus? Du hast 
>da ja jetzt (wieder) einen Vergleich. Oder gibt es die auf Deinem 
>System im Normalfall evtl. garnicht?

Es gibt sie im Normalfall nicht – jedenfalls dann, wenn man eine 
Desktop‐Umgebung benutzt.

>Und woher kam diese Installation? Wenn das eine offizielle 
>Distribution ist, dann wäre da schonmal ein Käfer-Bericht ("Bug 
>report") angebracht. Und am besten dazu gleich eine entsprechende 
>Mitteilung im zugehörigen Forum, so vorhanden...

Unbedingt!  Ein Programm darf nicht einfach an einem Shell‐Skript,
das es nicht kennt, herumfummeln – auch nichts anhängen.

>>> Nicht so eilig - Du hast eine Fehlerstelle gefunden und
>>> vorläufig abgestellt. Sieh'erstmal zu, ob da nicht noch mehr
>>> aufgerissen ist, was mit der korrumpierten ".xsession"
>>> zusammenhängt.
>>
>> Die .xsession, die von "xkbset-gui" erstellt wurde, wurde 
>> entfernt. Ich kann in ~/ keine verdächtige Einträge finden.
>
>Aber _gibt_ es im regulären System denn eine .xsession, und was 
>_tut_ die dort, wenn ja?

Es gibt im regulären System mit entsprechender Desktop‐Umgebung 
keine.

>Wenn das System _ohne_ .xsession läuft, wie wird _dann_ die "GUI" 
>gestartet?

Ja.  Auf meinem Debian Buster schaut «/etc/X11/Xsession» zuerst, ob 
ihm ein Parameter übergeben worden ist, der angibt, was als GUI 
gestartet werden soll.  Wenn man am grafischen Login‐Fenster eine 
Desktop‐Umgebung (Gnome, KDE, …) auswählt, schlägt sich die Wahl im 
Parameter für «/etc/X11/Xsession» nieder.  Wenn man nichts 
derartiges auswählt und also kein Parameter (oder der Parameter 
«default») übergeben worden ist, aber ein ausführbares Programm oder 
Shell‐Skript «~/.xsession» vorhanden ist, wird das gestartet, 
ansonsten startet «/etc/X11/Xsession» «/usr/bin/x-session-manager», 
wenn ein Default‐Session‐Manager vorhanden und konfiguriert ist; 
ansonsten «/usr/bin/x-window-manager», wenn vorhanden und 
konfiguriert; ansonsten «/usr/bin/x-terminal-emulator», wenn 
vorhanden und konfiguriert.  Ansonsten wird ein Fenster mit einer 
Fehlermeldung gezeigt und nichts weiter getan.

>Irgendwo muß die ja über den X-Server aufgerufen werden - 
>

Nebenbei:  Sie wird nicht über den X‐Server sondern neben dem 
X‐Server gestartet, wie es auch im Handbuch «xinit(1)» des Programms 
«xinit» beschrieben ist.

>und wenn das nicht in der .xsession geht, muß es ja wohl anderswo 
>sein.

Es geschieht in «/etc/X11/Xsession». 


>Gibt es regulär auch eine .xsession mit Inhalt, der nicht nur 
>Kommentar iat, dann _fehlt_ dem System ohne diese doch wohl 
>"irgendetwas",

Debian fehlt nichts, sofern ein Session‐Manager, ein Window‐Manager 
oder ein Terminal installiert und konfiguriert ist.  Das folgende 
muss Andreas also nicht befürchten:

>und wenn Du nicht feststellst, _was_, dann kann es halt sein, daß 
>Du irgendwann unvermutet wieder tagelang 'rumsuchen mußt, um auf 
>die Ursache (keine .xsession, hätt' ich nie vermutet...) zu kommen. 
>Schnellfertig fällt halt auch schnell mal auf die Nase.

In Debian ist die Datei «~/.xsession» für die Anwender, die sich 
ihre eigene Wurst braten wollen, vorgesehen.  Wer mit den 
angebotenen Menüs zufrieden ist, braucht sie nicht.)

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

#120694 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Hallo Helmut Waitzmann,

Du schriebst am Sat, 08 Jan 2022 22:18:18 +0100:

> >Na, offenbar hat es ja die Datei überhaupt einfach völlig 
> >übergebügelt, ohne Rücksicht auf irgendwas, was dort ggfs. vorher 
> >drinstand.
> 
> Nein, es hat den «xkbset»‐Aufruf hinten drangehängt und dabei die 
> Datei «~/.xsession», weil es sie nicht gegeben hat, nebenbei 
> erzeugt.

Anscheinend, nachdem Andreas ja einigermaßen deutlich zu erkennen
gegeben hat, daß im Originalsystem offenbar keine vorhanden war.

> >Das könnte man IMHO wohl durchaus der Kategorie "schwerwiegender 
> >Software-Fehler" zuordnen.
> 
> Allerdings.  Es ist prinzipiell nicht in jedem Fall möglich, mit 
> einem Programm zu ermitteln, wo in einem anderen Programm (hier: 
> «~/.xsession») welche Änderung vorgenommen werden muss, um einen 
> gewünschten Effekt zu erreichen.  Weil «xkbset-gui» nicht wissen 

Naja, _wenn_ dieses (Hilfs-!) Programm schon mit einer sich selber
vorkonfigurierenden Umgebung ausgeliefert wird, dann sollte man schon
erwarten können, daß die nicht ohne Vorwarnung bei seiner Nutzung
unbrauchbar gemacht wird. Das ist schon ein Armutszeugnis.

...
> welche Datei er ihn (zwischen‐)speichern soll, damit der Anwender 
> ihn daraus kopiere und in seiner X11‐Startup‐Datei am richtigen Ort 
> eintrage.

Sicher, es gibt unterschiedliche Möglichkeiten. Leider sind inzwischen
offenbar viele Anwender garnicht mehr _in der Lage_, solche Aktionen
durchzuführen, wie Du sie beschrieben hast, jedenfalls nicht ohne
Anleitung, und auch dann nur mit Gegewehr "mit Händen und Füßen".

> >BTW, wie sieht denn eine _funktionierende_ .xsession aus? Du hast 
...
> Es gibt sie im Normalfall nicht – jedenfalls dann, wenn man eine 
> Desktop‐Umgebung benutzt.

Es gibt sie _bei dieser Systemkonfiguration_ im Normalfall nicht.
Ich habe schon ein paar System installiert, mit unterschiedlichen
Display-Managern, auch ganz ohne einen solchen. Meistens waren einige
solche Startdateien - hier für die benutzerspezifische Einrichtung,
schon dabei. Manchmal wurde da nur an die .xinitrc weitergegeben, bei
meinem derzeitigen System, wie geschrieben, werden nur Voreinstellungen
gemacht. Der genaue Ablauf hängt auch vom Display-Manager ab, oder
allgemeiner vom benutzten Startvogang, der bei X11 ja mehr als eine
Phase aufweist. (Nur eine Phase wäre ein simpler Programmaufruf.)

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

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

#120747 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de>:
>Hallo Helmut Waitzmann, 
>Du schriebst am Sat, 08 Jan 2022 22:18:18 +0100:
>

[Es geht um «xkbset-gui».] 


>Naja, _wenn_ dieses (Hilfs-!) Programm schon mit einer sich selber 
>vorkonfigurierenden Umgebung ausgeliefert wird, dann sollte man 
>schon erwarten können, daß die nicht ohne Vorwarnung bei seiner 
>Nutzung unbrauchbar gemacht wird.

Genaugenommen verhält es sich so:  In Debian lassen sich 
Desktop‐Umgebungen installieren; eine davon kann dann auch Default 
sein, d. h. gestartet werden, wenn der Anwender keine Datei 
«~/.xsession» (und keine Datei «~/.Xsession») hat und beim 
grafischen Einloggen im Menü nichts anderes ausdrücklich auswählt.

Dieses ganze System rechnet nicht damit, dass da «xkbset-gui» 
einfach eine Datei «~/.xsession» anlegt oder in ihr herumfummelt.  
Der Fehler liegt also einerseits darin, dass «xkbset-gui» keine 
Möglichkeit anbietet, auszuwählen, an welcher Datei es herumfummelt 
(oder welche es erzeugt) und als Folgefehler andererseits darin, 
dass das Programm «xkbset-gui» zwar zur Verfügung gestellt wird, 
aber nicht ins Grafiksystem integriert ist.

>Sicher, es gibt unterschiedliche Möglichkeiten. Leider sind 
>inzwischen offenbar viele Anwender garnicht mehr _in der Lage_, 
>solche Aktionen durchzuführen, wie Du sie beschrieben hast, 
>jedenfalls nicht ohne Anleitung, und auch dann nur mit Gegewehr 
>"mit Händen und Füßen".

Dem könnte Debian nur beikommen, indem einerseits «xkbset-gui» so 
geändert wird, dass man ihm (per Aufrufparameter) mitteilen kann, 
wohin es seine Daten schreiben soll, und indem andererseits das 
System der Grafikumgebungen so angepasst wird, dass es von vorne 
herein eine Datei (vermutlich dann nicht «~/.xsession») für die 
Daten von «xkbset-gui» reserviert.

Dann müssten die oben beschriebenen Anwender nur noch auf den Knopf 
drücken, der «xkbset-gui» mit dem passenden (vom Grafiksystem 
festgelegten) Aufrufparameter startet.

>
>>>BTW, wie sieht denn eine _funktionierende_ .xsession aus? Du hast 
>>>
>...
>> Es gibt sie im Normalfall nicht – jedenfalls dann, wenn man eine 
>> Desktop‐Umgebung benutzt.
>
>Es gibt sie _bei dieser Systemkonfiguration_ im Normalfall nicht. 
>

Ja.  Ich habe mich in allem auf Andreas' Debian‐Installation 
bezogen, die man erhält, wenn man sich keine Datei «~/.xsession» von 
Hand selber erstellt.

Ob es irgendwo einen distributionsübergreifenden Standard für die 
Funktion von «~/.xsession» gibt, weiß ich nicht.

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

#120813 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Hallo Helmut Waitzmann,

Du schriebst am Mon, 10 Jan 2022 20:48:19 +0100:

> [Es geht um «xkbset-gui».] 
> >Naja, _wenn_ dieses (Hilfs-!) Programm schon mit einer sich selber 
> >vorkonfigurierenden Umgebung ausgeliefert wird, dann sollte man 
...
> Genaugenommen verhält es sich so:  In Debian lassen sich 
> Desktop‐Umgebungen installieren; eine davon kann dann auch Default 
...
> Dieses ganze System rechnet nicht damit, dass da «xkbset-gui» 
> einfach eine Datei «~/.xsession» anlegt oder in ihr herumfummelt.  

Das ist schon richtig - nur wird "Dieses ganze System" (GUIs) ja im
Zusammenhang mit der Distribution "Debian" ausgeliefert, und _dazu_
im Zusammenhang mit "diesen ganzen Systemen". Da Debian (und auch
andere Distributionen) ja den Anspruch erhebt, ein komplette in sich
konsistentes und getestetes System bereitzustellen, ist ein Programm,
das diesess System so nachhaltig stört, auf jewden Fall ein schwerer
Fehler in der Zusammenstellung.

Allerdings - es könnte ja durchaus auch der Fall sein, daß dieses
"xkbset-gui" überhaupt nicht dafür gedacht ist, undefiniert von einem
Benutzer ohne Systemkenntnisse aufgerufen zu werden, sondern nur einen
Bestandteil eines in der Distribution enthaltenen Programmsystems
darstellt, das insgesamt in sich konsistent ist und korrekte Ergebnisse
(hier evtl. eine Tastatur-Konfiguration) liefert. Dann wäre die
Benutzung dieses Teilprogramms außerhalb der zugehörigen Umgebung ein
"Bedienerfehler". Daß der möglich ist, liegt halt daran, daß jeder
mögliche Nutzer auf seinem System effektiv _alles_ tun kann, also auch
es zerstören. Da wäre dann bloß noch nützlich zu wissen, ob dieses
Programm "einfach so" in den allgemeinen Programmverzeichnissen
(/bin, /usr/bin...) 'rumliegt oder nicht eher in den systeminternen
Programmverzeichnissen der "sbin"-Hierarchie. Bei _denen_ sollte man
halt grundsätzlich "ein wenig tiefere" Systemkenntnisse haben und sich
_vor_ deren Benutzung über den Zweck und die möglichen Folgen
informieren.

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

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

#120828 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Wed, 12 Jan 2022 19:53:44 +0100, Sieghard Schicktanz wrote:
>
> Allerdings - es könnte ja durchaus auch der Fall sein, daß dieses
> "xkbset-gui" überhaupt nicht dafür gedacht ist, undefiniert von einem
> Benutzer ohne Systemkenntnisse aufgerufen zu werden, sondern nur einen
> Bestandteil eines in der Distribution enthaltenen Programmsystems
> darstellt, das insgesamt in sich konsistent ist und korrekte Ergebnisse
> (hier evtl. eine Tastatur-Konfiguration) liefert. Dann wäre die
> Benutzung dieses Teilprogramms außerhalb der zugehörigen Umgebung ein
> "Bedienerfehler".

Das könnte in der Tat mein Fehler gewesen sein; ich hatte xkbset (ohne
-gui) beim Suchen im Internet gefunden. Dann "xkb" und "TAB" eingegeben,
was *auch* xkbset-gui anzeigte. So nahm ich die GUI-Version direkt, ohne
mir etwas dabei zu denken.

Wenn das Programm allerdings nicht zum direkten Aufruf vorgesehen ist,
sollte es (siehe unten) besser nicht in $PATH liegen. Weiter sollte es
prüfen, wie es aufgerufen wurde, und beim direkte Aufruf zumindest eine
Warnung ausgeben, dass dies keine gute Idee sei. Ist nicht passiert.

> Daß der möglich ist, liegt halt daran, daß jeder
> mögliche Nutzer auf seinem System effektiv _alles_ tun kann, also auch
> es zerstören.

Ich hatte es nicht also root aufgerufen. Es wurde "nur" die Möglichkeit
des Startens von X zerstört.

> Da wäre dann bloß noch nützlich zu wissen, ob dieses
> Programm "einfach so" in den allgemeinen Programmverzeichnissen
> (/bin, /usr/bin...) 'rumliegt oder nicht eher in den systeminternen
> Programmverzeichnissen der "sbin"-Hierarchie. Bei _denen_ sollte man
> halt grundsätzlich "ein wenig tiefere" Systemkenntnisse haben und sich
> _vor_ deren Benutzung über den Zweck und die möglichen Folgen
> informieren.

~$ whereis xkbset-gui
xkbset-gui: /usr/bin/xkbset-gui

Btw. hat niemand hier Debian? ;-) Weil niemand mal versuchte, xkbset-gui
bei sich selbst aufzurufen (danach aus der GUI ausloggen und schauen, ob
das Einloggen nun nicht mehr geht), um das mal nachzuvollziehen.

Sollte das nun jemand machen, bitte daran denken, dass (vermutlich) eine
kaputte ..xsession erzeugt, oder eine vorhandene zerstört werden könnte. Im
einfachsten Falle die Datei wieder entfernen, ob ein zuvor gesichertes
Backup zurückspielen.
-- 
Andreas

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

#120839 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

 Andreas Kohlbach <ank@spamfence.net>:
> On Wed, 12 Jan 2022 19:53:44 +0100, Sieghard Schicktanz wrote: 
>
>>
>> Allerdings - es könnte ja durchaus auch der Fall sein, daß dieses 
>> "xkbset-gui" überhaupt nicht dafür gedacht ist, undefiniert von 
>> einem Benutzer ohne Systemkenntnisse aufgerufen zu werden, 
>> sondern nur einen Bestandteil eines in der Distribution 
>> enthaltenen Programmsystems darstellt, das insgesamt in sich 
>> konsistent ist und korrekte Ergebnisse (hier evtl. eine 
>> Tastatur-Konfiguration) liefert. Dann wäre die Benutzung dieses 
>> Teilprogramms außerhalb der zugehörigen Umgebung ein 
>> "Bedienerfehler".
>
> Das könnte in der Tat mein Fehler gewesen sein; ich hatte xkbset 
> (ohne -gui) beim Suchen im Internet gefunden. Dann "xkb" und "TAB" 
> eingegeben, was *auch* xkbset-gui anzeigte. So nahm ich die 
> GUI-Version direkt, ohne mir etwas dabei zu denken.

 Es war nicht dein Fehler.  Ein Programm (hier: «xkbset-gui»), das an 
 der Datei «~/.xsession» herumfummelt, obwohl es in der 
 Default‐Konfiguration der Grafikumgebungen keine Datei «~/.xsession» 
 geben darf, passt nicht zu diesen Grafikumgebungen.  Auch hier kann 
 man aus der Tatsache des Halteproblems schließen, dass «xkbset-gui» 
 nicht in der Lage ist, jedwede Datei «~/.xsession» korrekt zu 
 behandeln.  Oder kurz gesagt: «xkbset-gui» ist defekt.

 (Wie du deine Grafikumgebung so anpassen kannst, dass sie sich um 
 «~/.xsession» nicht mehr kümmert und deshalb von «xkbset-gui» nicht 
 mehr aus dem Konzept gebracht wird, habe ich ja bereits 
 geschrieben.)

> Wenn das Programm allerdings nicht zum direkten Aufruf vorgesehen 
> ist, sollte es (siehe unten) besser nicht in $PATH liegen.

 Es gibt in der Default‐Konfiguration der Grafikumgebungen überhaupt 
 keinen sinnvollen Aufruf für «xkbset-gui», weder direkt noch auf 
 andere Weise.

> Weiter sollte es prüfen, wie es aufgerufen wurde, und beim direkte 
> Aufruf zumindest eine Warnung ausgeben, dass dies keine gute Idee 
> sei.

 Hier schlägt wieder das Halteproblem zu:  Kein Programm kann prüfen, 
 ob es direkt oder indirekt (was sollte das sein?) aufgerufen wurde, 
 denn dazu müsste es das Programm, von dem es aufgerufen wird, 
 untersuchen können.

> Btw. hat niemand hier Debian? ;-) Weil niemand mal versuchte, 
> xkbset-gui bei sich selbst aufzurufen (danach aus der GUI ausloggen 
> und schauen, ob das Einloggen nun nicht mehr geht), um das mal 
> nachzuvollziehen.

 Brauch' ich nicht zu versuchen.  Jemand hat mir den Quellcode von 
 «xkbset-gui» gezeigt.  Der Dateiname «~/.xsession» ist hart ins 
 Programm einkodiert.  In Kombination mit «/etc/Xsession» folgt 
 daraus das Verhalten, das du erlebt (und erlitten) hast.

 Es läuft auf folgendes hinaus:  So lang «xkbset-gui» nicht repariert 
 ist, empfiehlt es sich, es nicht zu verwenden – es sei denn, man 
 stellt, wie beschrieben, «~/.xsession» kalt und verwendet statt 
 dessen nur «~/.Xsession».

 Vermutung:  «xkbset-gui» ist ein Schnellschuss von jemandem, der in 
 «~/.xsession» nur eine Reihe von Programmaufrufen (den letzten so, 
 dass auf seine Beendigung gewartet wird) stehen hat und 
 selbstverständlich davon ausgeht, dass das bei jedem Anwender so 
 ist.

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

#120840 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Helmut Waitzmann schrieb 

>  Andreas Kohlbach <ank@spamfence.net>: 
>> Btw. hat niemand hier Debian? ;-) Weil niemand mal versuchte, 
>> xkbset-gui bei sich selbst aufzurufen (danach aus der GUI ausloggen 
>> und schauen, ob das Einloggen nun nicht mehr geht), um das mal 
>> nachzuvollziehen. 

Ich hatte es mal kurz angesehen, aber gleich wieder zugeklappt 
(nicht zuletzt wegen des Fehlers in "Number of pointer movements 
before accleration completed", weitere "acceleration" sind richtig 
- sowas zeugt nicht von umfangreichem Einsatz bzw. umfangreicher 
Prüfung). 
 
>  Brauch' ich nicht zu versuchen.  Jemand hat mir den Quellcode von 
>  «xkbset-gui» gezeigt.  

Ist (jedenfalls bei Devuan 4/Debian 11) ein perl-Skript, 
kann man unter /usr/bin/xkbset-gui selbst angucken. 

> Der Dateiname «~/.xsession» ist hart ins Programm einkodiert.  

Das ließe sich schnell ändern (und das Ergebnis dann etwa in 
/usr/local/bin abladen). So arg hart einkodiert ist es nicht. 

>  Es läuft auf folgendes hinaus:  So lang «xkbset-gui» nicht repariert 
>  ist, empfiehlt es sich, es nicht zu verwenden – es sei denn, man 
>  stellt, wie beschrieben, «~/.xsession» kalt und verwendet statt 
>  dessen nur «~/.Xsession».

Oder das. 
 
>  Vermutung:  «xkbset-gui» ist ein Schnellschuss von jemandem, der in 
>  «~/.xsession» nur eine Reihe von Programmaufrufen (den letzten so, 
>  dass auf seine Beendigung gewartet wird) stehen hat und 
>  selbstverständlich davon ausgeht, dass das bei jedem Anwender so 
>  ist. 

So richtig schnell aber dann auch nicht: 
# Copyright (c) 2000, 2002 Stephen Montgomery-Smith 

Ist also jedenfalls schon was her. 

Hans 

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

#120845 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Thu, 13 Jan 2022 23:37:23 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> On Wed, 12 Jan 2022 19:53:44 +0100, Sieghard Schicktanz wrote: 
>>>
>>> Allerdings - es könnte ja durchaus auch der Fall sein, daß dieses
>>> "xkbset-gui" überhaupt nicht dafür gedacht ist, undefiniert von 
>>> einem Benutzer ohne Systemkenntnisse aufgerufen zu werden, sondern
>>> nur einen Bestandteil eines in der Distribution enthaltenen
>>> Programmsystems darstellt, das insgesamt in sich konsistent ist und
>>> korrekte Ergebnisse (hier evtl. eine Tastatur-Konfiguration)
>>> liefert. Dann wäre die Benutzung dieses Teilprogramms außerhalb der
>>> zugehörigen Umgebung ein "Bedienerfehler".
>>
>> Das könnte in der Tat mein Fehler gewesen sein; ich hatte xkbset
>> (ohne -gui) beim Suchen im Internet gefunden. Dann "xkb" und "TAB" 
>> eingegeben, was *auch* xkbset-gui anzeigte. So nahm ich die
>> GUI-Version direkt, ohne mir etwas dabei zu denken.
>
> Es war nicht dein Fehler.  Ein Programm (hier: «xkbset-gui»), das an
> der Datei «~/.xsession» herumfummelt, obwohl es in der 
> Default‐Konfiguration der Grafikumgebungen keine Datei «~/.xsession»
> geben darf, passt nicht zu diesen Grafikumgebungen.  Auch hier kann 
> man aus der Tatsache des Halteproblems schließen, dass «xkbset-gui»
> nicht in der Lage ist, jedwede Datei «~/.xsession» korrekt zu 
> behandeln.  Oder kurz gesagt: «xkbset-gui» ist defekt.

Eine ~/.xsession war *nicht* Teil der Default-Konfiguration. Sie wurde
erst auf mein Verlangen hin erstellt, als ich «xkbset-gui» zum Einrichten
einer "Keyboard-Mouse" aufrief.

>> Wenn das Programm allerdings nicht zum direkten Aufruf vorgesehen
>> ist, sollte es (siehe unten) besser nicht in $PATH liegen.
>
> Es gibt in der Default‐Konfiguration der Grafikumgebungen überhaupt
> keinen sinnvollen Aufruf für «xkbset-gui», weder direkt noch auf 
> andere Weise.

Ich kann «xkbset-gui», zumindest auf meinem "neuen" Computer, direkt aus
der Shell aufrufen.

Es scheint einfach die GUI-Version von «xkbset» zu sein, die in einer
Grafikumgebung durchaus IMO Sinn macht (wenn sie nicht kaputt wäre).

>> Weiter sollte es prüfen, wie es aufgerufen wurde, und beim direkte
>> Aufruf zumindest eine Warnung ausgeben, dass dies keine gute Idee 
>> sei.
>
> Hier schlägt wieder das Halteproblem zu:  Kein Programm kann prüfen,
> ob es direkt oder indirekt (was sollte das sein?) aufgerufen wurde, 
> denn dazu müsste es das Programm, von dem es aufgerufen wird,
> untersuchen können.

Was ist mit $1? Sollte es "xkbset-gui" selbst sein, sollte das erkannt
werden. Ein indirekter Aufruf sollte in $1 nicht (oder nicht allein)
"xkbset-gui" haben.

>> Btw. hat niemand hier Debian? ;-) Weil niemand mal versuchte,
>> xkbset-gui bei sich selbst aufzurufen (danach aus der GUI ausloggen 
>> und schauen, ob das Einloggen nun nicht mehr geht), um das mal
>> nachzuvollziehen.
>
> Brauch' ich nicht zu versuchen.  Jemand hat mir den Quellcode von
> «xkbset-gui» gezeigt.  Der Dateiname «~/.xsession» ist hart ins 
> Programm einkodiert.  In Kombination mit «/etc/Xsession» folgt  daraus
> das Verhalten, das du erlebt (und erlitten) hast.
>
> Es läuft auf folgendes hinaus:  So lang «xkbset-gui» nicht repariert
> ist, empfiehlt es sich, es nicht zu verwenden – es sei denn, man 
> stellt, wie beschrieben, «~/.xsession» kalt und verwendet statt
> dessen nur «~/.Xsession».
>
> Vermutung:  «xkbset-gui» ist ein Schnellschuss von jemandem, der in
> «~/.xsession» nur eine Reihe von Programmaufrufen (den letzten so, 
> dass auf seine Beendigung gewartet wird) stehen hat und
> selbstverständlich davon ausgeht, dass das bei jedem Anwender so 
> ist.

Ich habe daher einen Bug-Report (mit einem nicht so dringenden Level) für
«xkbset» selbst («xkbset-gui» war unbekannt, obwohl es direkt nach der
Installation meines "nacktem" Debian-Systems installiert wurde)
eingereicht. Eine Antwort (außer einer automatischen Bestätigung) gab es
bisher nicht. Ich hatte aufgrund des "nicht so dringenden Levels" auch
noch keine erwartet.

Wie schon von Hans erwähnt, scheint das Skript das letzte Mal zwischen
2000 oder 2002 (also vor 20 Jahren) aktualisiert worden sein. Wenn
niemand sich diesem annimmt, sollte «xkbset-gui» vielleicht einfach aus
Debian herausfallen, da es (heute) offenbar mehr Schaden als Nutzen
anrichtet.
-- 
Andreas

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

#120868 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Thu, 13 Jan 2022 23:37:23 +0100, Helmut Waitzmann wrote: 
>
>> Andreas Kohlbach <ank@spamfence.net>:
>>> On Wed, 12 Jan 2022 19:53:44 +0100, Sieghard Schicktanz wrote: 
>>>

[zum Thema: «xkbset-gui» zu verwenden, ohne sich darum zu kümmern, 
wo und wie es zu verwenden wäre]

>>> Das könnte in der Tat mein Fehler gewesen sein; ich hatte xkbset 
>>> (ohne -gui) beim Suchen im Internet gefunden. Dann "xkb" und 
>>> "TAB" eingegeben, was *auch* xkbset-gui anzeigte. So nahm ich 
>>> die GUI-Version direkt, ohne mir etwas dabei zu denken.
>>
>> Es war nicht dein Fehler.  Ein Programm (hier: «xkbset-gui»), das 
>> an der Datei «~/.xsession» herumfummelt, obwohl es in der 
>> Default‐Konfiguration der Grafikumgebungen keine Datei 
>> «~/.xsession» geben darf, passt nicht zu diesen 
>> Grafikumgebungen.  Auch hier kann man aus der Tatsache des 
>> Halteproblems schließen, dass «xkbset-gui» nicht in der Lage ist, 
>> jedwede Datei «~/.xsession» korrekt zu behandeln.  Oder kurz 
>> gesagt: «xkbset-gui» ist defekt.
>
>Eine ~/.xsession war *nicht* Teil der Default-Konfiguration. 
>

Freilich.  Andreas, die folgende Frage ist ernst gemeint:  Findest 
du meinen Text missverständlich?  Ich habe mit keiner Silbe 
behauptet oder auch nur angedeutet, dass «~/.xsession» Teil der 
Default‐Konfiguration sein sollte.  Im Gegenteil:  In der 
Default‐Konfiguration gibt es keine Datei «~/.xsession» und darf es 
auch keine, deren Lauf nach kürzester Zeit zu Ende kommt, geben, 
weil sonst das eintritt, was du erlitten hast.

>Sie wurde erst auf mein Verlangen hin erstellt, als ich 
>«xkbset-gui» zum Einrichten einer "Keyboard-Mouse" aufrief.

Ja, das hattest du bereits geschrieben. 


>>> Wenn das Programm allerdings nicht zum direkten Aufruf vorgesehen 
>>> ist, sollte es (siehe unten) besser nicht in $PATH liegen.
>>
>> Es gibt in der Default‐Konfiguration der Grafikumgebungen überhaupt 
>> keinen sinnvollen Aufruf für «xkbset-gui», weder direkt noch auf 
>> andere Weise.
>
>Ich kann «xkbset-gui», zumindest auf meinem "neuen" Computer, 
>direkt aus der Shell aufrufen.

Das kann man auch nicht verhindern:  Jedes Programm, das du 
überhaupt aufrufen kannst (also: die dafür nötigen Zugriffsrechte 
besitzst), kannst auch aus einem Shell heraus aufrufen.  Trotzdem 
bleibt der Aufruf für das defekte «xkbset-gui» Unsinn, weil es 
überhaupt keinen sinnvollen Aufruf dafür gibt – es sei denn, man 
sorgt dafür, dass «~/.xsession» vom restlichen Grafiksystem nicht 
verwendet wird.

>Es scheint einfach die GUI-Version von «xkbset» zu sein, 
>

Nein, «xkbset-gui» ist nicht einfach die GUI‐Fassung von «xkbset»:  
«xkbset» fummelt im Gegensatz zu «xkbset-gui» nicht an der Datei 
«~/.xsession» herum.

>die in einer Grafikumgebung durchaus IMO Sinn macht (wenn sie nicht 
>kaputt wäre).

Genau.

«xkbset-gui» = «xkbset» mit Grafik‐Oberfläche + Unsinn


>>> Weiter sollte es prüfen, wie es aufgerufen wurde, und beim 
>>> direkte Aufruf zumindest eine Warnung ausgeben, dass dies keine 
>>> gute Idee sei.
>>
>> Hier schlägt wieder das Halteproblem zu:  Kein Programm kann 
>> prüfen, ob es direkt oder indirekt (was sollte das sein?) 
>> aufgerufen wurde, denn dazu müsste es das Programm, von dem es 
>> aufgerufen wird, untersuchen können.
>
>Was ist mit $1? Sollte es "xkbset-gui" selbst sein, sollte das 
>erkannt werden. Ein indirekter Aufruf sollte in $1 nicht (oder 
>nicht allein) "xkbset-gui" haben.

Das müsstest du genauer ausführen:  Was meinst du mit «$1»?  Was ist 
ein direkter Aufruf, was ein indirekter?  Kannst du jeweils ein 
Beispiel geben?

>>> Btw. hat niemand hier Debian? ;-) Weil niemand mal versuchte, 
>>> xkbset-gui bei sich selbst aufzurufen (danach aus der GUI 
>>> ausloggen und schauen, ob das Einloggen nun nicht mehr geht), um 
>>> das mal nachzuvollziehen.
>>
>> Brauch' ich nicht zu versuchen.  Jemand hat mir den Quellcode von 
>> «xkbset-gui» gezeigt.  Der Dateiname «~/.xsession» ist hart ins 
>> Programm einkodiert.  In Kombination mit «/etc/Xsession» folgt 
>> daraus das Verhalten, das du erlebt (und erlitten) hast.
>>
>> Es läuft auf folgendes hinaus:  So lang «xkbset-gui» nicht 
>> repariert ist, empfiehlt es sich, es nicht zu verwenden – es sei 
>> denn, man stellt, wie beschrieben, «~/.xsession» kalt und 
>> verwendet statt dessen nur «~/.Xsession».
>>
>> Vermutung:  «xkbset-gui» ist ein Schnellschuss von jemandem, der 
>> in «~/.xsession» nur eine Reihe von Programmaufrufen (den letzten 
>> so, dass auf seine Beendigung gewartet wird) stehen hat und 
>> selbstverständlich davon ausgeht, dass das bei jedem Anwender so 
>> ist.
>
>Ich habe daher einen Bug-Report (mit einem nicht so dringenden 
>Level) für «xkbset» selbst

Hoffentlich geht aus deinem Fehlerbericht hervor, dass «xkbset» 
vollkommen in Ordnung ist, während «xkbset-gui» jedoch die Datei 
«~/.xsession» anlegt oder beschädigt.  Falls nicht, würdest du es 
noch im Fehlerbericht klarstellen?

>(«xkbset-gui» war unbekannt, obwohl es direkt nach der Installation 
>meines "nacktem" Debian-Systems installiert wurde) eingereicht. 
>Eine Antwort (außer einer automatischen Bestätigung) gab es bisher 
>nicht. Ich hatte aufgrund des "nicht so dringenden Levels" auch 
>noch keine erwartet.
>
>Wie schon von Hans erwähnt, scheint das Skript das letzte Mal 
>zwischen 2000 oder 2002 (also vor 20 Jahren) aktualisiert worden 
>sein. Wenn niemand sich diesem annimmt, sollte «xkbset-gui» 
>vielleicht einfach aus Debian herausfallen, da es (heute) offenbar 
>mehr Schaden als Nutzen anrichtet.

Meine Datei «~/.xsession» ist auch schon mindestens an die 22 Jahre 
alt und war schon immer nie nur eine Liste von Einträgen sondern 
immer ein komplettes Shell‐Skript.  «xkbset-gui» hätte sie also auch 
damals schon beschädigt.

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

#120874 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Sat, 15 Jan 2022 21:46:03 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> On Thu, 13 Jan 2022 23:37:23 +0100, Helmut Waitzmann wrote: 
>>>
>>> Es war nicht dein Fehler.  Ein Programm (hier: «xkbset-gui»), das
>>> an der Datei «~/.xsession» herumfummelt, obwohl es in der 
>>> Default‐Konfiguration der Grafikumgebungen keine Datei
>>> «~/.xsession» geben darf, passt nicht zu diesen 
>>> Grafikumgebungen.  Auch hier kann man aus der Tatsache des
>>> Halteproblems schließen, dass «xkbset-gui» nicht in der Lage ist, 
>>> jedwede Datei «~/.xsession» korrekt zu behandeln.  Oder kurz
>>> gesagt: «xkbset-gui» ist defekt.
>>
>> Eine ~/.xsession war *nicht* Teil der Default-Konfiguration. 
>
> Freilich.  Andreas, die folgende Frage ist ernst gemeint:  Findest du
> meinen Text missverständlich?

Mitunter schon.

> Ich habe mit keiner Silbe behauptet
> oder auch nur angedeutet, dass «~/.xsession» Teil der
> Default‐Konfiguration sein sollte.  Im Gegenteil:  In der 
> Default‐Konfiguration gibt es keine Datei «~/.xsession» und darf es
> auch keine, deren Lauf nach kürzester Zeit zu Ende kommt, geben, 
> weil sonst das eintritt, was du erlitten hast.

Das wollte ich sagen.

>>> Es gibt in der Default‐Konfiguration der Grafikumgebungen überhaupt
>>> keinen sinnvollen Aufruf für «xkbset-gui», weder direkt noch auf 
>>> andere Weise.
>>
>> Ich kann «xkbset-gui», zumindest auf meinem "neuen" Computer, direkt
>> aus der Shell aufrufen.
>
> Das kann man auch nicht verhindern:  Jedes Programm, das du überhaupt
> aufrufen kannst (also: die dafür nötigen Zugriffsrechte besitzst),
> kannst auch aus einem Shell heraus aufrufen.  Trotzdem bleibt der
> Aufruf für das defekte «xkbset-gui» Unsinn, weil es überhaupt keinen
> sinnvollen Aufruf dafür gibt – es sei denn, man sorgt dafür, dass
> «~/.xsession» vom restlichen Grafiksystem nicht verwendet wird.
>
>> Es scheint einfach die GUI-Version von «xkbset» zu sein, 
>
> Nein, «xkbset-gui» ist nicht einfach die GUI‐Fassung von «xkbset»: 
> «xkbset» fummelt im Gegensatz zu «xkbset-gui» nicht an der Datei 
> «~/.xsession» herum.

OK.

Offenbar ist xkbset-gui eine API. Sollte der User nicht anfassen. Sicher,
ich hätte vorher einlesen können.
>
>>>> Weiter sollte es prüfen, wie es aufgerufen wurde, und beim direkte
>>>> Aufruf zumindest eine Warnung ausgeben, dass dies keine gute Idee
>>>> sei.
>>>
>>> Hier schlägt wieder das Halteproblem zu:  Kein Programm kann
>>> prüfen, ob es direkt oder indirekt (was sollte das sein?) 
>>> aufgerufen wurde, denn dazu müsste es das Programm, von dem es
>>> aufgerufen wird, untersuchen können.
>>
>> Was ist mit $1? Sollte es "xkbset-gui" selbst sein, sollte das
>> erkannt werden. Ein indirekter Aufruf sollte in $1 nicht (oder 
>>nicht allein) "xkbset-gui" haben.
>
> Das müsstest du genauer ausführen:  Was meinst du mit «$1»?  Was ist
> ein direkter Aufruf, was ein indirekter?  Kannst du jeweils ein 
> Beispiel geben?

Das erste Argument eines Kommandos. xkbset-gui könnte $1 (oder welches
Argument auch immer) auswerten und feststellen, ob es direkt aufgerufen
wurde, um ggf. eine Warnung auszulösen.

Indirekt wäre IMO, wenn ein anderes Programm xkbset-gui aufruft.

Also wenn das Programm "ein_programm" "xkbset-gui" aufruft, sollte $1
xkbset-gui sein. Dann OK (auch $2 etc.).

ein_programm xkbset-gui

Vielleicht einfacher $0 auszuwerten...

>>>> Btw. hat niemand hier Debian? ;-) Weil niemand mal versuchte,
>>>> xkbset-gui bei sich selbst aufzurufen (danach aus der GUI 
>>>> ausloggen und schauen, ob das Einloggen nun nicht mehr geht), um
>>>> das mal nachzuvollziehen.
>>>
>>> Brauch' ich nicht zu versuchen.  Jemand hat mir den Quellcode von
>>> «xkbset-gui» gezeigt.  Der Dateiname «~/.xsession» ist hart ins 
>>> Programm einkodiert.  In Kombination mit «/etc/Xsession» folgt
>>> daraus das Verhalten, das du erlebt (und erlitten) hast.
>>>
>>> Es läuft auf folgendes hinaus:  So lang «xkbset-gui» nicht
>>> repariert ist, empfiehlt es sich, es nicht zu verwenden – es sei 
>>> denn, man stellt, wie beschrieben, «~/.xsession» kalt und verwendet
>>> statt dessen nur «~/.Xsession».
>>>
>>> Vermutung:  «xkbset-gui» ist ein Schnellschuss von jemandem, der in
>>> «~/.xsession» nur eine Reihe von Programmaufrufen (den letzten so,
>>> dass auf seine Beendigung gewartet wird) stehen hat und
>>> selbstverständlich davon ausgeht, dass das bei jedem Anwender so 
>>> ist.
>>
>> Ich habe daher einen Bug-Report (mit einem nicht so dringenden
>> Level) für «xkbset» selbst
>
> Hoffentlich geht aus deinem Fehlerbericht hervor, dass «xkbset»
> vollkommen in Ordnung ist, während «xkbset-gui» jedoch die Datei 
> «~/.xsession» anlegt oder beschädigt.  Falls nicht, würdest du es noch
> im Fehlerbericht klarstellen?

Sollte vorher schon klar gewesen sein. Ich habe es trotzdem aktualisiert
und auch darauf hingewiesen, dass man den Report als erledigt ansehen
kann, da das Problem wohl daran lag, dass ich das Programm selbst aufrief.

[...]
-- 
Andreas

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

#120889 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Sat, 15 Jan 2022 21:46:03 +0100, Helmut Waitzmann wrote: 
>
>> Andreas Kohlbach <ank@spamfence.net>:
>>> On Thu, 13 Jan 2022 23:37:23 +0100, Helmut Waitzmann wrote: 
>>>

>> Andreas, die folgende Frage ist ernst gemeint:  Findest du meinen 
>> Text missverständlich?
>
>Mitunter schon. 
>

In solchen Fällen darfst du gerne nachfragen.  Bei Dingen, die mir 
selbstverständlich sind, kann es schon mal vorkommen, dass ich 
betriebsblind bin.  Da bricht mir kein Zacken aus der Krone, wenn 
jemand nachfragt.

[«xkbset-gui»]

>>> Es scheint einfach die GUI-Version von «xkbset» zu sein, 
>>>
>>
>> Nein, «xkbset-gui» ist nicht einfach die GUI‐Fassung von 
>> «xkbset»:  «xkbset» fummelt im Gegensatz zu «xkbset-gui» nicht an 
>> der Datei «~/.xsession» herum.
>
>OK.
>
>Offenbar ist xkbset-gui eine API. Sollte der User nicht anfassen. 
>Sicher, ich hätte vorher einlesen können.

Wenn «xkbset-gui» eine API ist, dann ist die auf gut Deutsch einfach 
defekt:  Der Entwickler hat angenommen, er dürfe «xkbset-gui» an der 
Datei «~/.xsession» herumfummeln lassen, ohne, dass es dabei Schaden 
anrichtet.  Seine Annahme ist nachweislich falsch.  Und wenn es der 
Fall sein sollte, dass man davon weder etwas im laufenden Programm 
selber (Hilfeknopf o. ä.), noch im Handbuch, noch unter 
«/usr/share/doc/xkbset/» lesen könnte, kann man das Verhalten von 
«xkbset-gui» sogar als hinterhältig bezeichnen.

>>>>> Weiter sollte es prüfen, wie es aufgerufen wurde, und beim 
>>>>> direkte Aufruf zumindest eine Warnung ausgeben, dass dies 
>>>>> keine gute Idee sei.
>>>>
>>>> Hier schlägt wieder das Halteproblem zu:  Kein Programm kann 
>>>> prüfen, ob es direkt oder indirekt (was sollte das sein?) 
>>>> aufgerufen wurde, denn dazu müsste es das Programm, von dem es 
>>>> aufgerufen wird, untersuchen können.
>>>
>>> Was ist mit $1? Sollte es "xkbset-gui" selbst sein, sollte das 
>>> erkannt werden. Ein indirekter Aufruf sollte in $1 nicht (oder 
>>>nicht allein) "xkbset-gui" haben.
>>
>> Das müsstest du genauer ausführen:  Was meinst du mit «$1»?  Was 
>> ist ein direkter Aufruf, was ein indirekter?  Kannst du jeweils 
>> ein Beispiel geben?
>
>Das erste Argument eines Kommandos. 
>

Wenn du (das Perl‐Skript) «xkbset-gui» aufrufst, ist der Inhalt der 
Perl‐Variablen «$0» vermutlich «/usr/bin/xkbset-gui».  Sehen, von 
wem es aufgerufen würde, könnte man daran nicht.  Insofern sehe ich 
keine Chance für deinen Wunsch:

>xkbset-gui könnte $1 (oder welches Argument auch immer) auswerten 
>und feststellen, ob es direkt aufgerufen wurde, um ggf. eine 
>Warnung auszulösen.

Du hast noch immer nicht geschrieben, was du unter «direkt» aufrufen 
verstehst.  Meinst du einen Aufruf von einem interaktiven Shell aus?

>Indirekt wäre IMO, wenn ein anderes Programm xkbset-gui aufruft. 
>
>
>Also wenn das Programm "ein_programm" "xkbset-gui" aufruft, sollte 
>$1 xkbset-gui sein. Dann OK (auch $2 etc.).
>
>ein_programm xkbset-gui

Dann hat die Perl‐Variable «$0» den Wert «/usr/bin/xkbset-gui», und 
den Wert «ein_programm» findet man in keiner Perl‐Variablen:  Er 
taucht dort nirgends auf.

Egal, ob du aus einem interaktiven Shell heraus 


   xkbset-gui

oder

   ein_programm xkbset-gui

beispielsweise

   env DISPLAY=:0 xkbset-gui

oder

   nice -n 5 -- xkbset-gui

oder nicht aus einem Shell heraus eine dieser Varianten aufrufst:  
Du hast immer «/usr/bin/xkbset-gui» in der Variablen «"$0"» stehen.  
Auf «ein_programm», «env» oder «nice» findet man im Perl‐Skript 
keine Hinweise mehr.

[Bug‐Report gegen «xkbset-gui» im Paket «xkbset»] 


>Ich habe es trotzdem aktualisiert und auch darauf hingewiesen, dass 
>man den Report als erledigt ansehen kann, da das Problem wohl daran 
>lag, dass ich das Programm selbst aufrief.

Nein, daran lag es nicht.  Ich habe doch oft genug geschrieben, dass 
«xkbset-gui» defekt ist, und begründet, warum:  Ein Programm, das in 
die Datei «~/.xsession» schreibt, passt nicht zu einer Distribution, 
die Grafikumgebungen anbietet, bei denen es in der 
Standard‐Konfiguration keine Datei «~/.xsession» geben darf.  Ich 
bezeichne das als defekt, weil es unbrauchbar ist.

Das Minimum wäre also ein Feature‐Request um Aufrufparameter, die es 
dem Aufrufer erlauben, anzugeben, wohin «xkbset-gui» seine Daten 
schreibt.

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

#120970 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Mon, 17 Jan 2022 23:39:18 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> On Sat, 15 Jan 2022 21:46:03 +0100, Helmut Waitzmann wrote: 
>>> Andreas Kohlbach <ank@spamfence.net>:
>>>> On Thu, 13 Jan 2022 23:37:23 +0100, Helmut Waitzmann wrote: 
>
>>> Andreas, die folgende Frage ist ernst gemeint:  Findest du meinen
>>> Text missverständlich?
>>
>> Mitunter schon. 
>
> In solchen Fällen darfst du gerne nachfragen.  Bei Dingen, die mir
> selbstverständlich sind, kann es schon mal vorkommen, dass ich 
> betriebsblind bin.  Da bricht mir kein Zacken aus der Krone, wenn
> jemand nachfragt.

Ich, aber auch andere, hatten in der Vergangenheit erwähnt, dass Du gerne
sehr "umfänglich" schreibst. Vermutlich technisch korrekt, aber zu
umfangreich, wenn ein Problem von vielleicht fünf Blickwinkeln aus
betrachtet wird.

> [«xkbset-gui»]

[...]

>>>> Was ist mit $1? Sollte es "xkbset-gui" selbst sein, sollte das
>>>> erkannt werden. Ein indirekter Aufruf sollte in $1 nicht (oder 
>>>>nicht allein) "xkbset-gui" haben.
>>>
>>> Das müsstest du genauer ausführen:  Was meinst du mit «$1»?  Was
>>> ist ein direkter Aufruf, was ein indirekter?  Kannst du jeweils 
>>> ein Beispiel geben?
>>
>> Das erste Argument eines Kommandos. 
>
> Wenn du (das Perl‐Skript) «xkbset-gui» aufrufst, ist der Inhalt der
> Perl‐Variablen «$0» vermutlich «/usr/bin/xkbset-gui».  Sehen, von 
> wem es aufgerufen würde, könnte man daran nicht.  Insofern sehe ich
> keine Chance für deinen Wunsch:
>
>> xkbset-gui könnte $1 (oder welches Argument auch immer) auswerten
>> und feststellen, ob es direkt aufgerufen wurde, um ggf. eine 
>>Warnung auszulösen.
>
> Du hast noch immer nicht geschrieben, was du unter «direkt» aufrufen
> verstehst.  Meinst du einen Aufruf von einem interaktiven Shell aus?

Ganz abstrakt. Nehmen wir ein fiktives Beispiel. Firefox (ein Webbrowser)
arbeitet zum Teil mit Perl. Warum auch immer wird von diesem "xkbset-gui"
aufgerufen. "xkbset-gui" sollte, weil es eben ein Perl-Skript ist (dem
ich wirklich so), feststellen können, ob es direkt (z.B. mir als User)
oder indirekt (im Beispiel über Firefox) aufgerufen wurde.

Wenn von mir, abbrechen (bzw. eine Warnung ausgeben.

[...]

> [Bug‐Report gegen «xkbset-gui» im Paket «xkbset»] 
>
>> Ich habe es trotzdem aktualisiert und auch darauf hingewiesen, dass
>> man den Report als erledigt ansehen kann, da das Problem wohl daran 
>>lag, dass ich das Programm selbst aufrief.
>
> Nein, daran lag es nicht.  Ich habe doch oft genug geschrieben, dass
> «xkbset-gui» defekt ist, und begründet, warum:  Ein Programm, das in 
> die Datei «~/.xsession» schreibt, passt nicht zu einer Distribution,
> die Grafikumgebungen anbietet, bei denen es in der 
> Standard‐Konfiguration keine Datei «~/.xsession» geben darf.  Ich
> bezeichne das als defekt, weil es unbrauchbar ist.

Das sieht auch der Maintainer so. Mein Report wurde als "gelöst"
bezeichnet, und die Sache dem Upstream übergeben:

Samuel Thibault:

| Indeed, xkbset-gui is broken in that regard. I have forwarded the issue
| to upstream.
-- 
Andreas

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

Page 4 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