Run a Applescript on a locked Mac by keypress or alternative options - macos

I have an Applescript written for a specific purpose that launches an application and performs a couple of tasks. I would like to be able to run this script by pressing a key on my keyboard, however, while the Mac is locked. (Note: Mac is only locked, not "asleep")
I'm open to alternative options, if such (or more efficient) options exist.
The above scenario is my "ideal" configuration, the only thing I don't have flexibility on, is that the mac must stay locked for this process.
I have full administrative access to the Mac.

I would suggest you use ssh to "get into" your Mac while the screen is locked and then run your script from the shell. You would probably use osascript for that if it is Applescript, by the way.
In order to do this, you will need to ensure the sshd is running on your Mac by going to the Apple Menu, then System Preferences then Sharing and check the box beside Remote Login.
In order to ssh into your Mac, you could use another Mac, or a PC or the free iPhone/iPad app called Terminus which is brilliant for remotely controlling machines via ssh.
Rather than have to run a command when you log in, a technique which I often use is to have a user who can only execute a specific function and the very act of logging in does that function and then logs the user out again. So, for example, if I wanted a login that can reboot a machine, I would create a new user called reboot and instead of that user having bash in /etc/passwd as his shell, he would have /sbin/reboot as his shell. Just a thought - YMMV.

I've tried this same thing and when the Mac becomes locked, normal processing will not occur but slow to a crawl, so I had to turn my screens off instead of locking my Mac. There is no way around it.

Related

On macOS how can I open a gui .app hidden or off screen?

I have a cross platform need to open a gui application programmatically, but keep it hidden from the user. Effectively, I want a command line driven interface to act as a wrapper over this gui app, and insulate the end user from seeing or interacting with it. The program is from a third party, I did not write it, and I can't edit it.
I can do this one way or another on Windows, on Linux, and (in theory) on older versions of Mac, but not the most recent ones. On Windows, I can use the native api ShellEx with a hide window parameter. It's very easy and straight forward. In Linux, I can can render a gui app to a virtual frame buffer (using xvfb).
On macOS, the open command has a --hide and --background option, but they don't have any effect (at least on this app...)
I tried changing the plist file and found that LSUIElement will hide the app from the docker, but it still shows up on the screen. LSUIPresentationMode=4 or 3 OUGHT to work for exactly this, but apparently that doesn't do anything anymore as of a few os versions ago...
I tried the approach of moving the .app off of the screen with AppleScript. That works, but you have to manually grant permissions for such a thing to occur via System Preferences. In prior versions of Mac, those permissions could be twiddled on the fly via sqlLite (so long as you had sudo rights), but now they blocked that too. You can only pull that off apparently through a process of disabling "SIP" and forcing a reboot. That is totally outside the realm of what I want.
I've tried using the xvfb approach on Mac (jumping through hoops to acquire the binary they use to include stock, and now dropped), but I'm not having luck with that. I don't think it's possible to direct a mac .app to another display is it? A .app does not render on X11 by it's nature right?
What other clever ways might there be to hide a third party app on a mac? (and that still works in most recent os versions!)

Is there a Mac App or command to autoconnect to SSH?

Right now I'm running a terminal with multiple tabs since I need to ssh into multiple servers to perform different tasks depending on the project. As I said I keep terminal up but it will eventually disconnect or some other hickup requiring me to either login back in or close and reopen terminal (and all my tabs/connections).
I'd like to either:
Open terminal type a command like "connect to webserver" and have it run the ssh command with password
Install an app that does this sort of thing and maybe has some extra functionality (not sure what that would be). Hopefully the app would auto connect and display windows for each connection I specify.
You should use vSSH Lite, Which is free for 2 tabs. Then you have to pay some amount.
Here is the link vSSH Lite

Logon-type wxpython app

