Cannot execute shell or python scripts other than at command line

I have several very simple scripts (for example, write current date/time to a file). They don’t require any human input. They are executable and have #!/bin/… in first line. They run perfectly at command line. However, the FileManager (Thunar or Dolphin) will not execute the scripts (permissions problem), I am the owner, they are executable and they only write to locations in my home directory tree.

Next, they won’t run when added to autostart (startup or shutdown). There no error messages to give any clue what’s wrong.

I can add the scripts as applications in ~/.local/share/applications and they will run from the launch menu.

I’ve written lots of scripts on lots of other linux platforms in the past and never had this kind of problem. What is it that Manjaro/Plasma is requiring I do to be able to run scripts by double-click in a file manager or on DeskTop?

It would likely be of interest what that permission problem error message actually is.

They run in a terminal at that time.
They do not if you don’t start them like that by simply calling the command via file manager …
there is no terminal then - just the command

give it a terminal to run in

something like:
xfce4-terminal -e $yourcommand
would be the way to start it via file manager click …

Perhaps you could provide an example to illustrate the issue?

I get the point about running in a terminal, but (a) I’ve never found the need to do this before on other platforms, (b) one of the shell scripts does work with double-click in Thunar (datechk.sh runs DateChk.py), but the other (clipsave.sh fails to run ClipSave.py). (see code below.) So obviously, running in a terminal isn’t essential.

datechk.sh simply has this content:
python /home/pinebook/bin/DateChk.py
DateChk.py contains this:
#!/usr/bin python3
import time
t = time.asctime()
time_now = t[0:3]+','+t[8:10]+' '+t[4:7]+' '+t[20:24]+' '+t[11:19]
f = open('/run/media/pinebook/0101-076C/time.txt', 'w')
f.write(time_now)
f.close()
clipsave.sh contains this:
python /home/pinebook/bin/ClipSave.py

(note how this is very similar to the other shell script)

ClipSave.py contains this:
#!/usr/bin python3
import datetime
import pyperclip
nas = '/home/pinebook/Documents/'
t = datetime.datetime.now()
name = t.strftime('%Y%m%d_%H%M%s')[0:15]+'.txt'
clip = pyperclip.paste()
print(nas+name)
f = open(nas+name, 'w')
f.write(clip)
f.close()

Attempting to run either python script in Thunar results in “Permission denied” but note they are executable and owned by “pinebook” (me).

I’m guessing that the filemanager has a setting that prevents it running certain scripts, but why is it OK to run a shell script that runs a python script, and not the python directly? And why do almost identical shell scripts behave differently?

Incidentally, I’m ot using XFCE, I’m using Plasma, so if I did want to run in a terminal I’m not sure what the command would be.

What is rather annoying is that other than “Permission denied” there are no error messages (at least not that get reported to the user). Is there a way to get debug info?

Forgive me if the post formatting isn’t quite right, I’m not familiar with it yet and haven’t found a preview option.

That is not a proper script then?
(it has no shebang)

Same as above.


Im a bit surprised either runs at all.

The should both have something like this in the header

#!/usr/bin/env bash

