Well I've got the "wrapper" file that launches mcomm fixed, so now I am
getting the following errors from the actual python script:
Traceback (most recent call last):
  File "/usr/share/mcomm/mcomm.py", line 199, in <module>
    main()
  File "/usr/share/mcomm/mcomm.py", line 163, in main
    lPorts = serial.tools.list_ports.comports()
  File "/usr/lib/python3/dist-packages/serial/tools/list_ports_posix.py",
line 122, in comports
    return [(d, describe(d), hwinfo(d)) for d in devices]
  File "/usr/lib/python3/dist-packages/serial/tools/list_ports_posix.py",
line 122, in <listcomp>
    return [(d, describe(d), hwinfo(d)) for d in devices]
  File "/usr/lib/python3/dist-packages/serial/tools/list_ports_posix.py",
line 93, in describe
    return usb_lsusb_string(sys_usb)
  File "/usr/lib/python3/dist-packages/serial/tools/list_ports_posix.py",
line 71, in usb_lsusb_string
    iManufacturer = re_group('iManufacturer\s+\w+ (.+)', desc)
  File "/usr/lib/python3/dist-packages/serial/tools/list_ports_posix.py",
line 44, in re_group
    m = re.search(regexp, text)
  File "/usr/lib/python3.5/re.py", line 173, in search
    return _compile(pattern, flags).search(string)
TypeError: cannot use a string pattern on a bytes-like object

On Thu, 4 Mar 2021 at 02:02, Brian K. White <b.kenyo...@gmail.com> wrote:

> On 3/3/21 1:50 PM, Peter Vollan wrote:
> > FYI my problem persists, despite installing python 3.5
>
> I haven't seen an answer to either mine or others questions that would
> nail down that the the installed 3.5 is actually what the script is
> using. Merely installing a package doesn't guarantee anything.
>
> You're symptoms are unusual, and so it needs debugging on your end if
> you want it to work. You have to investigate and verify things that are
> usually just assumed and handled automatically.
>
> When you type "mcomm" is it really running the file you and I and
> everyone assumes it is?
>
> $ which mcomm
> /usr/bin/mcomm
>
> ok good, next, look at that file. The problem sytax occurs right in that
> file, not later in the real program file, so *that* file needs to be
> executed by a python 3.5 or later executable.
>
> And that file is executed by whatever is on it's shebang line, which is
> "/usr/bin/python3", point being, not just "python3", so, you can verify
> the interpreter for that file a couple different ways. You can look at
> "/usr/bin/python3",
>
> $ ls -l /usr/bin/python3
> lrwxrwxrwx 1 root root 9 Oct  6 06:28 /usr/bin/python3 -> python3.8
>
> $ /usr/bin/python3 --version
> Python 3.8.6
>
>
> Or you could also add a print statement to show the python version.
> Insert this line after the import lines and before the subprocess.call()
> line:
>
> print(sys.version)
>
>
>
> Or, better yet, the problem syntax occurs right in the top level wrapper
> script, and that entire line really isn't necessary, the entire script
> doesn't even need to be python. You could replace the entire contents
> with this simpler sh version:
>
> #!/bin/sh
> exec python3 /usr/share/mcomm/mcomm.py "$@"
>
> What happens when you do that?
>
> --
> bkw
>

Reply via email to