I manage a number of Windows PCs which are used to control equipment. Each computer has a specific program installed which is what people launch to use that equipment. We want to require people to log in before they can access this program.
Currently, I have a wxpython app which just launches that executable when people log in with the correct credentials. However, you can just run the program directly and bypass logging on. I'd like to make a mock logon screen, ie, fullscreen and modal, which only goes away when you log in. Also it should not be able to be bypassed by alt-tab, windows key, etc. How might I accomplish this with wxpython?
There is no full proof way to do this on Windows. You can show a wx.Frame modally using its MakeModal() method. And you can catch EVT_CLOSE and basically veto it it they try to close the frame. However, if they have access to the Task Manager or even Run, they can probably get around the screen. Most users won't be that smart though. You can delete the shortcuts to the apps you want to launch with wx and that will force most normal users to use your login screen. It's only the smart ones who like to troll through the file system who will go around it.

Is there a way to capture console controls (keyboard/mouse/remote) in OSX so they can be replicated on another machine?

I need to mirror GUI console activity happening on one Macbook so that it is duplicated on a second identical Macbook.
The idea is to control an application that will run on two Macbooks simultaneously. The application is sort of a presentation with two variations in content, but identical controls. Think of it as two versions of PowerPoint presentation with some slides that are different.
I'm thinking that it may be possible to capture the keypresses and mouse events on one Mac, then use RFB protocol to send these across the network to the other Mac. I'm looking at rfbproxy and rfbplaymacro, but these are somewhat inelegant hacks, and any solution built on these will also be a bit of a hack. And of course, I'd prefer to avoid a solution that requires me to compile and perhaps debug software that hasn't been touched in half a decade. :-)
I could conceivably use Cliclick or xdotool (from MacPorts) to initiate console events on the "slave" Mac. But then I don't know what I'd use to capture the events on the "master". Or would an xdotool-based solution require that both Macs be slaves, and then use some other device as a master?
Input devices could be a presentation mouse, an Apple remote, or in a pinch, the keyboard of on of the Macbooks or even a third device.
Can you suggest tools? Or is there another strategy I haven't thought of?
If the computers are in the same room, a single Apple Remote can control both Macs as long as the remote is not paired to either one. I'm assuming you need a solution that will work over any arbitrary distance, though.
Have you considered AppleScript? It's pretty good at sending keystrokes to ssh-accessible Macs. The receiving application doesn't even need to be aware of AppleScript (i.e. scriptable). You'll just have to be sure GUI scripting is enabled on the targets by checking the Enable access for assistive devices option in the Universal Access system prefs panel.
Here's an example of a shell command that will send a keystroke to the frontmost app via applescript:
osascript -e "tell application \"System Events\" to keystroke \"a\""
If you set up key-based ssh auth between the master and slaves you can simply tack ssh onto the front of this command:
ssh slave osascript -e "tell application \"System Events\" to keystroke \"a\""
For elegance, you could wrap any number of desired keystrokes into a menu-based bash script and run it from a third computer.
I have tried to synchronise systems like this that are NOT Macs a few years ago using rfbproxy and rfbplaymacro which you already know about. The systems were both X terminals running at the same resolution. We still had problems because of different font size settings putting application controls in different places, but the basic VNCiness of the solution seemed to work just fine.
That said, if you want to write a stand-alone application to send stuff using osascript or cliclick or xdotool, and you have a wii, you might get some joy from DarwiinRemote.
Kindof convoluted, but you could use clusterSSH for OSX to start shell sessions from a third machines master window, and then send commands to the two slaves. This could be paired with a screen control utility similar to the ones you list above, another of which is pymaCursor.
If everything could instead be recorded in advance, you could try good ol' applescript/automator recording, or a newer project like sikuli - http://sikuli.org/

Better terminal in Mac OS X -- reversing the control and command key-mappings

