using ./ to run bash script and .py files

I think this is the correct subforum for this question. I recently retired my last 15.0 server… most of my servers are running 15.2 and 15.1 - all are vanilla KDE-plasma. (opteron 6380s and xeon x5680s) Most were set up with LEAP 15.2 on bare metal within the last several weeks but two have been running 15.1 for over a year.

Over the last couple of days, I’ve been trying to get a redeployed Dell R820 E5-4650 server running (to replace one of the 5680’s) and there are a couple of odd problems. On all my other OS computers, I can run bash and python script files in kde/konsole without prefixing them with ./ (I thought that was mandatory, actually, even if the script is in the current directory) but, like I said, it isn’t working on the new xeon server. I tried online-installing 15.2 three times. I think this is somehow related to the second problem…

The second problem has to do with Anaconda3 python. It seems to have self-installed correctly and the python command line in konsole responds correctly. Spyder throws a weird error related to the X server (plasma/desktop/applets/etc. seem nominal). The “X” error is:

~> spyder
No protocol specified
qt.qpa.screen: QXcbConnection: Could not connect to display :0
Could not connect to any X display.
~> which python
~> python
Python 3.8.5 (default, Sep  4 2020, 07:30:14) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>> quit()

YaST-hardware thinks it’s Matrox M-200 graphics chip (G200eR2 16MB) - kernel driver mgag200. xf86-video-mga, -fbdev, and -vesa are installed along with xorg-x11-driver-video. (I assume nouveau is installed and running since plasma is working apparently normally.)

Anaconda/spyder works as-advertised on my intel laptop, one of the xeon servers (through a cheap nvidea-clone PCIe video card), and on the opteron boxes (again through cheap nvidea-clone PCIe cards - all using plasma KDE).

This particular server (Dell R820) is apparently well-known to be finicky about its use of the PCIe 3.0 specification - so none of my cheap 1x or 4x PCIe cards work with OpenSuSE on this machine (I have no idea if this is related to the X error). What makes me think it might be related is that 15.2 installs fine using a cheap graphics card in the R820, but when GRUB first starts up on first-boot after install, I get the “Welcome to GRUB!” message - then a black screen and it never boots 15.2. (So I’m using the built-in matrox video.)

Very confusing. BTW: There’s yet a third problem - but two is enuf 4 now.

Do any bits of this sound familiar to anyone? Thank you for any help.

Get a cheap intel card if the Nvidia cards aren’t working, or use nomodeset to install and see if that helps. Those legacy matrox cards are probably on the way out, and likely never designed to run the likes of Xorg/Wayland/Plasma…

For your scripts, in in ~/bin have the whole shebang present and set to executable they will run without issues, else if in some random directory AND have the whole shebang and executable will run with ./<some_file.

An example…


print ("It runs")

It runs

bash: ./ Permission denied

chmod 0755

./ line 1: syntax error near unexpected token `"It runs"'
./ line 1: `print ("It runs")'


print ("It runs")

It runs

mv bin/

It runs

Hi Malcom - thanks - is there some setting in kde/konsole/bash wherein it is instructed to require or not-need the “./”?

“nomodeset” - that sounds familiar - can I use that on the boot line or elsewhere, or is that during the install splash-screen only?
I pulled two of the video cards I tried out of my xeon 5680 boxes, so I know they worked fine there with opensuse 15.1/15.2.

Yes, that’s how it behaves on all my other servers and laptops - just not this server. I’m stress-testing it now.
I’m wondering if OS installer did some slightly different on setup than on my other servers.

I do always set my script files to executable. I don’t really have the option of putting all relevant scripts in ~/bin.
As soon as the stress-test finishes - I’ll give you an example.

Yes, if the script it resides in the directories listed in the output of;

echo $PATH

AND is executable (0755) AND has the whole shebang eg;

which bash

Line 1 of script to use bash

 which sh

Line 1 of script to use sh

:~> ls -la `which python`
lrwxrwxrwx 1 root root 9 Feb  4 14:06 /usr/bin/python -> python2.7

:~> ls -la `which python3`
lrwxrwxrwx 1 root root 9 Feb  2 09:13 /usr/bin/python3 -> python3.8

Line 1 of script to use python3

Note, if you have scripts that call /usr/bin/env python as the whole shebang, then they need fixing!

Yes, at install, either edit the grub boot option (press the e key) or just install in text mode, it’s an option down the bottom… I would also disable plymouth.

After quiet, add;

quiet nomodeset plymouth.enable=0

Here’s an example (15.1 on a xeon 5680 server). I didn’t do anything I’m aware of to make it always run scripts w/o the “./” prefix.
The 00_Python subdir isn’t in $PATH (although the directory above it is in the path).

