After copying myexentension#me.com folder to .../gnome-shell/extensions/ I'm executing this command on the terminal:
gnome-shell-extension-tool -e myexentension#me.com
Then, I restart my session with Alt + F2 and execute r, and everything works fine.
But can I start my extension only through the command line? Without Alt+F2+r? Without restarting my gnome-shell session?
According to some answers around the internet, sending SIGHUP to the gnome-shell process restarts it (i. e. killall -HUP gnome-shell), but I haven’t been able to find a clear source on this and couldn’t find the signal handling in the code. What I do know is that this should be exactly equivalent to Alt+F2 r:
busctl --user call org.gnome.Shell /org/gnome/Shell org.gnome.Shell Eval s 'Meta.restart("Restarting…")'
Because apart from a gettext call on the message, this is exactly what Alt+F2 r is bound to (see runDialog.js – search for _restart).
January 2022 update: Since Gnome 41, calling Eval is restricted and requires “unsafe mode” to be enabled, so by default this will no longer work. I’m not currently aware of a replacement for this particular usage.
Personally, I prefer a solid Alt+F2, r+Enter but maybe try disabling and enabling:
gnome-shell-extension-tool -d myexentension#me.com && gnome-shell-extension-tool -e myexentension#me.com
or
gnome-shell-extension-tool -r myexentension#me.com
Which may do the same thing. There's also gnome-shell-extension-prefs which you can use to do the same thing (and is typically hidden in Gnome for some reason).
Related
Is it possible to enter keyboard shortcuts into a bash script? For example, I have tried typing in ^d to substitute for control + d (logout) without success.
ubuntu#vfleet:~$ ^d
-bash: :s^d: substitution failed
ubuntu#vfleet:~$ ^D
-bash: :s^D: substitution failed
I am using screen to run a django development server in the background. One of the commands to run a particular screen as a daemon is control + a + d. The goal is to be able to enter in control + a + d into a bash script. For example:
python manage.py runserver
^a + d
Is this possible?
Edit:
A valid method of avoiding the keyboard shortcut in screen is linked by Eric Renouf in the comments below. screen -d -m sh -c "python manage.py runserver" will start a development server as a daemon. This is a great solution for my particular problem, but it would still be nice to have a solution for the original question at hand.
xdotool package is the solution here.
xdotool key ctrl+d
Full reference
You probably should just start the command without attaching to the screen session in the first place, like
screen -d -m python manage.py runserver
but if you can't do that for some reason, you could detach from a screen session you're currently in by doing:
screen -S "$STY" -X detach
screen saves its current session info in STY, so we'll use that to make sure we're interacting with the correct session (in case there are many). Then we'll use -X to send a command to that session, in this case our command will be detach which will detach all the attached sessions, including the one used to execute that command
So while this doesn't actually send key strokes, it does highlight that there is often another command that you can send to accomplish your goals. Here detach takes the place of ctrl+a+d. Sending quit or running exit could often replace ctrl+d.
Another work-around would be to use expect which you could then use to send the strings containing control characters or hex values of them.
I'm doing my project and I need to log keystrokes system wide in macOS. So, I turned over to GitHub and found Swift-Keylogger. The only problem is I can't quit the Terminal while the program is still running.
Is there any way to not to run this in terminal or closing the terminal window instead of creating a mac app like here.
Note: There are some mac app style executables in github but they are not providing the output I want and some need additional permissions.
Instead of running the executable like ./Keylogger use nohup ./Keylogger &.
You can quit the Terminal after executing the command.
To kill the Keylogger, run ps -e | grep "Keylogger" to get pid and kill -9 pid.
P.S. I thought of adding it as well as running at startup but I'm too lazy to update the repository.
I am using this command kill -s SIGINT ps on the command line and it works (the process is eliminated), but when I use that command on a SHELL script it doesn´t work and it shows this error message kill: SIGNIT: invalid signal specification. How can I solve this. Thanks
Error messages exist to give developers, and also users, a clue when something goes wrong. I suspect that you're mistyping SIGINT as SIGNIT. The error message you're getting is consistent with a typo in your statement.
I feel like this shows poor research effort because if you had read the error message before asking help, you would have figured it out.
I would like to answer this because I solved the similar problem recently. When you call kill -s SIGINT, you may use sh to run the script. Unfortunately, sh which is different from bash(linux shell kill signal SIGKILL && KILL) will run in compatibility mode and not recognize SIGINT.
The best solution is to use /bin/bash explicitly. By the way, #!/bin/bash doesn't work when you sh the script, either.
Hope it helps.
It's possible that the shell executing the script is using a built-in "kill" command while your command-line shell is using an external binary, or vice-versa. Use /bin/kill explicitly and see if that helps be more consistent. kill -SIGINT is, I believe, the more common way of doing this (instead of "-s SIGINT").
Also, kill normally takes a process-id and not a process-name. Built-in vs external "kill" commands may also support (or not support) this differently.
Well, what I need to do actually is CTRL-Z out of a process that got started from insert mode in GVim.
My command :Cdprun executes cdprun.sh which runs a sudo-ed daemon. I can add & at the end of the sudo-ed daemon call to run in the background and that works but the user doesn't get prompted for a password. Instead I want to just CTRL-Z out of it but the keyboard interrupt doesn't work. Any ideas? Thx.
You generally have two options in this case: generic is using something like vim-addon-async mentioned by #Nicalas Martin or vim with built-in interpreters support: tcl with expect module, python with pyexpect, perl with Expect, maybe something else (note: all of the mentioned packages are not shipped with tcl/python/perl). Second is specific to current situation: it is backgrounding in the other place. From your explanation I guessed that you have a script looking like
#!/bin/sh
<...>
sudo run-daemon --daemon-args # Last executed line
, am I right? Than you can just put backgrounding in another place: not
sudo run-daemon --daemon-args &
, but
sudo sh -c "nohup run-daemon --daemon-args &"
Here is a script to deal with asynchronous command in vim. Not a perfect solution but could be a good temporary solution. http://www.vim.org/scripts/script.php?script_id=3307
I have a LaunchDaemon. When it runs, it checks if SIMBL is installed. If SIMBL is not installed, it uses NSTask to run /usr/sbin/installer on the SIMBL.pkg.
SIMBL's postflight script then tries to run a launchctl load command to start SIMBL's LaunchAgent immediately:
sudo -u "$USER" -- /bin/launchctl load -F -S Aqua -D user "${LAUNCHD_PLIST}"
This fails, because my LaunchDaemon's NSTask environment doesn't have $USER set.
If I have my daemon detect the current user with the System Configuration framework and pass it to NSTask with setEnvironment, launchctl bugs out on me:
Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1
I realize a daemon, by definition, should not operate in a user session. By the same token, Apple seems to recommend LaunchAgents as helper objects for LaunchDaemons, to do that user session work. Is there any way to get such an agent up and running immediately?
I have all the .plists in the right places (they start running after a reboot, the next time launchctl does its regular loading) so my first thought was to just tell launchctl to reload. But all the code to do that is commented out in launchctl.c:
// { "reload", reload_cmd, "Reload configuration files and/or directories" },
...
* In later versions of launchd, I hope to load everything in the first pass,
* then do the Bonjour magic on the jobs that need it, and reload them, but for now,
* I haven't thought through the various complexities of reloading jobs, and therefore
* launchd doesn't have reload support right now.
Oh how launchd drives me crazy....
To cut to the chase, after much study and experimentation, this is how I do it on 10.5+:
# If possible, tell launchd to start the LaunchAgent. This will fail on 10.4.
# $F[0] is the pid
# $F[1] is the username
# $F[2] is the first word of the command
ps -ww -A -opid,user,command | \
perl -nae 'if($F[2] =~ /\bloginwindow\b/) { system(
qq(launchctl bsexec $F[0] su $F[1] -c "launchctl load -w <your_plist>"))
}'
I have found no way to achieve this directly on 10.4. I cheat on 10.4 and just run the thing the LaunchAgent would have run, even though it has a GUI and you're not supposed to be able to do that (you can anyway in 10.4-10.6; you can't in 10.7). On 10.4, the LaunchAgent works correct after the next reboot.
The above code looks for loginwindow processes and uses bsexec to run commands in those contexts. Keep in mind that with Fast User Switching, there can be multiple contexts.
Some useful links:
Daemons and Services Programming Guide. You have to read it, but it won't actually answer any of the hard questions. But it will at least give you hints at where everything is located.
TN2083. This is a maddening document that raises as many questions as it answers, but is gospel and mandatory reading for anyone entering the abyss of launchd.
Starting/stopping a launchd agent for all users with GUI sessions. This has several other useful links and explanation.
IMO, launchd is one of the worst "great ideas" Apple has ever deployed. The idea is very useful, but the API is horrible.