OS X does not make it obvious that you might've left a screen sharing session open -- and it's still actively broadcasting your session to these other computers. Does anyone know where Snow Leopard stores that the computer you're sitting at has an open screen sharing session?
If I could detect this file using a shell script every minute or so, then I could fire a Growl notification to let me know that I'm essentially being watched by this other computer (using the code snippet found here).
Otherwise, the only way to know now is to notice a very small icon on the top right of my screen that looks like binoculars (very hard to notice).
One way would be to use lsof to check for any established connections by AppleVNCServer
lsof -a -i :vnc-server -sTCP:ESTABLISHED -c AppleVNCServer
Related
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!)
I am using Mac OS X 10.11.2. Recently I connected it to another monitor using HDMI. Whenever I turn on my mac, it sounds out to the monitor. How can I fix it sounding out to a earphone? I know where I set the audio output in mac preference. But even if I choose the earphone output, it doesn't work at all. I want to know the permanent way to fix the output to the earphone.
System Preferences > Sound > Output is probably what you're looking for. Pretty sure the device you select here becomes default. You can always check the Show volume in menu bar to change it quickly.
I updated to OSX 10.9.5 and realized that one function pipeline that I used flawlessly is now broken.
I send a wake-on-lan magic packet to my OSX from my Raspberry Pi which successfully wakes up the OSX, but unlike before the iMac's display stays dark. Previously the display also brightened up. The problem is not that particularly, but that when I run an applescript through SSH the iMac goes back to sleep by itself in the middle of running and I have to wake it up again to finish the interrupted script. I have setup my energy saving to "Never" so it shouldn't do that.
I even tried running a script that actually sets the brightness of iMac's display to highest, but that doesn't wake up the display either.
Only when I take a VNC connection or move the local USB mouse the display wakes up and OSX won't go back to sleep by itself.
I found a solution for this. Just run this on the remote OSX's terminal:
caffeinate -u -t 1
It will wake up the display immediately. I found the solution from this blog
I have an Applescript that changes my mouse tracking speed that I want to run whenever I connect a mouse to my laptop. How do I do something like this? I was thinking of making it into an application and just clicking it whenever I need it, but I feel like there's a better way to do it.
This answer mentions launchd's ability to detect and launch an app when usb devices are connected. Sounds like what you are after.
Execute an application on Mac OS X when a particular type of USB device is connected?
You can get your specific product is, to use in the plist file, from System Profile->USB
Hope that helps.
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/