~/00_GCMs/00_Python> dir 00__*.txt
-rwxr-xr-x 1 patti users 1.1K Sep  3 13:49 00__Process.txt
-rw-r--r-- 1 patti users 1.8K Jan  3 12:26 00__Process+upl.txt
-rwxr-xr-x 1 patti users 2.3K Jan 29 14:11 00__RunEMS+Process.txt
-rwxr-xr-x 1 patti users 3.0K Jan  3 08:51 00__RunEMS+Process+upl.txt
-rwxr-xr-x 1 patti users 1.1K Apr 30  2020 00__TestProcess.txt
-rwxr-xr-x 1 patti users  127 Feb 13 19:12 00__upl2.txt
-rwxr-xr-x 1 patti users 1.6K Feb 13 15:27 00__upl.txt

~/00_GCMs/00_Python> 00__upl2.txt
Start uEMS Upload-only Script At:
Sat Feb 13 19:13:30 MST 2021
Sun Feb 14 02:13:30 UTC 2021
Finished UPLOADING Vids at:
Sat Feb 13 19:13:30 MST 2021
Sun Feb 14 02:13:30 UTC 2021

~/00_GCMs/00_Python> cat 00__upl2.txt

#! /bin/bash
echo 'Start uEMS Upload-only Script At:'
date -u
echo 'Finished UPLOADING Vids at:'
date -u
exit 0

~/00_GCMs/00_Python> echo $PATH


Does the following command find it;

which 00__upl2.txt

Thank you! So when I boot monitoring the matrox built-in VGA, grub works, and briefly I can get the boot/splash screen (with the little animated turning thing) through the add-in video card at 1080p, then Opensuse turns off the add-in video card and goes back to using the matrox VGA. Do you think reinstalling with nomodeset (and turning off the built-in matrox VGA) would fix this? Would I loose 1080p?

I guess that’s not actually important - what I’m trying to understand is the weird error with not connecting to X display:0
I’m sort of assuming this is a video-card problem, but that’s just a wild guess.

Boot with both nomodeset and disable plymouth grub options, does that help? Yes, switch back to the on-board card first and see how it goes with no extra card.

I’m not sure this will be useful to any Wizards, holders of Deep Magic, etc., who read this thread, but I changed 2 things and it worked: (1) installed 15.1, and (2) switched to ext4 (from the default BtrFS, and used separate home/root partitions).
Now I no longer receive the the ‘unable to connect to X display:0’ error even though I’m still using the matrox VGA (on the mobo of this server) - Spyder works fine.

How do you like that? :confused:

One problem solved. I guess. Any solution thoughts appreciated!
Since this is just a compute node, I guess I can leave 15.1 installed, essentially forever. But there are a LOT of servers out there like this one, and LEAP will be around for a while, too. The actual issue(s) would likely be worth knowing. Maybe simple as not having the right software installed? Anaconda3/spyder is supposed to be stand-alone, but the X:0 error seems pretty unusual - that’s deep within the system, no?

More likely kernel/driver support for that legacy card…

Hi Malcom - it wasn’t just a graphics card issue (I’m still investigating that - it may be a PCIe issue). I was OK with running just the matrox onboard graphics, but for some reason that option has the X-server display:0 problem in 15.2. I wound up trying an install of 15.1 and that solved the display:0 problem with the matrox onboard graphics.

I’ll let this thread know how the PCIe investigation goes as it might be useful info for contributors to the Opensuse project, inasmuch as I’ve never seen this behavior on a server (intel or opteron) before.

Huh - could be - but that kernel/driver was OK b4 the transition 15.1 -> 15.2. Well, I guess folks do that and linux just evolves…

Years ago my research was “hamstrung” by the decision to remove the general class of “32-bit support” from the Yast installation code. (I had some crucial software that used stuff in the “32-bit support” meta-package - but I didn’t know what support it needed.) I couldn’t seem to get it working.

I complained and a while later “32-bit support” came back as a Yast option. (I was told it went away because they were trying to shrink the install code - not sure why - we’re up to our eyeballs in storage space since the 80’s). Now I can again install “32-bit support” when installing with Yast on bare-metal. Anyway, that’s just an example of how things can change behind-the-scenes from us users, so maybe someone messed with the Matrox driver support 15.1 -> 15.2. Or maybe there’s a minor hardware issue on my server that just happens to mess with the Matrox code. Dunno.

As far as cards go, I am trying to find a strict PCIe-3.0 card to see if that will work in this server. This server is 2x as fast as my xeon 5680’s and uses half the power - so that works out to 1/4 the power for the same calculations. :open_mouth: