Closed RokeJulianLockhart closed 8 months ago
Most file systems provide a way to escape forward slashes. For example:
. `{title: "[LSHW](https%3A%2F%2Fdownload.opensuse.org%2Frepositories%2Fhardware%2FopenSUSE_Tumbleweed%2Fx86_64%2F)" \⁄* https%3A%2F%2Fdub.sh%2Fs5gs6l *\⁄, id: ""}`{.JSON5}.dir
Does that work?
https://github.com/json5/json5-spec/issues/46#issuecomment-1849123707
@jordanbtucker, no, and I'm not aware of filesystems which provide that capability. Which do you refer to? Creating an empty file using https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/dolphin-23.08.4-1.1.x86_64.rpm on BTRFS converts the forward solidus to https://www.compart.com/en/unicode/U+2044. For instance, \/
becomes \⁄
.
```.log PS /home/RokeJulianLockhart> touch "$HOME/testfile" PS /home/RokeJulianLockhart> $? True PS /home/RokeJulianLockhart> touch "$HOME/testfile\/ss" /usr/bin/touch: cannot touch '/home/RokeJulianLockhart/testfile\/ss': No such file or directory NativeCommandExitException: Program "touch" ended with non-zero exit code: 1. PS /home/RokeJulianLockhart> $? False ```
That doesn't work because you're not allowed to have a file with a /
in it. I guess I'm not sure what problem you are trying to solve. Are you trying to create a file whose name is a JSON5 document with a comment?
@jordanbtucker, yes. I've always used JSON5 for my file names for the reasons aforementioned (because using a concise interchange format the sole solution to that problem) but haven't been able to use comments in them.
Thanks for the clarification. The JSON5 syntax is finalized, so no new syntactic features or changes will be implemented. Any changes to the specification will be clarifications or additional information regarding JSON5's use. Since JSON5 was not designed to be used as filenames, it will not be changed to conform to or accommodate the character limitations of filename systems.
That being said, I'm still very curious about your use case is for using JSON5 as filenames. I've never come across that before, not even with regular JSON.
https://github.com/json5/json5-spec/issues/46#issuecomment-1852768700
@jordanbtucker,
The JSON5 syntax is finalized, so no new syntactic features or changes will be implemented. Any changes to the specification will be clarifications or additional information regarding JSON5's use.
Is there something like a JSON6 where this could be considered, then? Or does
Since JSON5 was not designed to be used as filenames, it will not be changed to conform to or accommodate the character limitations of filename systems.
apply to any future versions too?
That being said, I'm still very curious about your use case is for using JSON5 as filenames. I've never come across that before, not even with regular JSON.
Thanks. I'm glad to elaborate on any point, especially if it would increase the probability even vaguely that this use case might be considered.
As far as I know, there is no such thing in JSON6, however, I do not maintain that project.
There are no plans to create new versions of the JSON5 format at this time. New versions of the json5
npm package may be released, but they will conform to the JSON5 format, so they won't support additional comment syntax.
I use JSON5 for filesystem object names. It works brilliantly, allowing me to encode attributes in a standardized manner without using the XDG filesystem object attribute specification (see https://wiki.archlinux.org/title/Extended_attributes). However, I cannot use comments, because they are exclusively delimited by the forward solidus, the sole character disallowed by every kernel and filesystem universally (my configuration is Linux and BTRFS, where literally solely
/
and NULL are disallowed, per https://forum.garudalinux.org/t/btrfs-can-have-crazy-file-names-having/5687/15?u=rokejulianlockhart). Could you provide an alternative, like PowerShell's#
and<#
#>
? I really don't want to go non-standard.As an example:
To alleviate confusion, that JSON5 is wrapped in Pandoc Markdown for irrelevant reasons. Currently, I must use:
...which syntactically provides less contextual relevance. Is this rationale enough to suggest this?