what display?

[bad sector]

On booting into the Slaclware-15.0 login prompt I get

"Error: Can't open display"
"Error: Can't open display"

What display is this referencing?
(NB. no-one has logged-in at this point)



--
Slackware 15.0, Kernel=5.15.63 on x86_64,
DM=Unknown,DE=lightdm,ST=tty,grub2,GPT,
BIOS-boot,CMI8788-Oxygen.
https://i.imgur.com/yJusEud.png

[Henrik Carlqvist]

On Thu, 15 Sep 2022 00:59:22 +0000, bad sector wrote:

> On booting into the Slaclware-15.0 login prompt I get
>
> "Error: Can't open display"
> "Error: Can't open display"
>
> What display is this referencing?
> (NB. no-one has logged-in at this point)

The error message "Error: Can't open display" seems like an output of
some X program unable to start because X has not been started. I suppose
that you by "login prompt" men a terminal text login prompt? Or did you
configure your system with runlevel 4 and mean a graphical login like
SDDM?

Did you add any X program to any startup files like /etc/rc.d/rc.local?

regards Henrik

[bad sector]

Yes I do mean a prompt and no, there's no login-manager. Slackware is the only distro on my machine that (default outta-the-box) handles the launch as Linux was meant to handle it. Just a prompt is all and IF I want to start X then I do 'startx'. Even as a typical mouse-slave there are still times when I want no graphics running. I'm not booted into Slackware right now, there are some commands in ~/.profile but seeing that I still haven't logged in when the error pops up...

I ran a string search from the outside against the entire Slackware partition for "Can't open display" asci/binary and it returned two yards of instances but that don't help me any. It would be so easy if devs prepended every error message with the outputing file path. Nothing is crashing though, it's just that it's irritating.

[Jimmy Johnson]

On 09/14/2022 05:59 PM, bad sector wrote:
>
> On booting into the Slaclware-15.0 login prompt I get
>
> "Error: Can't open display"
> "Error: Can't open display"
>
> What display is this referencing?
> (NB. no-one has logged-in at this point)

Well, slackware had a resent /etc/inittab update.

Can you login as user and type: startx ? If you can, then go to
/etc/inittab and change the 3 to a 4 so it will start on reboot.
--
Jimmy Johnson

PCLinuxOS - AMD A8-7600 - EXT4 at sda8
Registered Linux User #380263

[bad sector]

On Thu, 15 Sep 2022 18:27:46 -0700, Jimmy Johnson wrote:

> On 09/14/2022 05:59 PM, bad sector wrote:
>>
>> On booting into the Slaclware-15.0 login prompt I get
>>
>> "Error: Can't open display"
>> "Error: Can't open display"
>>
>> What display is this referencing?
>> (NB. no-one has logged-in at this point)
>
> Well, slackware had a resent /etc/inittab update.
>
> Can you login as user and type: startx ? If you can, then go to
> /etc/inittab and change the 3 to a 4 so it will start on reboot.

But I don't want to start a graphic login thing at all. Runlevel 3 has
been working just fine and is still what I want, it's just that this error
message was never there before, I haven't changed anything and everything
is working same as before as far as I know, but I don't like unexplained
error messages :-)

[Henrik Carlqvist]

On Thu, 15 Sep 2022 08:48:01 -0400, bad sector wrote:

> On 9/15/22 01:44, Henrik Carlqvist wrote:
>> On Thu, 15 Sep 2022 00:59:22 +0000, bad sector wrote:
>>
>>> On booting into the Slaclware-15.0 login prompt I get
>>>
>>> "Error: Can't open display"
>>> "Error: Can't open display"
>>>
>>> What display is this referencing?
>>> (NB. no-one has logged-in at this point)

>> Did you add any X program to any startup files like /etc/rc.d/rc.local?

> there are some commands in ~/.profile but seeing
> that I still haven't logged in when the error pops up...
>
> I ran a string search from the outside against the entire Slackware
> partition for "Can't open display" asci/binary and it returned two yards
> of instances but that don't help me any.

Before anyone has logged in, the only things that has been run are the
kernel itself and /sbin/init which runs files in /etc/rc.d as described
in /etc/inittab.

Some of the files in /etc/rc.d will give an output. Even if those scripts
themselves do not echo "Error: Can't open display" they might call some
program which does give that output. It might be easier to find the cause
of that output by looking at other outputs before and after, where did
those outputs come from? For example, the file /etc/rc.d/rc.M starts by
doing echo "Going multiuser...", does "Error: Can't open display" come
before or after "Going multiuser..."?

