I hope to add -clean when restarting. At present, the way I can think of is to change the ini, and then change it back after restarting. This scheme feels stupid -.-"
Related
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
This is a nightmare I've been plagued with for a while:
I have no idea what's causing it. I'm using iTerm2 (Build 3.0.10) and MiniTest, however I'm pretty sure this happens with other rake tests and some logging as well. I will try to update this question as I see it happen elsewhere.
EDIT: it happened on bundle output
I just started using fugitive in my workflow... very useful! But I've seem to have run into a weird annoyance that I'm hoping someone might have a solution to:
When I run :Gpush, sometimes control never returns to vi. Vi hangs on the output of git push until I Ctrl+C to kill "it". I've also tried installing vim-dispatch and, within tmux, the result is that the git push pane never closes. This is even more annoying because I've got to switch down to that pane to Ctrl+C it.
Oddly, if I ps, I do not see any git processes running, so I'm not sure what is hanging, exactly... but Ctrl+C does kill "it", whatever "it" is, and control returns to vi.
I've found a closed github issue that mentions similar behavior, but a solution was never posted... it appears the problem eventually just "went away" for the OP, so the issue was closed.
However, a second person replied to the issue some time later saying he was having a similar problem and it seemed to happen when git spawned some kind of "credential cache daemon". I'm not using a credential helper as he is, so that's not my exact issue... but that caused me to notice something else:
I have ssh configured to keep connections open for 5 minutes (ControlPersist 5m in my ~/.ssh/config). If I haven't pushed in a while, git push causes ssh to spawn a process to persist the connection. This triggers the issue. After 5 minutes, ssh exits, which will fix the problem and cause the tmux pane to close. If I do another push while the connection is still open, it works fine.
So, the problem seems to be when git spawns another process. This obviously doesn't cause any issues when I run git on the command-line, so why does it cause an issue here? And what can I do about it? I don't want to disable the ssh persistent connections because that's useful...
For anyone who stumbles upon this in the future, I've come up with a solution for my particular case where the ssh process is hanging vim: I disable the ControlPersist option, but only for git commands run inside vim via fugitive by setting the following option in my .vimrc:
let g:fugitive_git_executable = "env GIT_SSH_COMMAND='ssh -o ControlPersist=no' git"
It's ugly, and I'm sad that I have to disable the persistent connections, but it works.
I have been working with phpStorm and it had suddenly stopped showing suggestions for code completion. When i do Ctrl + space its behaving correctly by showing all the possible options in a drop down.
I have followed the below link and have did invalidate cache but still of no use.
PhpStorm code completion doesn't show core classes/extensions
My Setup is:
OS: Mac - 10.9.2 (Mavericks)
PHPStorm: 7.1.3
I just had the same problem, fixed it when I realized I mistakenly put PHPStorm in Power Save Mode. Click the little fellow on the bottom right of your PHPStorm window and switch that off
Indeed, the Power saving mode (File > Power Saving Mode) allow you to disable the code inspection functionnality.
However sometimes the PhpStorm code analysis failed and you lost your code completion. In this case you juste have to ask for a new code analysis (File > Synchronize [CTRL+ALT+Y]) or invalid the cache and force a restart (File > Invalid cache / Restart).
Hope that helps.
Invalidating the cache did not work for me, but this did:
Enable power save mode (File > Power Save Mode), then disable it.
If your are using a Linux distro (Ubuntu, Debian, Centos) etc, it is due to ibus.
Just change the Shortcut (run: ibus-setup and change to Super+Ctrl+Space for instance) and everything will be fine again.
Or (my favorite): uninstall ibus if you are not using it.
In a Debian/Ubuntu distro should be:
sudo apt-get remove ibus
Ctrl+Space autocompletion should be back.
It was power saving mode for me too. It's an option at the bottom of the File menu.
install a previous version
https://www.jetbrains.com/phpstorm/download/other.html
Worked for me after I tried everything.
I struggled with this for a few hours this morning. After invalidation of caches, a complete reinstall, etc.. nothing worked.
I closed phpstorm and removed the .idea folder in the filesystem. I then renamed the project folder and reopened it. Autocomplete was now working!
I noticed that phpstorm then created the old project directory in the background, even though I did not open it and put a .idea folder in it. Something is obviously corrupted here.
" ... stopped showing suggestions for code completion".
On mac you can invoke it by fn+ctrl+space.
Going to php-storm -> Settings -> Keymap -> Set Active Changelist you can see it is associated with ^+space.
on windows ctrl+space
Because of some dependencies, we close Windows Explorer during part of our installation. As an emergency safety, I'd like to make sure that the user has a shell if we fail. I thought that a type 34 custom action with 'Execute="rollback"' was what I wanted to do, but I don't seem to be smart enough to craft the CA.
Here's what I have:
<CustomAction Id="RestartExplorer"
ExeCommand="explorer.exe"
Execute="rollback"
Impersonate="yes"
Return="asyncNoWait"/>
I know I'm missing a directory element, but I don't know how to specify a platform agnostic way of specifying %windir%\system32. Using environment variables or scripting is not an option.
Thanks :)
I've never tried to kill Explorer during an install. Doesn't it autorestart? What if it restarted while you were installing?
Otherwise, if I did do this, I'd start it back up using the QuietExec custom action.
You would also want to start it as an immediate custom action after InstallFinalize. Note I didn't say commit because rollback can be disabled and commit wouln't execute.
Also the SystemFolder property is what you are looking for. Make sure you test this on 32 and 64 bit machines.
Killing explorer is the wrong thing to do in any case that I can think of. Instead of restarting explorer, I fixed the bug in our shell extension ;) Thank you for your help