hotkey not working on mac Monterey 12.2.1

[nerdielol]

import pyautogui

pyautogui.hotkey('command', 'c')

outputs a single 'c' being typed

[JayRizzo]

What versions are you running? I am on macOS: 12.3.1, Python 3.9.5, PyAutoGUI 0.9.53

When running in the command line - I get a flash when i am in my terminal as I have nothing highlighted to copy.

pip3 list | grep PyAutoGUI

test:

import pyautogui

with pyautogui.hold('command'):
    pyautogui.press(['c'])

pyautogui.hotkey('command', 'c')

I had no issue, just a flash of my screen since i had nothing highlighted to copy.

BUT, I only get the single 'c' being typed in the interactive terminal when i copy & paste very quickly:

Example:

Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> import pyautogui
>>> 
>>> with pyautogui.hold('command'):
...     pyautogui.press(['c'])
... 
>>> pyautogui.hotkey('command', 'c')
>>> 
>>> 
>>> 
>>> import pyautogui
>>> 
>>> with pyautogui.hold('command'):
...     pyautogui.press(['c'])
... 
>>> pyautogui.hotkey('command', 'c')
>>> 
>>> 
>>> import pyautogui
>>> 
>>> with pyautogui.hold('command'):
...     pyautogui.press(['c'])
... 
>>> pyautogui.hotkey('command', 'c')

c>>> 
>>> c

Note check for memory leaks and i noticed if the copy command is failing the interactive terimnal might be launching additional windows. not sure if that is the cause or side effect.

[avi-cenna]

I have noticed a certain degree of instability with hotkeys on Mac as well. I'm on Monterey 12.3.1 (21E258) and PyAutoGUI 0.9.53.

The following works for me:

with pyautogui.hold(['command']):
    time.sleep(1)
    pyautogui.press('a')

Using hotkey by itself doesn't seem to work, and excluding the sleep seems to make the command less reliable, sometimes working and sometimes not.

For Mac users, you might want to consider using Hammerspoon for things such as keypresses. It's been incredibly reliable for me.

[pendragons-code]

I have noticed a certain degree of instability with hotkeys on Mac as well. I'm on Monterey 12.3.1 (21E258) and PyAutoGUI 0.9.53.

The following works for me:

with pyautogui.hold(['command']):
    time.sleep(1)
    pyautogui.press('a')

Using hotkey by itself doesn't seem to work, and excluding the sleep seems to make the command less reliable, sometimes working and sometimes not.

For Mac users, you might want to consider using Hammerspoon for things such as keypresses. It's been incredibly reliable for me.

can confirm, based on other sources, macOS consistently has issues with pyautogui.

[yezhengli-Mr9]

I have noticed a certain degree of instability with hotkeys on Mac as well. I'm on Monterey 12.3.1 (21E258) and PyAutoGUI 0.9.53.

The following works for me:

with pyautogui.hold(['command']):
    time.sleep(1)
    pyautogui.press('a')

Using hotkey by itself doesn't seem to work, and excluding the sleep seems to make the command less reliable, sometimes working and sometimes not.

For Mac users, you might want to consider using Hammerspoon for things such as keypresses. It's been incredibly reliable for me. Hi @avi-cenna , @JayRizzo , @pendragons-code

709 , https://github.com/JetBrains/jdk8u_jdk/issues/37 Not for sure your command+c/a context but does not work for command+s context anyhow:

        driver.get(url)
    wait = WebDriverWait(driver, 200)
    time.sleep(5)
    with pyautogui.hold('command'):
        time.sleep(1)
        pyautogui.press(['s'])
    # Press Ctrl+S to open the Save As dialog box
    # pyautogui.hotkey('command', 's')
    '''
    pyautogui.keyDown('command')
    pyautogui.press('s')
    '''
    time.sleep(5)

    # Type the file path and press Enter to save the file
    # pyautogui.typewrite('downloads/')
    pyautogui.press('enter')
    time.sleep(5)
    driver.quit()

[avi-cenna]

@yezhengli-Mr9 Have you tried using Hammerspoon?

[yezhengli-Mr9]

@yezhengli-Mr9 Have you tried using Hammerspoon?

Hi @avi-cenna , thanks~ Let me checkout hammerspoon next weekend (or in mid-Oct.). Best,

[CLARKBENHAM]

On MacOS14.1, Python 3.9 and PyAutoGUI 0.9.54 on both VSCode's integrated terminal and the default terminal trying to get paste working produces indeterminate behavior.

The following 3 options normally type the letter 'v' when first run, but if run again are likely to paste the outputs. If you run the script below in a terminal the first writes 'v' and the 2nd and 3rd paste. This is independent of the method used: if you reorder them to 3,2,1 then 3 and 2 might not paste but # 1 would.

import pyautogui 
import time 

print ("# 1. ")
with pyautogui.hold("command"): 
  time.sleep(1)
  pyautogui.press("v")

print("# 2. ")
pyautogui.hotkey("command", "v", interval=0.1)

print("# 3. ")
pyautogui.keyDown("command")
pyautogui.press("v")
pyautogui.keyUp("command")

What works well enough for my use case is chaining 2 pastes. At least one paste happens > 95% of the time initally, and after “warming up” I would consistently see 2 pastes.

pyautogui.hotkey("command", "v")
time.sleep(0.5)
pyautogui.hotkey("command", "v") 

[yezhengli-Mr9]

CLARKBENHAM

On MacOS14.1, Python 3.9 and PyAutoGUI 0.9.54 on both VSCode's integrated terminal and the default terminal trying to get paste working produces indeterminate behavior.

The following 3 options normally type the letter 'v' when first run, but if run again are likely to paste the outputs. If you run the script below in a terminal the first writes 'v' and the 2nd and 3rd paste. This is independent of the method used: if you reorder them to 3,2,1 then 3 and 2 might not paste but # 1 would.

import pyautogui 
import time 

print ("# 1. ")
with pyautogui.hold("command"): 
  time.sleep(1)
  pyautogui.press("v")

print("# 2. ")
pyautogui.hotkey("command", "v", interval=0.1)

print("# 3. ")
pyautogui.keyDown("command")
pyautogui.press("v")
pyautogui.keyUp("command")

What works well enough for my use case is chaining 2 pastes. It happens maybe 75% of the time?

pyautogui.hotkey("command", "v")
time.sleep(0.5)
pyautogui.hotkey("command", "v") 

In terms of keys mapping on (esp. different OS versions of) MacOS, pyautogui is unstable. Feel pyautugui was developed on non-MacOSs', not tested on MacOS. Consequentially, attempts on MacOSs seem personal rather than official tested/ provable attempts.