Running PyInstaller v3.2 on Ubuntu 16.04, is it possible to get my bundled application to open a console for stdout? On Mac and Windows I can get this to work, as outlined in the options documentation. But nothing is mentioned for Linux. I've tried playing around with the -c flag, but that does not seem to have any effect. I also tried bundling it as a single file (-F) versus a directory, but neither seems to open a console for stdout...
Just for future reference, in Linux if you run a bundled app from the command line like a script, it will automatically use that same terminal as stdout ...
Related
When I start neovide from my applications and run :checkhealth I get errors that node and other commands are not available. But when I start it from my terminal there is no error for those commands. I tried to copy and modify the neovide desktop file to start just nvim and see if there if something wrong with my my neovide installation. But also starting just nvim as application prints the same errors.
I'm using linux with plasma desktop
TL:DR; add a path variable
Depending on your configuration, nvim will need to know the environment to run some executables (like it is with node in your example). An easy solution is to add the path variable to the exec command in the according .desktop file. I remember that I had the same issue with node not being recognized in a configuration using my plasma installation. On gnome node was recognized and healthchecks were good, so I thought I didn't need the extra path. Later on I realized that I had trouble with other commands. E.g. when using fdfind to complete path commands. Again I had to search what the reason was and it also was the missing path.
To give an example, let's say you are using zsh and want to start neovide with multigrid enabled, the Exec line in your desktop file could look like:
Exec=zsh -c "source ~/.config/zsh/.zshrc && neovide --multigrid %F"
im on macbook old version El Capitan 10.11.6 and my python script is 147bytes just for auto shutdown program but when i try to boundle it pyinstaller filename.py it done almost everything and end up with (codesign failure). do someone know how to solve this?
Try the following command in your terminal, type: sudo codesign -f -s followed by your script name test.py Make sure you are in your script file directory by using cd path to your file folder.
After that, you can run pyinstaller test.py However, I am using macOS Monterey Version 12.6 and am not sure if it will work on your current version. In fact, I don't even know how that command makes it work, but it works for me. If your app is a windowed app, such as the Tkinter app, your system may prevent it from opening; in that case, use the following command to disable the security system sudo spctl --master-disable . then you will see a new option available in your macOS Settings under Security; down there it says Allow app from: App Store, App Store and identified developer; and at last, you will see a new option "Anywhere" which wasn't there before; check that, and your app will work perfectly. hope helped
I have a local vscode installed for windows.
Afterwards I setup wsl-2 and use it as my shell.
When I tried to open a file with code using the code filename command, it installed vscode anew instead of using the local windows install.
Installing VS Code Server for x64 (054a9295330880ed74ceaedda236253b4f39a335)
Is there a way to point wsl to use the windows install when triggering it via the code command?
I don't specifically mind using either or, but settings/extensions etc. for one are not used by the other.
By checking with Git Bash where the location of code is when triggering it (type -a code) and comparing it to the ubuntu wsl shell, I came to the conclusion, that it is actually the same install that is being triggered, . I will have to check why some extensions do not seem to "carry over" though.
The code that is being triggered is a script, that behaves differently when being triggered from within WSL.
How about an alias?
# Set alias
alias code2='/mnt/c/Users/Username/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code'
# Open a file now
code2 file.txt
I installed the selenium webdriver using the following command:
$ npm i selenium-webdriver
Then, I created the directory D:\WebDriver\bin (and added the files geckodriver.exe and operadriver.exe to that directory) and added it to the system's PATH variables.
The PATH to the directory that contains both drivers was successfully added, as can be seen below:
$ printenv PATH
/mnt/d/WebDriver/bin/
$ ls "/mnt/d/WebDriver/bin/"
geckodriver.exe operadriver.exe
I am also able to run the geckodriver via cmd.exe (Same applies to operadriver):
C:\Users\user>geckodriver
1621873805268 geckodriver INFO Listening on 127.0.0.1:4444
When I try to run one example file (google_search) via:
/mnt/d/proj/node_modules/selenium-webdriver/example $ node google_search.js
I receive the following stacktrace:
Error: The geckodriver executable could not be found on the current PATH. Please download the latest version from https://github.com/mozilla/geckodriver/releases/ and ensure it can be found on your PATH.
The operadriver also cannot be found when setting up an example that uses the opera driver.
Worth mentioning is that I use a Windows Subsystem for Linux (WSL) and ran the commands (node, printenv and npm) in the terminal of that subsystem. The path variable was set on the Windows system and the required drivers were only installed on the Windows system. I can access the installed files on my windows system via the WSL terminal, but selenium still cannot find the specific driver(s).
When I run the above mentioned test file (google_search.js) from selenium-webdriver on the Windows system, it does find the web driver and works as expected. I still cannot figure out the reason why the driver is not being found in the WSL.
I was able to resolve the problem using the following well written article: https://qxf2.com/blog/setup-linux-testing-environment-on-windows-using-wsl/. By creating symlinks that point to the driver and the web driver executable, the driver and the web browser was found. For now, I do think it's easier to run the tests in cmd.exe, though, as it does not require these additional steps.
I am attempting to install RetroPie as an app on Raspbian Stretch and I am done except for creating a desktop shortcut for it. The problem is that the only way to open RetroPie seems to be running a command in the command line. I can’t do it in terminal because it gives me an error saying that it can’t initialize the window. Is there a way to run a command line command as a shortcut or am I going to have to find another way of doing this?
P.S. Here is the tutorial that I followed to install RetroPie:
https://www.makeuseof.com/tag/install-retropie-app-raspberry-pi/
Probably your shell (on the raspberry) is GNU bash. So read the manual of GNU bash.
You probably want (once) to edit some Bash startup file (such as ~/.bashrc) to define functions and aliases there, and you could add executable shell scripts somewhere in your $PATH. I recommend having a $HOME/bin/ directory containing your scripts and executables, and have $HOME/bin/ early in your $PATH.
I can’t do it in terminal because it gives me an error saying that it can’t initialize the window.
Perhaps you need some display server (such as Xorg or Wayland) running (with a desktop environment or a window manager). You could run Xorg on your PC (on which you could install Linux) and connect to the raspberry using ssh -X then remote applications running on your Raspberry are displayed on your PC. IF your Raspberry is directly connected to a screen (via HDMI) you might run some Xorg server on it.
Is there a way to run a command line command as a shortcut
Yes, by making a shell alias or shell function or shell script. You need to understand how they work and change or create some appropriate file using some source code editor (I recommend GNU emacs, but the choice is yours and you might use any other editor such as vim, gedit, etc...): functions and aliases could be defined in your ~/.bashrc; shell scripts would usually have their own file with a shebang under your $HOME/bin/...