Hi all, the specification says this about link lines: > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>] > > where: > > • <whitespace> is any non-zero number of consecutive spaces or tabs > • Square brackets indicate that the enclosed content is optional. > • <URL> is a URL, which may be absolute or relative. From this description I don't know whether <USER-FRIENDLY LINK NAME> MAY be empty. Which of these regular expressions would be correct to parse a link line? a) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t].*)$) b) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t]?.*?)$) Or are both wrong, because I misunderstood "spaces" as 0x20? Sorry for the nitpicking :p Greetings Richard Ulmer
On 2021-11-08 08:07PM, codesoap@mailbox.org wrote:
> Hi all,
> > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
> From this description I don't know whether <USER-FRIENDLY LINK NAME>
> MAY be empty. Which of these regular expressions would be correct to
> parse a link line?
The user friendly link name is optional, however if it is present
then the whitespace after the url is mandatory as well. In other words,
the URL is mandatory, and you either have no link name and no space
after the URL or a link name and mandatory space(s) after the URL.
So you have the following possibilities for link lines:
=>url <- no link name, no space between => and url
=> url <- no link name, one or more spaces separating
=>url name <- link name present, no space between => and url
=> url name <- link name present, one or more spaces separating
> a) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t].*)$)
> b) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t]?.*?)$)
I believe the latter (option b) would be correct. I would remove the
final "[^ \t]?" and simplify it down to this:
^=>[ \t]*([^ \t]+)(?:$|[ \t]+(.*)$)
You don't really need regex though, just skip past the =>[whitespace],
then the url is splitting on the first space and the remainder is
everything else.
~nytpu
--
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com
Hi Alex, thanks for your response! Unfortunately your answer still leaves me uncertain. Here you say, that trailing whitespace is illegal, if there is no link name: > The user friendly link name is optional, however if it is present > then the whitespace after the url is mandatory as well. In other words, > the URL is mandatory, and you either have no link name and no space > after the URL or a link name and mandatory space(s) after the URL. The regular expression you suggest here, however, allows trailing whitespace, even if there is no link name: > > a) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t].*)$) > > b) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t]?.*?)$) > I believe the latter (option b) would be correct. I would remove the > final "[^ \t]?" and simplify it down to this: > ^=>[ \t]*([^ \t]+)(?:$|[ \t]+(.*)$) Do you have a link to an authoritative source upon which your knowledge on the matter is based? I wrote my initial mail on the topic, because I'm looking for an authoritative answer rather than an opinion. - Richard Ulmer
It was thus said that the Great codesoap@mailbox.org once stated: > Hi Alex, > thanks for your response! Unfortunately your answer still leaves me > uncertain. Here you say, that trailing whitespace is illegal, if there > is no link name: > > > The user friendly link name is optional, however if it is present > > then the whitespace after the url is mandatory as well. In other words, > > the URL is mandatory, and you either have no link name and no space > > after the URL or a link name and mandatory space(s) after the URL. > > The regular expression you suggest here, however, allows trailing > whitespace, even if there is no link name: > > > > a) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t].*)$) > > > b) ^=>[ \t]*([^ \t]+)(?:$|[ \t]+([^ \t]?.*?)$) > > I believe the latter (option b) would be correct. I would remove the > > final "[^ \t]?" and simplify it down to this: > > ^=>[ \t]*([^ \t]+)(?:$|[ \t]+(.*)$) > > Do you have a link to an authoritative source upon which your knowledge > on the matter is based? I wrote my initial mail on the topic, because > I'm looking for an authoritative answer rather than an opinion. The two sources I know of are the one you already quoted (section 5.4.2 of gemini://gemini.circumlunar.space/docs/specification.gmi) and a proposed BNF for the revised specification (https://gitlab.com/gemini-specification/gemini-text/-/issues/7). Both leave the impression that (where spaces are replaced by '_'): =>gemini://example.com_ would not be allowed, but as with the real world, you may have to be a bit lenient with the input (especially if it's user generated). Also note that as of now, the official spec allows both spaces (0x20) and tabs (0x09) to be "whitespace", whereas the BNF only allowd spaces (0x20). -spc
It was thus said that the Great codesoap@mailbox.org once stated: > > Do you have a link to an authoritative source upon which your knowledge > on the matter is based? I wrote my initial mail on the topic, because > I'm looking for an authoritative answer rather than an opinion. Let me amend my previous response---the BNF at https://gitlab.com/gemini-specification/gemini-text/-/issues/7, as defined, will allow the text portion of the link line to be nothing but spaces (per the text rule). -spc
---
Previous Thread: Request for feedback from server/client implementers using non-OpenSSL TLS stacks