regards Henrik

[John McCue]

bad sector <forgetski@postit_invalid_.gov> wrote:
> On 9/15/22 01:44, Henrik Carlqvist wrote:
>> On Thu, 15 Sep 2022 00:59:22 +0000, bad sector wrote:
>>

<snip>

>
> Yes I do mean a prompt and no, there's no
> login-manager. Slackware is the only distro on my machine
> that (default outta-the-box) handles the launch as Linux
> was meant to handle it.

This is a bit confusing to me, some questions:
1. Did you do a Full Install ?
2. After the Full Install, did you remove some packages ?

If so that is probably the issue.

If you retained all packages from Slackware, try deleting
file $HOME/.Xauthority

Also before doing a 'startx', execute 'xwmconfig' and select
twm. If that works the issue is probably with settings in
your desktop Environment.

<snip>

> there are some commands in ~/.profile but seeing that
> I still haven't logged in when the error pops up...

What commands are in ~/.profile ?
Are you trying to start X programs in ~/.profile ?
X programs should be started via ~/.xinitrc in your case.

<snip>

HTH
John

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

[bad sector]

On Thu, 15 Sep 2022 00:59:22 +0000, bad sector wrote:

> On booting into the Slaclware-15.0 login prompt I get
>
> "Error: Can't open display"
> "Error: Can't open display"
>
> What display is this referencing?
> (NB. no-one has logged-in at this point)

My apologies for having mislead all the well-meaning
and helpful group regulars!

The event rises BETWEEN login and doing 'startx'. My
Slackware installation is the only one that permits
me to log in without any graphics being started. I
also noticed that the command prompt (otherwise set
to show current path) was showing where it had last
been directed:

cd /0/dx/homes/0Link/bashers-linked

in file ~/.profile to execute some custom utilities,
such as

/0/dx/homes/0Link/bashers-linked/my-xeyes-plasma.bsh

and this IS an X issue and gets executed BETWEEN login
and doing startx. Once I commented it out the error
message vanished.

Arises a secondary problem nonetheless. As I'm tinkering
with cannibalizing 7 distros so that all of them use the
same ~/.profile this leaves me without starting xeyes
in other distros also configured for Plasma (distros set
up for XFCE have xeyes in the panel as provided for).

So for now I've taken out the comment sign and will
live with the error message pending a better a way
to manage things. Ideally I would point /home/userMe
to the same single /mnt/somedata/userMe2Link directory
but that's farther down the road. For now I'm just
linking piecemeal those files that can be linked without
the risk of being burned at the stake and excommunicated.

[Rich]

bad sector <forgetski@postit_invalid_.gov> wrote:
> The event rises BETWEEN login and doing 'startx'. My Slackware
> installation is the only one that permits me to log in without any
> graphics being started.

> ...

> Arises a secondary problem nonetheless. As I'm tinkering with
> cannibalizing 7 distros so that all of them use the same ~/.profile
> this leaves me without starting xeyes in other distros also
> configured for Plasma (distros set up for XFCE have xeyes in the
> panel as provided for).

You should put X programs that need to be started upon X login in
~/.xinitrc not ~/.profile.

[Jerry Peters]

Test if $DISPLAY is set before calling xeyes:
[ -n "$DISPLAY" ] &&
/0/dx/homes/0Link/bashers-linked/my-xeyes-plasma.bsh

$DISPLAY isn't set in a terminal session.

[bad sector]

I did that, then I realized that I was using XFCE in Slackware
so I don't need the line in any script in this case :-))))

The distros I have set up for Plasma are Artix, Suse Leap/Tumbleweed, and
UbuntuStudio.

Suse has only an .xinitrc.template which I could replace with my .xinitrc
and Artix and UbuntuStudio have no such file but then none of these
plasma installations log me in at runlevel 3 anyway.

The long of the short is that all I have to do is move the line
to .xinitrc in Slakware and not include it anywhere in the other distros

Sorry about all this, I shudda stayed away from computing the last two
days.

[bad sector]

On Fri, 16 Sep 2022 23:46:33 +0000, bad sector wrote:

> The long of the short is that all I have to do is move the line to
> .xinitrc in Slakware and not include it anywhere in the other distros

ahemmm, i.e. include it in .profile or .xinitrc for all others

