* Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 @ 2016-03-29 19:25 Steffen Nurpmeso 2016-03-29 19:44 ` Steffen Nurpmeso 2016-03-31 16:20 ` Ingo Schwarze 0 siblings, 2 replies; 12+ messages in thread From: Steffen Nurpmeso @ 2016-03-29 19:25 UTC (permalink / raw) To: tech Hallo Ingo, hello list, i've just recognized a syntax error in some OpenSSH manuals, and that mandoc falsely does the correct thing, if that is possible. I.e., it renders correctly instead of printing the "Ns" as text, which i *think* it should; i think since groff does so, i however wonder why the zero-width extends beyond the space, hm, because it is a separator? I haven't looked into anything groffish that much for almost a year (and won't until i can really focus), so i may be mistaken. Ciao! -------- Original Message -------- Date: Tue, 29 Mar 2016 21:21:07 +0200 From: Steffen Nurpmeso <steffen@sdaoden.eu> To: openssh-unix-dev@mindrot.org Cc: Steffen (Daode) Nurpmeso <steffen@sdaoden.eu> Subject: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 Mail-Followup-To: Steffen Nurpmeso <steffen@sdaoden.eu>, openssh-unix-dev@mindrot.org Hello, the fix says it all. sftp.1 uses correct syntax already. Ciao, --- ssh.1.orig 2016-03-29 21:15:31.616819859 +0200 +++ ssh.1 2016-03-29 21:15:52.996820743 +0200 @@ -1049,7 +1049,7 @@ for remote and .Fl KD Oo Ar bind_address : Oc Ar port .Sm on for dynamic port-forwardings. -.Ic !\& Ns Ar command +.Ic \&! Ns Ar command allows the user to execute a local command if the .Ic PermitLocalCommand option is enabled in --- ssh_config.5.orig 2016-03-29 20:43:23.853406023 +0200 +++ ssh_config.5 2016-03-29 20:42:21.703403428 +0200 @@ -1220,7 +1220,7 @@ The default is Allow local command execution via the .Ic LocalCommand option or using the -.Ic !\& Ns Ar command +.Ic \&! Ns Ar command escape sequence in .Xr ssh 1 . The argument must be --steffen --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-29 19:25 Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 Steffen Nurpmeso @ 2016-03-29 19:44 ` Steffen Nurpmeso 2016-03-30 9:26 ` Steffen Nurpmeso 2016-03-31 16:20 ` Ingo Schwarze 1 sibling, 1 reply; 12+ messages in thread From: Steffen Nurpmeso @ 2016-03-29 19:44 UTC (permalink / raw) To: tech Ahem, i wrote |i've just recognized a syntax error in some OpenSSH manuals, and |that mandoc falsely does the correct thing, if that is possible. i want to add that this one is from 15th September 2015, i'm sorry i'm terribly restricted since my second box died in January etc. I will eventually have to buy a new one.. Ciao! --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-29 19:44 ` Steffen Nurpmeso @ 2016-03-30 9:26 ` Steffen Nurpmeso 2016-03-31 16:24 ` Ingo Schwarze 0 siblings, 1 reply; 12+ messages in thread From: Steffen Nurpmeso @ 2016-03-30 9:26 UTC (permalink / raw) To: tech i wrote ||i've just recognized a syntax error in some OpenSSH manuals, and ||that mandoc falsely does the correct thing, if that is possible. CVS as of today doesn't, though. So sorry for the noise, Ingo. (However, i had to --- a/configure +++ b/configure @@ -235,7 +235,7 @@ fi # --- ohash --- if [ ${BUILD_DB} -eq 0 ]; then - HAVE_OHASH=1 + HAVE_OHASH=0 elif ismanual ohash "${HAVE_OHASH}"; then : elif [ -n "${DBLIB}" ]; then to be able to compile with the config i've used (i'm only interested in the plain formatter.) Ciao! --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-30 9:26 ` Steffen Nurpmeso @ 2016-03-31 16:24 ` Ingo Schwarze 2016-03-31 17:16 ` Steffen Nurpmeso 0 siblings, 1 reply; 12+ messages in thread From: Ingo Schwarze @ 2016-03-31 16:24 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: tech Hi Steffen, Steffen Nurpmeso wrote on Wed, Mar 30, 2016 at 11:26:28AM +0200: > --- a/configure > +++ b/configure > @@ -235,7 +235,7 @@ fi > > # --- ohash --- > if [ ${BUILD_DB} -eq 0 ]; then > - HAVE_OHASH=1 > + HAVE_OHASH=0 > elif ismanual ohash "${HAVE_OHASH}"; then > : > elif [ -n "${DBLIB}" ]; then Don't do that. If automatic HAVE_OHASH detection doesn't work for you, just put HAVE_OHASH=0 into configure.local See INSTALL and configure.local.example for how the system works. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-31 16:24 ` Ingo Schwarze @ 2016-03-31 17:16 ` Steffen Nurpmeso 0 siblings, 0 replies; 12+ messages in thread From: Steffen Nurpmeso @ 2016-03-31 17:16 UTC (permalink / raw) To: Ingo Schwarze; +Cc: tech Hallo Ingo. Ingo Schwarze <schwarze@usta.de> wrote: |Steffen Nurpmeso wrote on Wed, Mar 30, 2016 at 11:26:28AM +0200: |> --- a/configure |> +++ b/configure |> @@ -235,7 +235,7 @@ fi |> |> # --- ohash --- |> if [ ${BUILD_DB} -eq 0 ]; then |> - HAVE_OHASH=1 |> + HAVE_OHASH=0 |> elif ismanual ohash "${HAVE_OHASH}"; then |>: |> elif [ -n "${DBLIB}" ]; then | |Don't do that. | |If automatic HAVE_OHASH detection doesn't work for you, |just put | | HAVE_OHASH=0 | |into | | configure.local That didn't work? It was overwritten later on. You fixed it? No. |See INSTALL and configure.local.example for how the system works. Yes i did (PAIN). Even after finding out that some of the variables exist multiple times and you have to uniq them first. I made the great and compiled mandoc several times in the past already. ^_^ Ciao, Ingo. --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-29 19:25 Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 Steffen Nurpmeso 2016-03-29 19:44 ` Steffen Nurpmeso @ 2016-03-31 16:20 ` Ingo Schwarze 2016-03-31 17:11 ` Steffen Nurpmeso 1 sibling, 1 reply; 12+ messages in thread From: Ingo Schwarze @ 2016-03-31 16:20 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: tech Hi Steffen, Steffen Nurpmeso wrote on Tue, Mar 29, 2016 at 09:25:36PM +0200: > i've just recognized a syntax error in some OpenSSH manuals, That's not a syntax error. It cannot be one. The esacape sequence "\&" can be used at any place where any other character can be used. At the worst, it could be a semantic error, but it is not even that. > and that mandoc falsely does the correct thing, if that is possible. Mandoc correctly does the correct thing. > I.e., it renders correctly instead of printing the "Ns" as text, Doing that would be a rather severe bug. Whether a macro argument is treated as text or called as a submacro must not depend on the text content of previous arguments. > which i *think* it should; i think since groff does so, I cannot reproduce. At least, groff-1.22.3 on OpenBSD-current does not, and i cannot remember ever having seen such a bug in groff. It's hard to imagine how that could even happen, given how the groff implementation of mdoc(7) works internally... > i however wonder why the zero-width extends beyond the space, > hm, because it is a separator? A zero-width space doesn't extend at all. In fact, no roff characters ever extend beyond any other characters. In groff, there is no concept of "separators" that would include "\&". The only similar concept here is "mdoc delimiters", and that applies to "!", but not to "\&". The blank after "\&" is indeed a roff(7) macro argument separator, but it isn't escaped. To escape blanks with respect to macro argument separation, you need to prepend a backslash (forming the "\ " escape sequence, in which case they are regarded as a different input characters by roff, no longer as blanks) or to enclose both arguments including the blank in between in double quotes (in which case that's still a normal blank character, but now inside a macro argument). I'm also appending my response to your patch. Yours, Ingo > -------- Original Message -------- > Date: Tue, 29 Mar 2016 21:21:07 +0200 > From: Steffen Nurpmeso <steffen@sdaoden.eu> > To: openssh-unix-dev@mindrot.org > Subject: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 > > Hello, > > the fix says it all. sftp.1 uses correct syntax already. > Ciao, > > --- ssh.1.orig 2016-03-29 21:15:31.616819859 +0200 > +++ ssh.1 2016-03-29 21:15:52.996820743 +0200 > @@ -1049,7 +1049,7 @@ for remote and > .Fl KD Oo Ar bind_address : Oc Ar port > .Sm on > for dynamic port-forwardings. > -.Ic !\& Ns Ar command > +.Ic \&! Ns Ar command > allows the user to execute a local command if the > .Ic PermitLocalCommand > option is enabled in > --- ssh_config.5.orig 2016-03-29 20:43:23.853406023 +0200 > +++ ssh_config.5 2016-03-29 20:42:21.703403428 +0200 > @@ -1220,7 +1220,7 @@ The default is > Allow local command execution via the > .Ic LocalCommand > option or using the > -.Ic !\& Ns Ar command > +.Ic \&! Ns Ar command > escape sequence in > .Xr ssh 1 . > The argument must be This patch is bogus. Both versions are completely correct. The purpose of escaping in this context is to prevent mdoc(7) from treating the exclamation mark as a delimiter, which can influence spacing and end of sentence detection. The mdoc(7) language treats the argument of an mdoc macro as a delimiter if both of the following conditions hold: 1. The macro argument consists of exactly one input character. 2. That character is anyone from the following set: - opening delimiters: ([ - middle delimiters: | - closing delimiters: .,:;)]?! The usual way to escape an argument such that it isn't taken as a delimiter is to add a zero-width space "\&" such that condition 1 no longer holds. See the mdoc(7) manual, subsection "Delimiters", for a full discussion. I admit that i usually put the "\&" in front of the character rather than after it, and so do the examples in the mdoc(7) manual. But some people find it more intuitive to put the "\&" afterwards to express that the character is not ending a sentence (i.e. is not a delimiter). I don't see the point in enforcing either style, it seems like useless churn and wasted time. -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-31 16:20 ` Ingo Schwarze @ 2016-03-31 17:11 ` Steffen Nurpmeso 2016-03-31 17:38 ` Ingo Schwarze 0 siblings, 1 reply; 12+ messages in thread From: Steffen Nurpmeso @ 2016-03-31 17:11 UTC (permalink / raw) To: Ingo Schwarze; +Cc: tech Hallo Ingo, Ingo Schwarze <schwarze@usta.de> wrote: |Steffen Nurpmeso wrote on Tue, Mar 29, 2016 at 09:25:36PM +0200: |> i've just recognized a syntax error in some OpenSSH manuals, | |That's not a syntax error. It cannot be one. The esacape sequence |"\&" can be used at any place where any other character can be used. |At the worst, it could be a semantic error, but it is not even that. I still haven't checked the OpenBSD version of OpenSSH, but i have seen your message on their ML (via Gmane) and there you correctly state what \& is far, it is used to avoid (mis)interpretation of "!". So it should be before that, not thereafter. |> and that mandoc falsely does the correct thing, if that is possible. | |Mandoc correctly does the correct thing. The CVS version now does. | |I'm also appending my response to your patch. That one i meant. Let's see.. |> -.Ic !\& Ns Ar command |> +.Ic \&! Ns Ar command |> -.Ic !\& Ns Ar command |> +.Ic \&! Ns Ar command |This patch is bogus. Both versions are completely correct. | |The purpose of escaping in this context is to prevent mdoc(7) |from treating the exclamation mark as a delimiter, which can |influence spacing and end of sentence detection. | |The mdoc(7) language treats the argument of an mdoc macro |as a delimiter if both of the following conditions hold: | | 1. The macro argument consists of exactly one input character. | 2. That character is anyone from the following set: | - opening delimiters: ([ | - middle delimiters: | | - closing delimiters: .,:;)]?! | |The usual way to escape an argument such that it isn't taken as |a delimiter is to add a zero-width space "\&" such that condition 1 |no longer holds. See the mdoc(7) manual, subsection "Delimiters", |for a full discussion. Later again. |I admit that i usually put the "\&" in front of the character rather |than after it, and so do the examples in the mdoc(7) manual. But Fantastic. |some people find it more intuitive to put the "\&" afterwards to |express that the character is not ending a sentence (i.e. is not a |delimiter). A bug. |I don't see the point in enforcing either style, it seems like |useless churn and wasted time. The visible flyspeck in the manuals of the portable version springs into the eye and drives you up the wall. Bah. Ciao, --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-31 17:11 ` Steffen Nurpmeso @ 2016-03-31 17:38 ` Ingo Schwarze 2016-03-31 19:24 ` Steffen Nurpmeso 0 siblings, 1 reply; 12+ messages in thread From: Ingo Schwarze @ 2016-03-31 17:38 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: tech Hi Steffen, Steffen Nurpmeso wrote on Thu, Mar 31, 2016 at 07:11:14PM +0200: > I still haven't checked the OpenBSD version of OpenSSH, but i have > seen your message on their ML (via Gmane) and there you correctly > state what \& is far, it is used to avoid (mis)interpretation of "!". > So it should be before that, not thereafter. Non sequitur. In many languages, you escape characters by placing something before them. But that isn't true in roff. In some contexts of roff, you can escape stuff by putting something *after* it. >>> and that mandoc falsely does the correct thing, if that is possible. >> Mandoc correctly does the correct thing. > The CVS version now does. Now you confuse me completely. During the last few years, i changed nothing in the mandoc code we are talking about. So how can the version of mandoc matter? >> some people find it more intuitive to put the "\&" afterwards to >> express that the character is not ending a sentence (i.e. is not a >> delimiter). > A bug. No, that practice is just fine. I don't understand why you keep calling it a bug. > The visible flyspeck in the manuals of the portable version > springs into the eye and drives you up the wall. Bah. I have no idea what you are talking about. Which formatter are you using? Which output does it generate for which input? Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-31 17:38 ` Ingo Schwarze @ 2016-03-31 19:24 ` Steffen Nurpmeso 2016-03-31 20:04 ` hans 0 siblings, 1 reply; 12+ messages in thread From: Steffen Nurpmeso @ 2016-03-31 19:24 UTC (permalink / raw) To: Ingo Schwarze; +Cc: openssh-unix-dev, tech Hallo Ingo, list, Ingo Schwarze <schwarze@usta.de> wrote: |Steffen Nurpmeso wrote on Thu, Mar 31, 2016 at 07:11:14PM +0200: |> I still haven't checked the OpenBSD version of OpenSSH, but i have |> seen your message on their ML (via Gmane) and there you correctly |> state what \& is far, it is used to avoid (mis)interpretation of "!". |> So it should be before that, not thereafter. | |Non sequitur. So now i have, and the bug(s) is (are) still in there. It is a bug, if i type "man ssh_config" i see PermitLocalCommand Allow local command execution via the LocalCommand option or using the ! Ns command escape sequence in ssh(1). The argument must be ``yes'' or ``no''. The default is ``no''. In OpenBSD language that is total crap. If i type "zcat /usr/share/man/man5/ssh_config.5.gz|mandoc|v" i see ... the very same! |In many languages, you escape characters by placing something before |them. But that isn't true in roff. In some contexts of roff, you can |escape stuff by putting something *after* it. | |>>> and that mandoc falsely does the correct thing, if that is possible. |>> Mandoc correctly does the correct thing. |> The CVS version now does. | |Now you confuse me completely. During the last few years, i changed |nothing in the mandoc code we are talking about. So how can the |version of mandoc matter? The version from September 2015 acted as if "\&! Ns" had been used. I don't have it no more, and am toooo lazy to bite. In the meanwhile i seem to remember a message from A. J. Bentley who reported some bug a while back, did he? I'm drowning in work, i'd surely search otherwise. |>> some people find it more intuitive to put the "\&" afterwards to |>> express that the character is not ending a sentence (i.e. is not a |>> delimiter). | |> A bug. | |No, that practice is just fine. |I don't understand why you keep calling it a bug. Bugbugbugbugbugbugbugbugbugbugbug. (Manually typed.) |> The visible flyspeck in the manuals of the portable version |> springs into the eye and drives you up the wall. Bah. | |I have no idea what you are talking about. Which formatter are you |using? Which output does it generate for which input? Just feeding animals in the zoo. And then home. Tschüß. --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-31 19:24 ` Steffen Nurpmeso @ 2016-03-31 20:04 ` hans 2016-04-01 12:46 ` Steffen Nurpmeso 0 siblings, 1 reply; 12+ messages in thread From: hans @ 2016-03-31 20:04 UTC (permalink / raw) To: Steffen Nurpmeso, tech, Ingo Schwarze, openssh-unix-dev On Mar 31 21:24:57, steffen@sdaoden.eu wrote: > PermitLocalCommand > Allow local command execution via the LocalCommand option or > using the ! Ns command escape sequence in ssh(1). The argument > must be ``yes'' or ``no''. The default is ``no''. This is what I see: PermitLocalCommand Allow local command execution via the LocalCommand option or using the !command escape sequence in ssh(1). The argument must be “yes” or “no”. The default is “no”. What system are you on and which man(7) formatter does your man(1) use? > In OpenBSD language that is total crap. > If i type "zcat /usr/share/man/man5/ssh_config.5.gz|mandoc|v" > i see ... the very same! What is 'v'? > |> The visible flyspeck in the manuals of the portable version > |> springs into the eye and drives you up the wall. Bah. > | > |I have no idea what you are talking about. Which formatter are you > |using? Which output does it generate for which input? > > Just feeding animals in the zoo. And then home. Ah. I should have known better. -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-03-31 20:04 ` hans @ 2016-04-01 12:46 ` Steffen Nurpmeso 2016-04-01 12:53 ` hans 0 siblings, 1 reply; 12+ messages in thread From: Steffen Nurpmeso @ 2016-04-01 12:46 UTC (permalink / raw) To: hans; +Cc: openssh-unix-dev, tech hans <hans@stare.cz> wrote: |On Mar 31 21:24:57, steffen@sdaoden.eu wrote: |> PermitLocalCommand |> Allow local command execution via the LocalComman\ |> d option or |> using the ! Ns command escape sequence in ssh(1). Th\ |> e argument |> must be ``yes'' or ``no''. The default is ``no''. | |This is what I see: If i could read "the ! King command" it would be fine by me. Ns is not acceptable. |What system are you on and which man(7) formatter does your man(1) use? It is groff. It is mandoc as of CVS. It is Linux and FreeBSD, up-to-date. What i wasn't sure about, is wether in "!\& Ns" the "\&" should really escape the following Ns macro or not. I.e., wether that was also a bug in mdoc(7) parsing or not. Ingo said it's not. (The mdoc(7) macro expand such things recursive.) |> If i type "zcat /usr/share/man/man5/ssh_config.5.gz|mandoc|v" |> i see ... the very same! | |What is 'v'? v='LESS= less --RAW-CONTROL-CHARS --ignore-case --no-init --quit-if-one-screen' |> Just feeding animals in the zoo. And then home. | |Ah. I should have known better. Yeah, but no meat a.k.a. cut corpses. Not imprisoned but free. Only vegetarian stuff. --steffen -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 2016-04-01 12:46 ` Steffen Nurpmeso @ 2016-04-01 12:53 ` hans 0 siblings, 0 replies; 12+ messages in thread From: hans @ 2016-04-01 12:53 UTC (permalink / raw) To: Steffen Nurpmeso, tech, openssh-unix-dev On Apr 01 14:46:23, steffen@sdaoden.eu wrote: > hans <hans@stare.cz> wrote: > |On Mar 31 21:24:57, steffen@sdaoden.eu wrote: > |> PermitLocalCommand > |> Allow local command execution via the LocalComman\ > |> d option or > |> using the ! Ns command escape sequence in ssh(1). Th\ > |> e argument > |> must be ``yes'' or ``no''. The default is ``no''. > | > |This is what I see: > > If i could read "the ! King command" it would be fine by me. > Ns is not acceptable. What are you talking about? > |What system are you on and which man(7) formatter does your man(1) use? > > It is groff. It is mandoc as of CVS. Do you mean both of them show you this? -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-04-01 12:53 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-29 19:25 Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 Steffen Nurpmeso 2016-03-29 19:44 ` Steffen Nurpmeso 2016-03-30 9:26 ` Steffen Nurpmeso 2016-03-31 16:24 ` Ingo Schwarze 2016-03-31 17:16 ` Steffen Nurpmeso 2016-03-31 16:20 ` Ingo Schwarze 2016-03-31 17:11 ` Steffen Nurpmeso 2016-03-31 17:38 ` Ingo Schwarze 2016-03-31 19:24 ` Steffen Nurpmeso 2016-03-31 20:04 ` hans 2016-04-01 12:46 ` Steffen Nurpmeso 2016-04-01 12:53 ` hans
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).