Running Python Scripts at Startup

[patrikg]

When the execution bit is set, you telling the system that the file is executable.
It can be some elf(bin asm) file or it can be a script file. If it's a script file the system don't know what interpreter it should run.

So you need to tell the system what interpreter it should run.
You telling that in the first line, and that is also know as the shebang line.

You can see that line in lots of script languages, like in bash script.
Lets make an example.
First make this file.

nano test

Code: (bash) [Select]

#!/usr/bin/bash
echo "Hello World!"
Then you have to tell the system that the file is executable, you do that with the chmod command.

Like this:

Code: (bash) [Select]

chmod u+x test
Then you can test if it works with just the line

Code: (bash) [Select]

./test
The system loads the script and execute the first line program, and feeds the rest of the script to the interpreter in this case it's bash.
Why you have to add "./", that is just for telling the command interpreter that you trying to execute some file from your current directory.

You don't use the extension of the file to tell the system what interpreter to use. (like in Windows)
You just add the shebang line. And add the executing bit to the file.

You don't need to tell what interpreter to use when calling the script in the command line. You have provided that in the script.
And the filename can be what ever you like.
Unix don't use the filename extension of the file to determine what to do.

[xuraax]

@Patrickg

Thank you for the extensive explanation.

@Paul_123

In the end your suggestion to install py3.8serial.py worked for me.

My only, small, regret is that I have been unable when attaching headless, to "peek" into the still running script to monitor the progress. I have experimented with suggestions to use screen in the following 2 ways:

Code: [Select]

screen -S dummy -d -m python3test.py exec $SHELL
OR

Code: [Select]

screen -dmS dummy
screen -S dummy -p 0 -X stuff "python3 test.py\n"
These had some limited effect when included in the .profile method but none at all when using the bootlocal.sh method

 

[Paul_123]

Your best bet is to write to a log file.   Then just use tail to monitor.

tail -f logfile

If you don't need to keep the data, just write to the /tmp directory, but make sure you track the file size to make sure you don't fill up memory.   You can use python's logging functions to rotate the logs to keep the size under control.

[xuraax]

Your best bet is to write to a log file.   Then just use tail to monitor.

tail -f logfile

If you don't need to keep the data, just write to the /tmp directory, but make sure you track the file size to make sure you don't fill up memory.   You can use python's logging functions to rotate the logs to keep the size under control.

Does that log file need to have a special format?
The reason I ask is because my script already sends collected data in text format to a .txt file.

my test script opens up a text file and writes some text followed by CR every second until the loop ends after 100.

When I tried

tail -f test.txt

nothing happened until my script reached the end, at which point "tail" returned all the 100 lines in the file and waited there.

[Paul_123]

Logging is just a text file.  It’s likely because you are not flushing buffers writing to disk.  It’s easier to just use the built in logging

[patrikg]

You can run linux sync command to flush.

[Rich]

Hi xuraax

... my test script opens up a text file and writes some text followed by CR every second until the loop ends after 100. ...

After each write, do something like the following:

Code: [Select]

open status.tmp
write the same text to status.tmp
close status.tmp
os.system('sync')
os.system('mv -f status.tmp status.txt')Now anytime you want to see the current status, just:

Code: [Select]

cat status.txtYou won't have to deal with a file that keeps growing. No risk of reading a partially updated file.

[xuraax]

After each write, do something like the following:
......
......
You won't have to deal with a file that keeps growing. No risk of reading a partially updated file.

Thank you very much for this very interesting proposal. At this stage I think I will just forgo this requirement and concentrate on the main job of the script.

I take this opportunity to thank all who have contributed with suggestions.