#435 Broken file
Hi maintainers and contributors,
Please remove https://github.com/openocd-org/openocd/blob/ad216136180e0cd482f414eb072c9dd25dd1c559/tcl/target/1986%D0%B2%D0%B51%D1%82.cfg or https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/target/1986%D0%B2%D0%B51%D1%82.cfg from the repository. Many tools can't cope with these special chars in it. Which results in extraction errors if someone tries to extract a zip with this file and OpenOCD in it.
Also some file system tools don't like them and fail to display the file name correctly.
(This is not the reason for the ticket but it would be reason enough: it's Russian and contains a link to a Russian {.ru} web site. If you don't support the war against the Ukrain I it would be nice to remove any links {and in the same act support for special products from them} to them from your software)
And here is some example on a Windows system how an error of a library which failed to extract the zip look like: scripts\target\1986??1?.cfg as you can see the special chars broke the path.
*Ukraine sorry for the typo
Dear Maintainers,
I share the concerns from Paul Ober. I remember experiencing crashes and troubles because certain filenames in OpenOCD have non-ASCII characters.
Kind regards,
Kristof Mulier
Van: "Paul" paulober@users.sourceforge.net
Aan: "openocd-devel" openocd-devel@lists.sourceforge.net
Verzonden: Dinsdag 24 september 2024 02:14:05
Onderwerp: [openocd:tickets] #435 Broken file
[ https://sourceforge.net/p/openocd/tickets/435/ | [tickets:#435] ] Broken file
Status: new
Milestone: 0.10.0
Created: Mon Sep 23, 2024 06:14 PM UTC by Paul
Last Updated: Mon Sep 23, 2024 06:14 PM UTC
Owner: nobody
Hi maintainers and contributors,
Please remove [ https://github.com/openocd-org/openocd/blob/ad216136180e0cd482f414eb072c9dd25dd1c559/tcl/target/1986%D0%B2%D0%B51%D1%82.cfg | https://github.com/openocd-org/openocd/blob/ad216136180e0cd482f414eb072c9dd25dd1c559/tcl/target/1986%D0%B2%D0%B51%D1%82.cfg ] or [ https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/target/1986%D0%B2%D0%B51%D1%82.cfg | https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/target/1986%D0%B2%D0%B51%D1%82.cfg ] from the repository. Many tools can't cope with these special chars in it. Which results in extraction errors if someone tries to extract a zip with this file and OpenOCD in it.
Also some file system tools don't like them and fail to display the file name correctly.
(This is not the reason for the ticket but it would be reason enough: it's Russian and contains a link to a Russian {.ru} web site. If you don't support the war against the Ukrain I it would be nice to remove any links {and in the same act support for special products from them} to them from your software)
And here is some example on a Windows system how an error of a library which failed to extract the zip look like: scripts\target\1986??1?.cfg as you can see the special chars broke the path.
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to [ https://sourceforge.net/p/openocd/tickets/ | https://sourceforge.net/p/openocd/tickets/ ]
To unsubscribe from further messages, a project admin can change settings at [ https://sourceforge.net/p/openocd/admin/tickets/options. | https://sourceforge.net/p/openocd/admin/tickets/options. ] Or, if this is a mailing list, you can unsubscribe from the mailing list.
Related
Tickets: #435
If you search the OpenOCD mailing list archives you'll see that this sort of issue has cropped up a few times in the past - i.e. script filenames with non-ASCII (usually or always Cyrillic) characters in the name which caused problems for some people/tools. I remember a few such filenames in the OpenOCD source base years ago but then the files in question were either renamed or were removed along the way. I don't know if there's any general policy on the naming of source and configuration files or if it's simply a question of pragmatism/common sense? Similarly, I'm not sure if there's any stated policy on stuff like removing from files content such as links/URLs of a specific geographical/national nature, but I suspect that anything suggestive of censorship might be potentially controversial?
Hey Tommy,
I want to echo your statements and probably add a bit more
clarification.
I was the one who added some non-ASCII file names and I still think it
was a good idea. All the other targets are using their official names,
so why make an exception for those having non-Latin letters?
Single-byte encodings are the memories from the past by now, so what
else would be a solid technical reason for that?
On Tue, Sep 24, 2024 at 07:28:26AM +0000, Tommy Murphy wrote:
Or just people stopped using broken tools. If the filename has Unicode
characters, so what, how does it make it broken? Quite the contrary,
it's an additional test to expose and let the broken tools be fixed.
There's no policy indeed. And removing actual information and code
"just because" is indeed controversial. If the chip was only good for
military purposes it might have made some sense, but "banning" a
generic Cortex-M MCU for the crimes of its country is just silly I
think.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
my only feedback on this topic is that I work with linux commandline and I have problems typing characters that are not on the international keyboard.
Today I still can run
and for the other file I type "1986" and auto complete it with TAB.
No big problems for the moment, but if in the future we get other files without any ASCII character in the name, I will be lost.
The Linux kernel has the documentation translated in few languages in Documentation/translations/ but the file names are strictly ASCII and use the same names of the eqivalent English docs. So no suggestions from there.
On Tue, Sep 24, 2024 at 01:25:01PM -0000, Antonio Borneo wrote:
Good point. But is using a pointer to copy it from e.g. "ls" output
not a comfortable option?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
indeed, it works!
I'm glad it works (thank you for testing, Tommy!)
In the xPack distribution, the Windows archive is created with Linux
zip, which, I guess, is pretty portable.I agree. According to my tests, I never had problems unpacking the archives, so, as long as keeping the non-ASCII names is not harmful in any way, I see no compelling reasons for removing them.
However, personally I think that avoiding non-ASCII names is a matter of courtesy, allowing users to enter the names on any common keyboard.
Regards,
Liviu
I don't know why this reply by email from me did not appear here on the list so here it is again...
I can see merit in this argument. Reminds me a bit of Linus's "tabs versus spaces" gate... :-)
https://arstechnica.com/gadgets/2024/04/linus-torvalds-reiterates-his-tabs-versus-spaces-stance-with-a-kernel-trap/
I'm also curious as to what specific platforms/tools people have seen having problems with filenames such as "1986ве1т.cfg" and "к1879xб1я.cfg"?
I just downloaded the latest xPack OpenOCD (https://xpack-dev-tools.github.io/openocd-xpack/docs/releases/) and extracted it using 7Zip and Windows Explorer ("File Manager") and neither had problems extracting all contents including 1986ве1т.cfg or к1879xб1я.cfg and I can use these files from the command line, editors etc.
Personally, as things stand, I don't really see a compelling case for removing or renaming (to ASCII (or ANSI?) only) such files - or unilaterally removing content from them. Where somebody has a different opinion then maybe the best way to test it is via the patch/review process?