Re: Fwd: Bug 1778 in Minutes of the 27th November 2023 Teleconference

[Robert Elz via austin-group-l at The Open Group]

Date:Fri, 8 Dec 2023 07:11:17 +
From:"Andrew Josey via austin-group-l at The Open Group" 

Message-ID:  

  | > In edited post-d3 line 111861:
  | >
  | >literal value of a following  *and* shall prevent a
  | >
  | > should this *and* be /or/?
  | >
  | > Using *and* seems to imply that you would need to specify:
  | >
  | >   \\
  | >
  | > to use it, while /or/ should more clearly indicate the intended
  | > alternatives:

I don't agree, it was intended to specify that the \ does both of
those things - it escapes the following char = or if that char is
a newline, it makes the pair vanish.   That is, implementations
don't get to choose which of those it should implement, and ignore
the other.

If the simple wording leaves that ambiguous in some way (I'm not
convinced it does) then the whole sentence should be reworded (made
more explicit) - just changing "and" to "or" wouldn't do it.

kre

Fwd: Bug 1778 in Minutes of the 27th November 2023 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

hi all

This did not make it to the list (sender not recognized), so forwarding

> Begin forwarded message:
> 
> From: Brian Inglis 
> Subject: Re: Bug 1778 in Minutes of the 27th November 2023 Teleconference
> Date: 3 December 2023 at 15:33:31 GMT
> 
> 
> "Bug 1778: The read utility needs field splitting updates/corrections) and a
> little more) Accepted as Marked
> https://austingroupbugs.net/view.php?id=1778
> 
> On page 3291 line 111859 section read, change:
>By default, unless the -r option is specified,  shall
>act as an escape character. An unescaped  shall
>preserve the literal value of the following character, with the
>exception of ...
> 
> to:
>If the -r option is not specified,  shall act as an
>escape character. An unescaped  shall preserve the
>literal value of a following  and shall prevent a
>following byte (if any) from being used to split fields, with
>the exception of ..."
> 
> In edited post-d3 line 111861:
> 
>literal value of a following  *and* shall prevent a
> 
> should this *and* be /or/?
> 
> Using *and* seems to imply that you would need to specify:
> 
>   \\
> 
> to use it, while /or/ should more clearly indicate the intended alternatives:
> 
>   \\ -> \
>   \ ->
>   \
>   
> 
> -- 
> Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada
> 


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org  
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy 
.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481