Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Ingo Schwarze]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Ingo Schwarze]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Ingo Schwarze]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[hans]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[Steffen Nurpmeso]

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

Re: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2

[hans]

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