This is not really about issue 1198, but a question raised by
thinking about issue 1198 ...
The question is, when an awk script does (not on the command
line, but in the script)
x="10"
can the value of x ever be considered a numeric string (in the
awk definition technical sense) ?
This
However you remember any discussions, it has never been the case in any
version of the Bourne Shell that a \ inside a '' (single quoted) string means
anything at all - ever. It is simply a character like any other (except the
closing single quote, and \0). Coming just before a newline makes no
I see the important words are that they "shall be removed before splitting the
input", otherwise you are forcing implementations to begin evaluating quoting
before determining a complete line, not as part of tokenizing that complete
line, and this is what I remember from that discussion being
Shware Systems wrote, on 07 Aug 2018:
>
>> On Tuesday, August 7, 2018 Geoff Clare wrote:
>>
>> Shware Systems wrote, on 07 Aug 2018:
>> >
>> > That is a bug in those shells, conformance wise. No buts. Consideration of
>> > quoting happens after line joining, for all forms, as noted in the
>>
That describes the non-quoted case, yes, and is needed to skip over instances
\' and \" during token evaluation. I'm on phone, so didn't have line numbers
handy, no. In evaluating a line, the implemention
is expected to behave as all characters are non-special except for a "\"
sequence,
On 08/07/2018 10:20 AM, Shware Systems wrote:
That is a bug in those shells, conformance wise. No buts. Consideration of
quoting happens after line joining, for all forms, as noted in the sections on
quoting and tokenization. I don't think that even qualifies as a permitted
extension, which
Shware Systems wrote, on 07 Aug 2018:
>
> That is a bug in those shells, conformance wise. No buts. Consideration of
> quoting happens after line joining, for all forms, as noted in the sections
> on quoting and tokenization.
If you had bothered to read the "sections on quoting and
On 08/07/2018 10:18 AM, Joerg Schilling wrote:
Stephane Chazelas wrote:
2018-08-07 15:46:33 +0100, Stephane Chazelas:
[...]
- or a variant thereof that covers historical implementations,
that is same as above except that a fragment can't end in a
backslash.
[...]
Correction: can't
Stephane Chazelas wrote:
> 2018-08-07 15:46:33 +0100, Stephane Chazelas:
> [...]
> > - or a variant thereof that covers historical implementations,
> > that is same as above except that a fragment can't end in a
> > backslash.
> [...]
>
> Correction: can't end in *an unescaped* backslash.
>
Stephane Chazelas wrote, on 07 Aug 2018:
>
> [...]
>
> (replying to a very old email as context for the recent
> discussion).
>
> Geoff, it looks like your change from the initially requested
> "Add the text specified by the script_frag" to "Add the editing
> commands specified by the script"
2018-08-07 15:46:33 +0100, Stephane Chazelas:
[...]
> - or a variant thereof that covers historical implementations,
> that is same as above except that a fragment can't end in a
> backslash.
[...]
Correction: can't end in *an unescaped* backslash.
sed -e 'w file\\' -e q
(write to a file
Stephane Chazelas wrote, on 07 Aug 2018:
>
> 2018-08-07 09:40:21 +0100, Geoff Clare:
> [...]
> > Looking at bug 262, which was a request to allow arbitrary text instead
> > of editing commands in the -e option-argument and the file specified by
> > the -f option-argument, it appears that we chose
2018-08-07 09:40:21 +0100, Geoff Clare:
[...]
> > It works with ast-open's sed, but that one also gives a warning:
> >
> > sed: warning: script segment ends with \
> >
> > Should those be considered non-compliant or did I miss something
> > in the text of the standard? There's at least some
The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1198
==
Reported By:geoffclare
Assigned To:
Robert Elz wrote, on 06 Aug 2018:
>
> | For step 1 this would conflict with 2.5.2 which says that empty fields
> | resulting from expanding @ and * _may_ be discarded. Your suggestion
> | would require them to be discarded instead of it being optional.
>
> Is that any different from what
Stephane Chazelas wrote, on 06 Aug 2018:
>
> From the spec at
> http://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/sed.html
>
> I think
>
> echo foo | sed -e 'a\' -e bar
>
> should be the same as
>
> echo foo | sed -e 'a\
> bar'
>
> As another "-e text" is meant to append
16 matches
Mail list logo