(something like #!/usr/bin/bash or #!/bin/bash is maybe more conventional, but modernly the env iteration is encouraged for interoperability [could even run on osx])


PS.

Any true script you would just execute. ex;

./myscript.sh

You can also help it along with something like

bash myscript.sh

PPS.

The preview should be just to the right of your editing window.
If your post editor view is a floating rectangle without a preview then you can click the :fast_forward: (two right arrows) in the bottom-right corner of the editor.

Again, I hear what you say, but the practicality is that the shebang makes no difference to the behavior I described. I used #/bin/bash as that’s what I’m familiar with and I’m not up to date with the latest recommendations (its about 10 years since I did any Linux programming/admin).

Re the preview, there isn’t any such button. There is one icon with no caption but that is for a submenu of options, none of which has preview. I’m using Firefox so I’d expect it to be pretty standard. Interestingly there is a “Welcome to Manjaro Linus Forum” box at bottom right. Maybe that is obscuring the preview button. It has a “esc X” in the box that disappears when the mouse pointer is over it. Ahh, yes, closing that (with the button that disappeared on hover) revealed the two arrow icon (which also disappears on mouse hover!). Wearing my old software test engineer hat, I’d say the design needs a little improvement! Never mind, back to the point of this thread…

So with a shebang* and with the script marked executable** … it does not run ?

*

#!/bin/bash
python /home/pinebook/bin/ClipSave.py

**

chmod +x clipsave.sh

What is the terminal output* ?

*

./clipsave.sh

One script runs (datechk.sh) the other appears not to (but without some sort of feedback, I don’t know if its the shell script that doesn’t run, or the python script it is executing.

ls -l … (I already did chmod +x ages back)

-rwxr-xr-x 1 pinebook pinebook 510 Sep 21 14:17 Clipsave.py
-rwxr-xr-x 1 pinebook pinebook  49 Sep 22 00:00 clipsave.sh
-rwxr-xr-x 1 pinebook pinebook 206 Sep 18 20:21 DateChk.py
-rwxr-xr-x 1 pinebook pinebook  50 Sep 22 00:00 datechk.sh

All executable (and Thunar shows that in the Properties view of each file).
I don’t know what else to do.

An update on this… I put “touch testfile” before and after the python execution command and in both cases the file was created, so I know the shell script runs. Its the python script that isn’t running (ClipSave.py). Remember, DateChk.py runs ok.

Then maybe add some basic error handling.

#!/bin/bash
echo "Bash script started!"
error_handler() {
   echo "Error: ($?) $1"
   exit 1
}
python /home/pinebook/bin/ClipSave.py || error_handler "ClipSave.py failed, Line: ${LINENO}"

Now what is the output of

./clipsave.sh

Oh no! I just spotted the problem… the file was Clipsave.py not ClipSave.py !!
This was a slip in moving stuff around earlier today (yesterday).
So the only issue now is, why can’t Thunar execute the python directly?
I suppose it doesn’t matter since the shell scripts can run them, but I’d like to know what’s going on.

Oh yeah, I shoulda noticed that!

Do you have thunarx-python installed ?

The other remaining question is, why won’t the datechk.sh script run when it is in the autostart shutdown location?

I didn’t specifically install thunarx-python. I’ll check that. And even if that is the problem with the filemanager exec, the above queation remains.

What does this mean?
Where are you putting it // how are you setting that?

Usually systemd would be employed for this.

But if you are using Plasma you can also just use

System Settings > System > Autostart

And the “Add…” button allows you to add the script as “Add Logout Script” which should run on Log Out and may or may not be acceptable for your use-case.

(It is not clear whether you need this to run at the end of graphical session, or particularly right before powering down or …)

OK, first, thunarx-python was not installed, but it is now. Makes no difference, Thunar won’t run python scripts directly (Permission denied).

Next, yes, I already did the

System Settings > System > Autostart

so I’m pretty sure its in the right place. I just couldn’t remember where it actually gets placed. But its in .config/plasma-workspace/shutdown/ and executing the script in that location works. I’ve made sure it now has a shebang but to test it again, I’ll have to shutdown so it’ll take a while to get back to this thread.

I did start to explore systemd but I was put off by the size of the manual!! I use RISC OS most of the time and to do similar tasks its a simple drag and drop but apparently, even creating a desktop icon for running a prog involves wrinting a desktop entry file. I’ve done it (I modified and example), but what a nightmare.

Re the autostart, the intent was to have the DateChk.py run on logout, The reason is that I want Linux to record the last time it was in use. Then, when the pinebook is booted into RISC OS, a date check runs to compare the system realtime clock with the last time linux ran. This is necessary because after linus has run, the reatlime clock, as read by RISC OS, can jump days or weeks (leaving time part correct). My RISC OS prog corrects the system clock based on whether or not linux ran or RISC OS ran last. Its a hack but I’m tired of having to check and set the clock on every boot. Of course, it’d be nice if ntp could be used, but the date is so far out that ntp won’t attempt to correct it.
Thanks for your help so far. I’m going to reboot now…

I have a question for you: any particular reason you have Thunar on a Plasma system? … this could be causing some conflict, or other issue(s), since file-managers like this are often quite integrated with the actual Desktop Environment.

I don’t know if this is actually the case with Thunar but I’d suggest trying it on a system without Thunar installed e.g. a Virtualbox VM and see how it works there.

Update after reboot… the shebang made the difference in the autostart shutdown execution. So DateChk.py gets run by the shell script datechk.sh. Lesson learned.

Re Thunar, I tried various file managers (and I have several installed). I found Thunar the least onerous, and it handles the Samba mounts pretty well, whereas the other file managers are cumbersome and sometimes unreliable. My opinion of all the Linux filemanagers is pretty poor compared to what I’m accustomed to on RISC OS. I’ve been testing a new RISC OS filemanager recently and I’m trying to encourage the dev team to do a linux build (its written in C++ so I don’t think it would be too difficult).

The biggest thing is that RISC OS has always implemented proper drag and drop (and cut/paste if you want) with multiple independent windows for directory contents. I haven’t found any linux filemanager that comes anywhere close to the same functionality and they all remind me of the early DOS days with disc commander or whatever it was. </end rant>

RISC OS is not a UNIX system, while GNU/Linux is. You cannot compare the behavior of one OS to that of another, and especially not given that RISC OS is a single-user system and therefore has no notion of POSIX file ownership and ditto permissions.

4 Likes

That should be #!/usr/bin/python

The bash scripts run the python scripts with python aka /usr/bin/python, so in that case the faulty shebang is just a comment.

EDIT:

To clarify, the shebang was trying to run the script with /usr/bin which is a directory, along with the parameter python3, of course that can’t work and would give an error about permissions.

python3 still exists for now as a symlink to python so it would work, as long as the path is correct.

Of course you are right, but the handling of ownership and permissions should have no impact on the ergonomic design of the file manager’s UI. Actually, ROX implemented the RISC OS concept of file management quite well and did so on a UNIX platform, so it can be done, Anyway, I suppose we ought not get into discussion of this on this forum, but as the question was asked as to why I’m using Thunar on KDE-Plasma, I answered.

1 Like

It’ll run if it’s run with an interpreter, like:

The hashbang just specifies the interpreter to use, making it possible to execute the script directly.