openssh unix dev - Mar 2016 - 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

--steffen

Hi Steffen,

Steffen Nurpmeso wrote on Tue, Mar 29, 2016 at 09:21:07PM +0200:
> the fix says it all.  sftp.1 uses correct syntax already.
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.

Yours,
  Ingo