Checking out support on various older platforms (older releases of Ubuntu, basically), I found one release, 18.04, that that could run poca (install and run requirements and with a version of Python that worked) AND that could bug out on discovering Unicode support (see #122). With a bit of jiggery pokery. But that still had a terminal that supported unicode.
So what's the point in insisting on a fallback option if we aren't supporting the platforms that would require it? And if we require unicode, does that mean only utf-8 encoding?
WSL apparently fakes a UTF-8 interface to underlying Windows NT UTF-16 innards, so that could work. (except in practice it doesn't seem like it has the capability of displaying it: see the issue on windows wsl)
Python on Windows itself uses UTF-8 for output since 3.6 but probably not for filenames?
MacOS? No idea.
Specifically:
Output: Output checks for encoding on stdout. Even if we drop the uni-UI, there's till the question of support for printing file names to the console.
Filenames: As long as rename is not used, there should not be any problem. But with rename on, it might be possible to crash. writing to a file takes a filename string. Python must then be responsible for whatever OS specific magic is required to turn that into a filename. So.... only if we use illegal characters?
Checking out support on various older platforms (older releases of Ubuntu, basically), I found one release, 18.04, that that could run poca (install and run requirements and with a version of Python that worked) AND that could bug out on discovering Unicode support (see #122). With a bit of jiggery pokery. But that still had a terminal that supported unicode.
So what's the point in insisting on a fallback option if we aren't supporting the platforms that would require it? And if we require unicode, does that mean only utf-8 encoding?
Specifically: