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)

[Henrik Carlqvist]

Post by 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)

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]

Post by Henrik Carlqvist

Post by 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)

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

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.

[Henrik Carlqvist]

Post by bad sector

Post by Henrik Carlqvist

Post by 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)

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]

<snip>

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

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>

Post by bad sector
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

[Jimmy Johnson]

Post by 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)

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.

[bad sector]

Post by Jimmy Johnson

Post by 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)

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 :-)

[bad sector]

Post by 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)

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]

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.

[bad sector]

Post by Rich

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.

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]

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]

Post by bad sector

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

/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

[bad sector]

Post by bad sector

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

/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

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]

Post by bad sector
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]

Post by Henrik Carlqvist

Post by bad sector
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

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]

Post by Henrik Carlqvist
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?

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.

[bad sector]

Post by Aragorn

Post by Henrik Carlqvist
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?

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.

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]

Post by bad sector

Post by Aragorn

Post by Henrik Carlqvist
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?

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.

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.

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

[Jerry Peters]

Post by bad sector

Post by 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)

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

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.