How does Binki handle spaces in filenames? Does it escape and unescape " " and "\x20"? I couldn't find anything in the sources.

---
* Origin: Birds aren't real (21:3/102)

On Sat Jan 15 19:00:00 2022, Oli wrote to All <=-

How does Binki handle spaces in filenames? Does it escape and unescape " " and "\x20"? I couldn't find anything in the sources.

It doesn't. I'm testing a change now to escape / unescape spaces and other reserved characters. The format is apparently \20 not \x20 for binkp

As for \x20 - I guess this is handled by the C++ filesystem std library, i don't know.

Andrew

=== TitanMail/freebsd v1.0.9


--- Talisman v0.34-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

It doesn't. I'm testing a change now to escape / unescape spaces and
other reserved characters. The format is apparently \20 not \x20 for
binkp

As for \x20 - I guess this is handled by the C++ filesystem std library,
i don't know.

Now that you mention it, that does remind me of C++. As I recall, '\n' was
the LF string? I really didn't like C++, back when I was learning to code, so maybe I'm wrong.

This was one of the reasons I chose Mystic for PiBBS. I (thought I) could
write code for Mystic, because I have experience with (*Turbo*)Pascal...Turns out, MPL isn't exactly the same...but, still easier than learning C++!

Never mind. Cheers!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

Re: spaces in filenames
By: apam to Oli on Sun Jan 16 2022 09:53 am

On Sat Jan 15 19:00:00 2022, Oli wrote to All <=-

How does Binki handle spaces in filenames? Does it escape and unescape " " and "\x20"? I couldn't find anything in the sources.

It doesn't. I'm testing a change now to escape / unescape spaces and other reserved characters. The format is apparently \20 not \x20 for binkp

I think it's actually supposed to be '\xXX' (and just just \x20 for space). This is what BinkIT does (for both encode and decode of filename parameters) and it appears to jive with FTS-1026.

As for \x20 - I guess this is handled by the C++ filesystem std library, i don't know.

Nope. '\x20' is character literal in C/C++, but that's a sequence that would be converted at compile time, not run-time, so there's no special filesystem support for that style of escape sequence. :-)
--
digital man (rob)

Breaking Bad quote #38:
Don't drink and drive, but when you do, call Saul.
Norco, CA WX: 53.5°F, 91.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

I think it's actually supposed to be '\xXX' (and just just \x20 for
space). This is what BinkIT does (for both encode and decode of
filename parameters) and it appears to jive with FTS-1026.

I was going by this document:

https://www.ritlabs.com/binkp/ (in section 5.2)

Ah, I see. they changed the method and that is an old document. Thanks.

Nope. '\x20' is character literal in C/C++, but that's a sequence that
would be converted at compile time, not run-time, so there's no
special filesystem support for that style of escape sequence. :-)

Yeah, I thought that was a stretch. I really don't know why it worked on
my system then :P

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07

--- Talisman v0.34-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

apam wrote (2022-01-16):

On Sat Jan 15 19:00:00 2022, Oli wrote to All <=-

How does Binki handle spaces in filenames? Does it escape and
unescape " " and "\x20"? I couldn't find anything in the sources.

It doesn't. I'm testing a change now to escape / unescape spaces and
other reserved characters. The format is apparently \20 not \x20 for binkp

It is \x for all reserved characters and \x20 for space (see FTS-1026). The \20 was an error in a previous FTSC proposal (FSP-1011).

AFAIK Argus, Irex and Mystic are using or have used "\".

binkd always used \x. mbcico, qico, Taurus/Radius, BinkIt and others use \x too.

---
* Origin: Birds aren't real (21:3/102)

It is \x for all reserved characters and \x20 for space (see
FTS-1026). The \20 was an error in a previous FTSC proposal
(FSP-1011).

Yep, thanks. I was looking at the wrong document.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07

--- Talisman v0.34-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

On 19 Jan 2022 at 12:02a, Digital Man pondered and said...

I think it's actually supposed to be '\xXX' (and just just \x20 for space). This is what BinkIT does (for both encode and decode of filename parameters) and it appears to jive with FTS-1026.

That was my reading, as well. What I took away from 1026
is this:

* New code should use "\xHH" for two hex-digits "HH" to represent
"escaped" characters in commands.
* Whitespace in filenames is prohibited at the protocol level,
and must be escaped.
* The character "\" must always be escaped.
* The FSP-1011.003 escape method of "\HH" is deprecated.
* Systems should provide a configuration option on a per-node
basis to use the FSP-1011.003 method for nodes running software
written assuming the "\HH" encoding.
* Software should unconditionally transform "\20" (specifically)
into a space character in file names.