[Lew Pitcher]

/If you must/ place the startup of an X application in one of the
non-X script libraries (~/.profile, ~/.bashrc, ~/.bash_profile, etc)
then you should wrap it in a test for the value of $DISPLAY, as in

[ -n "$DISPLAY" ] && xeyes &
or
if [ -n "$DISPLAY" ]
then
xeyes
else
echo Not in X, cant start xeyes
fi


--
Lew Pitcher
"In Skills, We Trust"

[bad sector]

I inserted this conditional into .xinitrc which is linked in all my Plasma
installations (it's commented out in .profile which is linked in all my
installations). I tested with and without the IF loop. Artix is the only
plasma installation where this worked, in Suse and UbuntuStudio it worked
only before when it was still included in .profile. There's a lot of
divergence between distros in handling such things. I don't know how
Slackware would fare since I use XFCE there and xeyes-xfce is already in
the panel, so if it HAD worked I would have ended up with 8 eyeballs :-))

[Henrik Carlqvist]

On Fri, 16 Sep 2022 23:54:55 +0000, bad sector wrote:

> ahemmm, i.e. include it in .profile or .xinitrc for all others

Even the fact that you can test for the DISPLAY variable in files
like .profile or .bashrc does not mean that they are a good choice for
starting X applications. Better choices would be .xinitrc, .xsessionrc or
any autostart functionality of your desktop environment.

Your .bashrc will be run every time you start a new bash, this includes
every time you open a new terminal.

Also your .profile will be run every time you open a new terminal if the
terminal is configured to run as a login shell.

Would you want a new pair of xeyes for every terminal that you open?

regards Henrik

[bad sector]

I finally got it sorted out: included the call in .profile same as
before but conditionally. Now it works in every distro I use same as
before except that the eror message "Can't open display" in Slackware
now says:

"~/.profile: &$(#^%^ Idiot, in Slackware you've already set up for
xfce4-eyes-plugin".

[Aragorn]

On 17.09.2022 at 07:58, bad sector scribbled:

> On 9/16/22 9:49 PM, Henrik Carlqvist wrote:
>
> > Even the fact that you can test for the DISPLAY variable in files
> > like .profile or .bashrc does not mean that they are a good choice
> > for starting X applications. Better choices would be .xinitrc,
> > .xsessionrc or any autostart functionality of your desktop
> > environment.
> >
> > Your .bashrc will be run every time you start a new bash, this
> > includes every time you open a new terminal.
> >
> > Also your .profile will be run every time you open a new terminal
> > if the terminal is configured to run as a login shell.
> >
> > Would you want a new pair of xeyes for every terminal that you open?
>

> I finally got it sorted out:

No, you didn't. ;)

What you did was work around the problem because for some reason you
don't want to do it the right way, which is to add the command to start
X11-based applications to your ~/.xinitrc or — as Henrik remarked above
— the autostart functionality of your desktop environment. The latter
approach actually bears preference for starting something like xeyes —
~/.xinitrc is actually better left for setting things like your keyboard
repeat rate, or for (re)assigning certain keys on your keyboard, or
something similar.

~/.profile is not the place to start applications, least of all
applications that require the X server to be running. ~/.profile is
where you set environment variables for your user account that must take
effect upon login, and where you then also export them.

--
With respect,
= Aragorn =

[bad sector]

Thanks for the pointer.

I could make life difficult for myself and use this version of xeyes on
all my installations but seeing that an xeyes widget already exist for
XFCE I need the footwork only for Plasma. THE way to handle the issue
would have been for Plasma to have continued offering xeyes as a panel
widget as KDE did before. I've never used Plasma's autostart because what
I prefer is a default path where all distros execute user scripts
regardless of desktop used at the moment (there used to be one
before .profile came along). For example Suse offers many desktop choices
at login, I don't use this feature because I set my different distros up
to use XFCE or Plasma, but if I did it would become a dizzying round of
tweaks to set several desktops' autostarts up for xeyes and other helper
scripts. This said (Saturday being UbuntuStudio-day) I did just point this
Plasma autostart to the script and that works too. I'll see about other
distros later.

[bad sector]

the script is:

-------------------------------
#!/bin/sh
#sleep 10
xeyes -geometry 70x50+36+420 &
xeyes -geometry 70x50+1810+420 &
-------------------------------

In Tumbleweed if I point Plasma Autostart to it
it executes but when the panels show up xeyes disapear