Open pekcheey opened 1 month ago
apparently the above diff doesn't fix the issue. still checking.
Seems like adding a ', errors="ignore"' to the decode call works more reliably.
- return runner.stdout.decode("UTF-8").removesuffix("\n") # looks like all commands returns \n in the end
+ return runner.stdout.decode("UTF-8", errors="ignore").removesuffix("\n") # looks like all commands returns \n in the end
Hello!
Please show output of clipman.init(debug=True)
and pip3 show clipman
ouch. look like it is probably an one of those issues that cannot be replicated after a computer restart.
> pip3.12 show clipman
Name: clipman
Version: 3.2.3
Summary: Python3 module for working with clipboard. Created because pyperclip is discontinued.
Home-page: https://github.com/NikitaBeloglazov/clipman
Author:
Author-email: NikitaBeloglazov <nnikita.beloglazov@gmail.com>
License: MPL 2.0 License
Location: /opt/homebrew/lib/python3.12/site-packages
Requires:
Required-by:
I think we should close this issue for now. I'll be sure to send the output of clipman.init(debug=True) ifI encounter the issue again.
You using old version of clipman This already get fixed in v3.2.5 Please see issue #16
oh I see. Okay. I'll update. Thanks for the quick response.
for what it's worth when I have the following cross like character in the clipboard at the time of calling clipman init, the problem still happen. [†]
after some testing, it seems that forcing an encoding when calling subprocess works.
runner = subprocess.run(command, timeout=timeout, shell=False, check=False, stdout=subprocess.PIPE, stderr=subprocess.P IPE, encoding="ISO-885-1")
▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲
with the encoding done within subprocess.run, the subsequent call to .decode('UTF-8')
is no longer needed.
apparently, using the encoding="unicode_escape"
works as well.
that said, is this a "fix" or a "workaround" for this particular case? I don't know. it may depends on factors such as
after a bit of googling / asking ChatGPT (info may be sketchy) it seems that ISO-8859-1 is a single byte encoding compared to UTF-8 and unicode_escape I suspect that with regard to Clipman, the encoding selected should be the more permissive encoding (that can encode more character's without throwing error)
Of course, it is also possible that these sort of errors may be regarded as special cases. And I suspect that for the majority of users, this issue is not encountered. and this issue may be close again. I don't mind it. I'm just going to reopen the issue with the comment for your attention.
Thanks for creating clipman!
Sometimes I get the following error when calling clipman.init()
from the following
† | python - UnicodeDecodeError: 'utf8' codec can't decode byte 0xa5 in position 0: invalid start byte - Stack Overflow
the solution is to make a call to strip() before decode() I tried the following and it seems to resolve the error.