I have a python script. This script is essentially my own desktop/UI. However, I would like to replace the default Raspbian (Raspberry Pi linux distro) desktop enviroment with my own version. How would I go about:
Disabling the default desktop and
Launching my python script (fullscreen) at startup?
This is on the Raspberry Pi running a modified version of debian linux.
(Edit: I tried making a startup script in the /etc/init.d directory, and added it to chmod, but I still can't seem to get it to start up. The script contained the normal .sh stuff, but also contained the python command that opened the script in my designated directory.)
Ah bah, let's just give a quick answer.
After creating a script in /etc/init.d, you need to add a soft-link to the directory /etc/rc2.d, such as sudo ln -s /etc/init.d/<your script> /etc/rc2.d/S99<your script>. Assuming, of course, that you run runlevel 2. You can check that with the command runlevel.
The S means the script is 'started', the number determines the order in which processes are started.
You will also want to remove the entry from rc2.d that starts the graphical environment. What command that is depends on how your pi is configured.
Related
I am trying to make a command-line application using Python.
I have developed the program, but I see that my program gets executed in cmd.exe, which seems to be the default for that kind of programs.
But I would like a finer GUI, like that of Windows Terminal. But the problem is that, Windows Terminal is not installed in all Windows computers as is cmd.exe.
Because of this I would like to request you that to suggest any methods to make the GUI or a method to bundle up Windows Terminal with my Python program.
So first we need to understand some terminology. You compare Windows Terminal and cmd.exe, but those are actually two entirely different types of applications. CMD is the old Windows shell. It runs inside a terminal emulator (a.k.a. terminal). There are multiple terminals that it can run under in Windows:
By default in Windows 10, it runs in the legacy Windows Console Host. This is the nearly 30 year (maybe more) old terminal for Windows.
CMD can also run inside Windows Terminal, the replacement terminal by Microsoft that is available to install in Windows 10 or Windows 11. Under Windows 11, it can become the default terminal for Windows.
When you ask Windows to run a console/terminal app, like your Python CLI app, Windows always runs it in its default terminal -- Under Windows 10, that is always the Windows Console Host. Under Windows 11, it may be either Windows Console Host or Windows Terminal, depending on the user configuration.
But there are also multiple other terminals that can run your CLI Python app in Windows:
Some of the more popular are:
ConEmu
Cmder
MobaXterm
You can find others listed in this blog post.
So it's really not that your app runs in CMD, but that your app runs in Python (the interpreter), which is running under CMD (the shell), which is running under Windows Console Host (the default terminal emulator).
Note that Python can also run under other shells (PowerShell, Linux shells under WSL, Nushell, etc.). These shells can also run in any of the terminals above. Or your Python CLI app can run as the top-level inside a terminal.
Ok, now that we've established some basics ...
But I would like a finer GUI, like that of Windows Terminal.
It's a bit unclear what you mean by that, but there may be other solutions than trying to package Windows Terminal. Both the legacy Console and Windows Terminal should have similar capabilities for your application. Windows Terminal adds things like tabs for the user, but you won't have control over that in your application. Both Console Host and WT can be configured with the same Windows fonts.
One thing you can do in Windows Terminal that you can't in Console Host is define a Profile for your application, including the themes, background image, etc. that you want it to run under. Perhaps that's what you are asking for, but you don't specify that those capabilities.
suggest any methods to make the GUI
If you are looking to create a GUI in Python, consider building it using a GUI Framework rather than as a CLI application. You can even write a terminal emulator in Python, but that would likely be a bit overkill for this.
or a method to bundle up Windows Terminal with my Python program.
That's probably not a good idea. Windows Terminal works best when it is installed as a Microsoft Store app (a.k.a. UWP, Modern, etc.). It is not possible to bundle Microsoft Store apps with another application; just like you can't install another Apple App Store app automatically from another on iOS. It's also possible to install/run Windows Terminal as a traditional .exe, but that's not the default (or supported) way.
You might consider the following:
Have your main Python app be a "launcher" that checks to see if Windows Terminal is installed, perhaps by looking for the existing of the wt.exe.
If Windows Terminal is installed:
Check for the existence of your applications JSON fragment in the appropriate directory (see link). Install it if it doesn't exist.
Launch your application by calling something like wt.exe new-tab --profile <your_app_profile> to start or open a new tab in Windows Terminal with the profile you defined in your JSON fragment.
If Windows Terminal is not installed:
Recommend that the user install it. Open the Microsoft Store link to it.
If they choose not to, your launcher should still launch the CLI portion of the app -- Windows will use the default terminal, which should be Windows Console Host.
Provide the instructions for running the CLI portion by itself (without the launcher) so that users of other terminal emulators can run it inside their preferred environment.
I have a bunch of useful Python3 scripts that I use in different OS environments. They run fine when called from the terminal but I want to run them from both Windows Explorer and OSX Finder. In Windows, that is not an issue as the *.py files get associated with the installed interpreter.
For OSX, I am having some problems. I tried using the shebang line.
#!/usr/bin/python3
But Finder doesn't recognize it as a script. How do I make Finder recognize *.py files as scripts? I am interested in maximum portability with as few OS modifications as possible.
Also I explicitly specified the interpreter location above. It will be in different locations for different OSes. Is there a way to make it multi-OS so that if it doesn't find it in one location, it will try another? Say if I want to run it from one of Ubuntu's GUI File Manager.
EDIT: Here's more info on my use case. I want to go to a new computer and git clone my repo of Python3 scripts and be able to run them from within the GUI file manager with minimal changes to the new computer.
To make the script more portable use #!/usr/bin/env python3 as shebang. Side effect will be that it will run the first python3 interpreter it finds in the $PATH (Unix StackExchange question on that subject)
To run the script from the finder try to chmod the file. i.e.
chmod +x FILE
Found another possibility here: Link to the Blog
Make this the first line of your Python script "#!/usr/bin/env python"
Change the extension of the script file to ".command" i.e. my_python_script.command
In Terminal make the Python script file executable by running "chmod +x my_python_script.command"
Now when you double click the Python script in Finder it will open a terminal window and run.
Alternative I found would be this but it needs system modification: Superuser question
How can i run a python script at startup with xubuntu 15.04?
I want to run a script that reminds me of things,like backup,buying thing,calling somebody.
I already have the script,i just need it to start at startup.
(Python 3.4)
As far i know, xubuntu 15.04 uses systemd.
All the tutorials i found,are for init.d or upstart.
I need one for systemd
Found the answer.
You have to go Configuration/Systemsettings/Session and Startup,
and add the program.
I am trying to automate running a python script every minute on my mac, from a virtual environment. I am convinced that I don't properly understand permissions, paths, and environment variables in some crucial way that is preventing me from figuring this out.
I am an admin user with root rights enabled. I run HomeBrew, PIP and Virtualenv to manage python packages and virtual environments for different projects.
I would like to do the following every 60 seconds:
$ source /.virtualenvs/myenvironment/bin/activate
$ cd ~/desktop/python/
$ python myscript.py
$ deactivate
I have tried:
(a) writing my own plist for Launchd - and I believe these documents were well formed.
(b) programs which manage Launchd daemons and agents for you (both Launch Control and Lingon).
(c) I have tried simply editing the crontab (only lets me if I use the sudo command).
The python script, which works on command, pulls data from an online source and stores it in a sqlite table. I can tell the cron isn't running because the sqlite db isn't being touched.
Any thoughts would be enormously appreciated.
You don't say exactly what you tried with launchd and cron, but I'd bet you weren't using either of them correctly. Both are oriented toward running single, isolated commands (/programs), not sequences of shell commands. While it's possible to do this with a single cron job or launchd item, it's going to be messy. The simplest thing would be to write a shell script that does the sequence you want (be sure to include a shebang at the beginning, and enable execute permission on the script with chmod +x /path/to/script), and run that from either cron or launchd:
#!/bin/bash
source /.virtualenvs/myenvironment/bin/activate
cd ~/desktop/python/
python myscript.py
deactivate
I would not recommend using Automator to wrap the command sequence; it's designed for GUI-based scripting, and may not work right in a background-only job.
I have had this exact same problem and have recently solved it. Look here for the steps I took. Basically it deals with the shell needing the PYTHONPATH, not just the PATH.
So I'm still not sure why I can't configure Launchd or the Crontab to work for me: I still suspect it has to do with the environment variables.
If anyone else is having a tough time with this issue, I suggest creating an Automator application that runs the shell script you want to run, then use Lingon or Launch Control to run the Automator application file at whatever frequency you desire.
I've seen a lot of scripts for daemonizing a python script in linux, but not much information about how to use them. Could anyone guide me on this?
I currently have a lengthy python script that listens on a socket for an incoming message, if it's the correct format accepts it and then stores it into the database. The script itself just opens the socket and then listens on a while true (which does the job!) and does all the work in there.
To daemonize it, would I have to modify my current script or call it from a separate script? I've seen examples of both but got neither to work.
Also, I'm using virtualenv which might the root of my problems, any hints on using this with daemonized scripts?
Create a shell-script that activates the virtual environment, and runs your Python script in the background.
Also, there should by a python module in the virtual environment that you can import and activate the environment from too. I don't have virtualenv working at the moment, so I can not check where it is, but search for activate (or something similar) in the virtual environment and you should find it.
Edit: Added a minimal Debian init.d script
The absolute minimal script needed to start a daemon when the computer boots, is this:
#!/bin/sh
/path/to/program &
The & makes the program run in the background, so it wont stop the rest of the boot process.
For a more complete script, copy /etc/init.d/skeleton and edit the new file. The important part to edit is the block at the beginning (between ### BEGIN INIT INFO and ### END INIT INFO, which is used by the update-rc.d program), and the NAME, DAEMON and DAEMON_ARGS variables. Hopefully that should be all that's needed for making a startup-script.
Activate the script as this:
sudo update-rc.d <name of script> defaults
sudo update-rc.d <name of script> enable
And to start it:
sudo update-rc.d <name of script> start
The <name of script> is just the name, not the full path.
script
export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
exec start-stop-daemon --start --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script
When you need to run an application in a python virtualenv, you can either 'activate' the virtualenv, or use that environment's unique python command.
As per the website "If you directly run a script or the python interpreter from the virtualenv's bin/ directory (e.g. path/to/env/bin/pip or /path/to/env/bin/python script.py) there's no need for activation." - http://pypi.python.org/pypi/virtualenv
I also have some python modules that were compiled from source. Those need to be in the PYTHONPATH environment variable. That could be part of your virtualenv activation, done with virtualwrapper, or explicitly called (as I do below.)
Calling the program from an UPSTART job works as well. My example is above.
On an Ubuntu 10.10 instance on Amazon EC2, I had better luck with the start-stop-daemon command.
I also struggled with some of the other upstart 'stanzas.' I am calling a python application with a specific virtualenv and some parameters to my executed program.