I'm trying to have the same KDE Konsole experience within Mac OS X.
Here's my (overly complicated?) setup:
I have Control and Command swapped at the System Preferences level. (Can't live without this)
Parallels lets you, at the Parallels application level, also reverse Control and Command. So I can undo the System Preferences setting (and get the setup I want within virtual Linux)
I want this same per-application-opt-out for the Mac OS X Terminal app. Is it possible?
The solution you're looking for is KeyRemap4MacBook. There is a Tiger, Leopard, Snow Leopard, and Lion version.
Once installed, goto System Preferences -> KeyRemap4MacBook
Then select the following options:
Change Command_L Key (Left Command)
---> Command_L to Control_L (except Terminal, Virtual Machine, RDC)
Change Control_L Key (Left Control)
---> Control_L to Command_L (except Terminal, Virtual Machine, RDC)
You can repeat this for Command_R (Right Command) and Control_R (Right Control) also if you desire. Tested and working on my Macbook.
You can simply ssh into the Linux/Unix system and run X11 programs direct to your Mac screen: ssh -X user#host_or_ipaddress, login, and just run the X11 programs you want (e.g. emacs&) and the X11 apps will appear on the Mac display.
Pros:
X11 windows work just like any other window, including Exposé goodness, etc...
No need to work only inside the Parallels console window
Same solution works with any Linux/Unix system, remote or virtual
ssh connection is secure even over the internet
Tech info:
"ssh -X" turns on X11 forwarding for the ssh connection, i.e. the X11 display connection is tunneled through ssh securely
"ssh -X" also handles X11 authentication tunneling
X11.app is automagically started on OSX by launchd when needed
X11 can connect to displays over the network, which is one of the few cool things about it ;-)
There is very good and key-mapping flexible terminal: iTerm2
My favorite set: iTerm + zsh + oh-my-zsh
The 2016 solution is to use Karabiner open-source program which allows you to remap modifier and other keys with very fine granularity, for example
Remap only the left ⌘ Cmd or Option key.
Remap a key only for specific applications, e.g. only inside Terminal, Emacs, or virtual machine.
For example, here's how to remap left ⌘ Cmd key to act as Ctrl only inside Terminal (and leave the right one unaffected so that you could still use e.g. ⌘ Cmd + Tab to switch between apps):
You can customize the command keys used for an individual application in System Preferences > Keyboard & Mouse > Keyboard Shortcuts. I think (if I understand correctly what you're trying to do) that this might allow you to accomplish your goal. You could remap all of Terminal's command keys to use control instead of command, to get them out of your way... but then you might need to do a lot of customization on the machines you ssh into, so that they use Command instead of control
It seems that you're going to have to do an ENORMOUS amount of work just to allow you to use your pinky instead of your thumb for the modifier key.
Another possibility: user preferences can be manipulated by the "defaults" command. I haven't been able to find a way to use this to control they modifier key mappings, but it should logically be possible (if you're willing to do a lot of digging). If so, then you could write short scripts to switch back and forth between Mac default and your swapped mode. Trigger the scripts with Quicksilver, and whenever you use Terminal you can call one script, and whenever you leave it you can call another. Again, a big pain to achieve what you want, but it might be possible.
I don't think there's a clean and simple solution.
I've seen third-party programs that give more control over manipulating modifier keys, if you're willing to install them (probably kernel extensions). They might be able to do what you want, but I don't recall the names. If you google for programs to fix emacs and vi keys you might find them.
Good luck.
I had exactly the same problem as you. I've remapped Command to CAPS Lock, and Control to Command, but as a frequent Linux user I want both setups to be as similar as possible. This is how I solved it:
Install Keyboard Maestro (not free, but totally worth it), and set it up to run at login.
Inside KM, define macros to send CMD+{key} to CTRL+{key} inside Terminal.
If you want to remap a lot of keys this is a lot of work. But I've already done it myself, you can just download this file kmmacros. Double-clicking is enough to install it. A couple of caveats:
You need to set Terminal to use option as a meta key (Terminal > Preferences > Keyboard).
The bindings are only for emacs-mode. This cheat sheet should be helpful.
Most default shortcuts don't work anymore (CMD-N, CMD-C, ...), and the menu in Terminal does not reflect this. For some conflicts (New Window, Close Window), I've taken the ones from Gnome.

Resources