In other words, use "\xHH" unless directed otherwise by a
configuration option. Always translate "\20" to space.

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

tenser wrote (2022-01-20):

* The FSP-1011.003 escape method of "\HH" is deprecated.

It's not deprecated, it was never valid binkp. FSP-1011 was never released as a standard and \HH was a documentation error. (if my interpretation is correct)

* Systems should provide a configuration option on a per-node
basis to use the FSP-1011.003 method for nodes running software
written assuming the "\HH" encoding.

"It is _advised_ to have a setting for specific nodes to sent escaped characters using the incorrect method."

advise is not a SHOULD or MUST.

It was not the worst idea when the FTS was released, but it's not really a sufficient workaround and in many cases useless. In the source code and documentation of several mailers, only Argus and Irex are mentioned as the mailers that are victims of the error in FPS-1011. I'm not sure anyone is using Argus anymore (and it has became open source, so it could be fixed). And Irex binkp implementation is a mess anyway and might need some additional workarounds (https://gitlab.synchro.net/main/sbbs/-/issues/185).

All other mailers I know do use \xHH or don't do any escaping at all.

IMHO, don't waste time with implementing and documenting a configuration option. Do some hard coded auto detection for the few specific mailer versions that have problems or just ignore the few broken mailers.

* Software should unconditionally transform "\20" (specifically)
into a space character in file names.

.... and send a warning message back ;)

M_NUL BUG "Your mailer is a victim of FSP-1011. Use \x20 instead of \20."

---
* Origin: Birds aren't real (21:3/102)

On 19 Jan 2022 at 03:57p, Oli pondered and said...

tenser wrote (2022-01-20):

* The FSP-1011.003 escape method of "\HH" is deprecated.

It's not deprecated, it was never valid binkp. FSP-1011 was never
released as a standard and \HH was a documentation error. (if my interpretation is correct)

I think you're splitting semantic hairs here. There is clearly
software in the wild that implements the proposal's behavior;
that behavior has been defined to be "incorrect" in an actual
standard, but nonetheless legacy software implements it. In
FTS-1026.003, this is described as "the incorrect method", but
given that the dictionary definition of "deprecate" as a verb
is to "express disapproval of" I'd say that 1026 certainly
deprecated the proposal's mechanism. :-)

* Systems should provide a configuration option on a per-node
basis to use the FSP-1011.003 method for nodes running software
written assuming the "\HH" encoding.

"It is _advised_ to have a setting for specific nodes to sent escaped characters using the incorrect method."

advise is not a SHOULD or MUST.

Again, splitting semantic hairs. I did not say I was using
the RFC terminology; my use was intended to be colloquial.

It was not the worst idea when the FTS was released, but it's not really
a sufficient workaround and in many cases useless. In the source code and documentation of several mailers, only Argus and Irex are mentioned as
the mailers that are victims of the error in FPS-1011. I'm not sure
anyone is using Argus anymore (and it has became open source, so it
could be fixed). And Irex binkp implementation is a mess anyway and
might need some additional workarounds (https://gitlab.synchro.net/main/sbbs/-/issues/185).

I agree with you.

All other mailers I know do use \xHH or don't do any escaping at all.

If they do no escaping, they are wrong. The standard is quite
clear about this.

IMHO, don't waste time with implementing and documenting a configuration option. Do some hard coded auto detection for the few specific mailer versions that have problems or just ignore the few broken mailers.

This begs the question: how does one define a "configuration
option"? That could be a dynamic determination made when the
connection is established based on some heuristic.

FTS-1026.003 is very poorly written; at a minimum, it needs a
good editor to clean up the grammar and language. My suspicion
is that the "configuration option" bit wasn't meant to be
strictly literal, but rather, that the intent be some mechanism
for dealing with software written to the proposal's recommendation,
as a pragmatic consideration. Whether that was done with some
file or done with some other mechanism seems largely irrelevant
from the intent.

* Software should unconditionally transform "\20" (specifically)
into a space character in file names.

.... and send a warning message back ;)

M_NUL BUG "Your mailer is a victim of FSP-1011. Use \x20 instead of \20."

Let's be honest: most BBS people would have no idea what to do
with that and would just ignore it.

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)