On 6/27/2021 4:00 PM, Nicolas George wrote:
James Almer (12021-06-27):
How is it not accurate enough?
Which characters must be escaped? Is it legal to escape another
character? Does it support single quotes like the other escaping
functions? Can you use byte or Unicode numbers?
Only line breaks need to be escaped. I said as much and even suggested
to make it more explicit in the documentation.
Every other character will be read and added verbatim into a string used
as uri for a given resource that ffurl_open_whitelist() will then handle.
Create a text file with the following four entries
foo\
bar.h264
foo'bar.h264
foo\bar.h264
foobar.h264
Where only the line break is escaped to ensure it's not interpreted as a
resource name delimiter, and they will all be read and open if they exist.
Various escaping syntax have subtle differences about these points, and
this is something users need to know about, especially for scripts.
Anyway, our escaping syntax should be documented once well, with links
to it everywhere where needed, the description must not be duplicated
all over the place.
I can add a line to the documentation stating that no other character needs
to be escaped if that will make it more clear.
Make it a link to the unique good documentation of escaping.
There's no need for any escaping other than the delimiter character, so
wouldn't it be misleading linking to a document that will make you write
your entries in the file in a way that will not work?
Said documentation will tell you that if you want to load foo'bar.h264
you will need to write it as foo\'bar.h264, but that's not true here and
will only make it attempt to load a file with all those characters as
part of its name.
If we do not have an unique good documentation of escaping, the it needs
to be written, and this is a good occasion. But I think we have it.
The existing de-escaping functions will just remove backslashes, and the
line break character will be parsed as a delimiter, which is why i wrote the
above to ensure it is read as part of the filename.
The contents of the file are meant to be taken as is, and if you want the
delimiter character to be part of the filename, you need to let the parser
know about it. Every other character in the text file doesn't need to be
escaped since this is not the command line where they could be interpreted
as something else.
I know what the existing de-escaping functions do, and I know what they
can be used for, and I repeat: you can the parsing correctly with them
by reading the whole file at once.
But as it is, this code duplication is a big no.
Wont your request to use escaping functions result in the need for the
entries in the text file to start pointlessly escaping characters like
quotes, backslashes and others for no reason, as if this were bash?
The protocol right now supports line breaks as part of the filename if
you escape it like you asked me to support, alongside every other
character without doing anything for them. What you're now asking from
me is to require it to parse more characters than necessary as if this
was the command line, when there's no reason to.
Regards,
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
