Re: Quoting: is "${foo-'a"b'"}" valid?

[Robert Elz]

Date:Fri, 9 Sep 2016 19:30:25 -0400
From:shwares...@aol.com
Message-ID:  <12a74a.132e02c8.4504a...@aol.com>

  | To me the contexts are, for "${foo-'a"b'"}" as a stream of  characters:

That's the way that you want it to be, and it even makes some sense, but
it is not the way the shell has traditionally parsed it.

Quoted ${ } is one of the hariest parts of the shell, and scariest in a
sense, and is really difficult to duplicate - and it is not at all surprising
that all this is left as unspecified, or will be, in issue 8 (and for now
it is simply incomprehensible).

What is clear is that a ${ } does not (never did) start a new quoting
context - if double quotes were in effect outside, they remain in effect
inside, so 

  | begin double quote stream part
  |   begin substitution
  | parameter-name dash-op begin argument word
  |   begin single quote stream part

cannot be right, as single quotes inside a double quoted string are
simply characters, and begin nothing.

All this was changed somewhat when the substring operators were added,
as it was clear that patterns followed, and patterns require their own
quoting to be able to enter the magic matching chars literally - and
enclosing quoting state cannot apply, or inside a "${v#xxx}" type
expansion (where the quotes are needed because of the value of v) it
would not be possible to have any pattern matching chars as the xxx
would otherwise all be quoted - so in that context the rules altered.

But only in that context.

Then we get to the issue of the " inside the "${ ... }" and that's where
it all gets very messy and absurd, and while no-one would really want to
require what the original shell did, nor can the standard claim that it
is sane, so unspecified is the best we can hope for.

As Jilles said, in the original shell

"${foo-some"more}

worked just fine (what it is supposed to mean really is almost
incomprehensible, but still, it worked.)

kre

Re: Quoting: is "${foo-'a"b'"}" valid?

[SHwareSyst]

To me the contexts are, for "${foo-'a"b'"}" as a stream of  characters:
begin double quote stream part
  begin substitution
parameter-name dash-op begin argument word
  begin single quote stream part
a"b
  end single quote
  begin double quote stream part
}
  end double quote
LF may implicitly end argument and
  may implicitly end substitution.
 
As it starts with a double quote, the shell should add the LF to the  
pending result as a char and keep looking for the closing quote. Tokenizing 
rule  
1. says an EOF may close a string implicitly, though should be at least a  
warning; I don't see that an EOL does. It is not part of the   
lexical class so that rule 7. applies. Since a closing quote does not end the  
context by rule 8. it simply gets added to the word. From that the  parameter 
to echo is not complete so no output should be generated.
 
Because the initial single quote is in a new pending argument  context due 
to the recursive evaluation, not the outer double quote context, the  single 
quote is special again, as part of checking it as a WORD token in its own  
right, when the substitution is evaluated. The unspecified aspect Bug 221 
deals  with is more double quotes don't have to be specially escaped in  
forming an element in those subcontexts to keep the syntax scan from  
considering 
it the end of the top level quoted portion, that I  see. Single quote being 
non-special during recognition ensures after the  end of token is found it 
is still available to participate in quote removal if a  recursed context 
specifies quote removal shall occur during evaluation of  substitutions.



In a message dated 9/9/2016 10:33:00 A.M. Eastern Daylight Time,  
chet.ra...@case.edu writes:

On  9/9/16 9:40 AM, Vincent Lefevre wrote:
> On 2016-09-09 09:02:11 -0400,  Chet Ramey wrote:
>> On 9/9/16 7:44 AM, Vincent Lefevre  wrote:
>>> On 2016-09-05 19:12:54 +, Mark Galeck  wrote:
 The standard says in the section 2.2.3 on  Double-Quotes and $ :
 "even number of unescaped  double-quotes or single-quotes, if any,
 shall  occur".
>>>
>>> Concerning this point, these even  number of double-quotes and even
>>> number of single-quotes are  fulfilled with the example below:
>>>
>>>echo "${foo-'a"b'"}"
>>>
>>> But is this  valid?
>>
>> It's unspecified, so anything goes, as  per
>>
>>  http://austingroupbugs.net/view.php?id=221
>>
>> "For  parameter expansions other than the four varieties that provide
>>  for substring processing, within the string of characters from an
>>  enclosed "${" to the matching '}', the double-quotes within which
>>  the expansion occurs shall preserve the literal value of all
>>  characters, with the exception of the characters double-quote,
>>  backquote, , and . If any  unescaped
>> double-quote characters occur within the string, other  than in
>> embedded command substitutions, the behavior is  unspecified."
> 
> But this will be only in Issue 8.
>  
> http://austingroupbugs.net/view.php?id=221 is about "poor
>  wording", but I don't see where it the above unspecified
> in Issue  7.

OK.  Geoff's position is that the issue 7 text is a requirement  on the
application, not the shell, in addition to the wording being  ambiguous
about the intent that the requirement applies separately to  single
and double quotes (i.e., you can't nest them).

As such, there  wasn't any shell behavior to point to as correct when
interpretation 221  was being discussed, and part of the discussion
involved deciding what was  correct and expressing it clearly.

The discussion, which took place in  2010, also included the point that
single quotes are not special when the  expansion is within double quotes,
so there's no implication that the  single quotes begin some separate
"single quote stream," and that shells  didn't have to take single quotes
into account when finding the ending  brace.

Since the single quotes aren't special, it would seem that the  ksh93
behavior, at least, isn't correct and that the correct output is  'ab'.
But that depends on what shells do with the embedded double  quotes.

So since the whole reason for the interpretation is that the  wording was
bad and shells behaved differently, there can't be any  conclusions
drawn from it.  It's a defect in the standard.   However...

The text in issue 8 was supposed to capture the original  intent of issue 7,
even if the text in issue 7 didn't do a good job of  expressing it.  If you
believe this, the construct is  unspecified.

> 
> And one also has:
> 
>   "For the four varieties of parameter expansion that provide  for
> substring processing (see [xref to 2.6.2  Parameter Expansion]),
> within the string of  characters from an enclosed "${" to the
> matching  '}', the double-quotes within which the expansion occurs
>   shall have no effect on the handling of any special  characters."
> 
> There's no unspecified behavior concerning the  double quotes.
> So, what abou

Re: Minutes of the 1st September 2016 Teleconference

[Stephen Michell]

Hello Andrew.

I have no problem with your actions. The secretary gave you an interpretation 
and instructions, and you followed that. We just need to discuss it in plenary 
and clarify the situation.

see you in Vienna (via WebEx)




> On Sep 9, 2016, at 6:04 AM, Andrew Josey  wrote:
> 
> hi Stephen, all
> 
> I can't be there in person in Vienna but will try and attend via the webex. 
> 
> Firstly, its best not to debate interpretations of legal agreements between 
> other parties and what “clearly applies” or not - as interpretations will 
> differ. 
> 
> The facts are that we took the routine approach of notifying ISO/IEC JTC 1 
> that a draft was ready for balloting, to be told by the ISO/IEC JTC 1 
> secretariat that it was not necessary  (minuted in Austin/751 with the 
> resulting action to alert the ISO/IEC SC22 OR and SC22 convenor completed by 
> the Austin Group chair on March 4) . 
> 
> If ISO/IEC come back next week to tell us that something else should happen 
> we are fine with that. 
> 
> So I would strongly suggest you not take umbrage with the Austin Group 
> actions.
> 
> I have a detailed communications trail from mid 2015 until now to back up the 
> actions, but probably best not to burden this list with it, suffice to say 
> each communication involved the top two work programme contacts below plus 
> Nick as the OR, and later the third person listed in the work programme at 
> ISO who at the end of communications confirmed they wanted the TC to be 
> handled via the PSDO agreement.
> 
> 
> 
> 
> Just so you know in the editorial role I spent several transatlantic plane 
> rides preparing a defect report log to accompany the TC as per the 
> instructions given on January 10 by the ISO/IEC JTC 1 secretariat . So I had 
> put in significant effort on Plan A , to then be told of this Plan B later in 
> February. 
> regards
> Andrew
> 
> 
> Andrew Josey  The Open Group
> Austin Group Chair  
> Email: a.jo...@opengroup.org  
> Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
> Tel:+44 118 9023044
> 
> 
> 
> 
> 

[1003.1(2013)/Issue7+TC1 0001076]: Cancellation Points

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1076 
== 
Reported By:torvald
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1076
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Torvald Riegel 
Organization:   Red Hat 
User Reference:  
Section:Cancellation Points 
Page Number:1 
Line Number:1 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-09-09 16:12 UTC
Last Modified:  2016-09-09 16:12 UTC
== 
Summary:Cancellation Points
Description: 
sem_wait is currently part of the "shall occur" list.  This is suboptimal:

(1) It adds overhead to the fast paths of any semaphore implementation (ie,
checking for cancellation, which will likely at least require touching an
additional cache line).

(2) It creates an inconsistency with sem_trywait semantics in that
sem_trywait isn't really a "subset" of sem_wait anymore.  Something like
"if (sem_trywait(...) != 0) sem_wait(...);" kills cancellation.  To be
consistent wrt cancellation, sem_trywait would have to be a cancellation
point too.

(3) Because the implementation is allowed to decide between cancellation
and success when a cancellation request races with unblocking *during* the
execution of sem_wait, the POSIX requirement that sem_wait should be a
cancellation point regardless of whether it blocks is only exploitable by
programs that enforce that the cancellation request is issued before
sem_wait is called.  This requires active synchronization, and thus the
program would already have been able to check whether it should continue to
compute or stop. Thus, using this reliably doesn't add functionality that
the program wouldn't be able to implement otherwise.
Desired Action: 
I think that the description of when cancellation requests have to be acted
upon could be improved.  Without reading the rationale ("Thread
Cancellation Overview", esp. first paragraph of "Cancellation Points"
bullet), it's hard to see that the "may" vs. "shall" lists also allow for
different treatment of the sem_wait issue I described (eg,
pthread_rwlock_rdlock implementations don't need to check).

It seems the cleanest specification of cancellation would be to say that a
function that is considered to have a cancellation point will eventually
act upon a cancellation request, provided that it is blocked.

This adds the forward progress requirement for acting upon a cancellation
request (ie, the "eventually"), and avoids the weasel-wording in the last
sentences of the section (ie, timeouts and when event and cancellation
request happen without enforced ordering).  It also avoids having to check
for cancellation in functions that don't block (which will always affect
fast-paths), yet prevents a thread from being blocked indefinitely.  It
would not make "shall occur" functions points that can be interrupted
regardless of whether the thread actually makes progress or not.

Whether a particular function is in the "shall" or "may" camp seems pretty
arbitrary (at least, arguably, different programs would benefit from
different functions being in "shall" vs. "may").  Therefore, cancellation
seems more useful as a mechanism for preventing indefinite blocking (ie,
only cancel if blocked) instead of having even deferred cancellation be
something like unconditional interruption at functions arbitrarily
considered safe points (ie, functions in which cancellation points "shall
occur").
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-09-09 16:12 torvaldNew Issue
2016-09-09 16:12 torvaldName  => Torvald Riegel  
2016-09-09 16:12 torvaldOrganization  => Red Hat 
2016-09-09 16:12 torvaldSection   => Cancellation Points
2016-09-09 16:12 torvaldPage Number   => 1   
2016-09-09 16:12 torvaldLine Number   => 1   
==

Minutes of the 8th September 2016 Teleconference

[Andrew Josey]

All
Enclosed are the minutes from yesterdays call
regards
Andrew
--

Minutes of the 8th September 2016 Teleconference Austin-782 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 9th September 2016

Attendees:
   Don Cragun, IEEE PASC OR
   Geoff Clare, The Open Group
   Mark Ziegast, SHware Systems
   Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
   Eric Blake, Red Hat
   Richard Hansen, Google
   Martin Rehak, Oracle
   Andrew Josey, The Open Group 
   Keld Simonsen, DK
   Joerg Schilling, FOKUS Fraunhofer
 
Apologies
   David Clissold, IBM

* General news

Andrew announced he has been informed by IEEE that they will be publishing a
rolled up 2016 edition after all. This is now in the final stages of 
preparation 
by the editors.

Keld had joined the meeting to voice concerns about the ISO/IEC approval 
process.
We noted this is a matter for ISO/IEC and we are proceeding as instructed
by the ISO/IEC JTC 1 secretariat. 
Andrew and Nick will try to attend the SC22 meeting remotely next week, so
the matter can be discussed. 

* Outstanding actions

( Please note that this section has been flushed to shorten the minutes -
to locate the previous set of outstanding actions, look to the minutes
from 28 Jan 2016)

Bug 249: Add standard support for $'...' in shell   Reopened
http://austingroupbugs.net/bug_view_page.php?bug_id=249
We will return to bug 249 on a future call.

Bug 953: Alias expansion is under-specified   Was Accepted as Marked
http://austingroupbugs.net/view.php?id=953
Richard has an action to propose new wording to discuss in a future telecon.

* Current Business


Bug 1009:"remain in affect after" and "during the execution" are problematic 
when built-in/function modifies the variable
http://austingroupbugs.net/view.php?id=1009 

A lengthy discussion occurred, with new wording proposals documented in the 
etherpad.

This matter is still open and to be continued.

Next Steps
--
The next call is on September 15th, 2016 (a Thursday)

Apologies from Andrew in advance

Calls are anchored on US time. (8am Pacific) 

This call will be for the regular 90 minutes.

http://austingroupbugs.net

An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

http://po...@posix.rhansen.org:9001/p/201x-mm-dd
password=2115756#


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

[1003.1(2013)/Issue7+TC1 0000755]: reused thread id and mutex ownership

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=755 
== 
Reported By:nsz
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   755
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Szabolcs Nagy 
Organization:   musl libc 
User Reference:  
Section:pthread_mutex_lock 
Page Number:1653 
Line Number:53580-53581 
Interp Status:  Approved 
Final Accepted Text:See
http://austingroupbugs.net/view.php?id=755#c1875. 
== 
Date Submitted: 2013-09-21 00:42 UTC
Last Modified:  2016-09-09 14:59 UTC
== 
Summary:reused thread id and mutex ownership
== 

-- 
 (0003375) torvald (reporter) - 2016-09-09 14:59
 http://austingroupbugs.net/view.php?id=755#c3375 
-- 
Ping.

Have you considered the consequences for implementations?  If so, what
implementation approaches did you consider, and how did you assess the
runtime costs?  For example, having to look up a separate thread ID on
another cache line every time one tries to acquire a recursive lock is not
for free in terms of runtime overhead.  This ID should also be large enough
to never overflow, so 32b is probably not sufficient.
Keeping a list of all locks a thread has acquired is obviously not
efficient enough.

Currently, I don't see a way to implement this requirement in a way that
does not add significant overhead to recursive mutexes.  Therefore, I'm not
planning to implement this requirement in glibc; I'd much rather ignore
this requirement than make recursive mutexes slower for everyone, because
the latter would drive people away from POSIX facilities. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-09-21 00:42 nszNew Issue
2013-09-21 00:42 nszName  => Szabolcs Nagy   
2013-09-21 00:42 nszOrganization  => musl libc   
2013-09-21 00:42 nszSection   => pthread_mutex_lock
2013-09-21 00:42 nszPage Number   => 0   
2013-09-21 00:42 nszLine Number   => 0   
2013-09-21 05:10 shware_systems Note Added: 0001842  
2013-09-21 05:31 dalias Note Added: 0001843  
2013-09-21 06:08 shware_systems Note Added: 0001845  
2013-09-21 06:30 dalias Note Added: 0001846  
2013-09-22 02:36 shware_systems Note Added: 0001847  
2013-09-22 03:20 dalias Note Added: 0001848  
2013-09-23 04:50 shware_systems Note Added: 0001849  
2013-10-10 18:23 Don Cragun Page Number  0 => 1653   
2013-10-10 18:23 Don Cragun Line Number  0 => 53580-53581
2013-10-10 18:23 Don Cragun Interp Status => --- 
2013-10-10 18:23 Don Cragun Note Added: 0001875  
2013-10-10 18:23 Don Cragun Status   New => Under Review 
2013-10-10 18:25 Don Cragun Final Accepted Text   => See
http://austingroupbugs.net/view.php?id=755#c1875.
2013-10-17 15:10 Don Cragun Status   Under Review =>
Interpretation Required
2013-10-17 15:10 Don Cragun Resolution   Open => Accepted As
Marked
2013-10-17 15:10 Don Cragun Interp Status--- => Pending  
2014-02-21 15:39 ajosey Interp StatusPending => Proposed 
2014-02-21 15:39 ajosey Note Added: 0002155  
2014-03-25 13:41 ajosey Interp StatusProposed => Approved
2014-03-25 13:41 ajosey Note Added: 0002196  
2014-10-07 11:50 torvaldNote Added: 0002408  
2016-09-09 14:59 torvaldNote Added: 0003375  
==

Re: Quoting: is "${foo-'a"b'"}" valid?

[Chet Ramey]

On 9/9/16 10:10 AM, Jilles Tjoelker wrote:

> What happens in the Bourne shell, ksh93 and FreeBSD sh is that there can
> be an unquoted part in word in "${var-word}" (for the + - = ?
> varieties). As such, the first single quote in "${foo-'a"b'"}" is
> literal but the second single quote introduces a single-quoted string,
> and to terminate the word, '"}" is needed.

This is one of the places I was talking about behavior differences: how
shells handle embedded double quotes in the `word'.  Some let the
double quotes on the rhs of the operator affect the quoting state of the
entire expression, others do not.  This is why it's now unspecified.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Quoting: is "${foo-'a"b'"}" valid?

[Chet Ramey]

On 9/9/16 9:40 AM, Vincent Lefevre wrote:
> On 2016-09-09 09:02:11 -0400, Chet Ramey wrote:
>> On 9/9/16 7:44 AM, Vincent Lefevre wrote:
>>> On 2016-09-05 19:12:54 +, Mark Galeck wrote:
 The standard says in the section 2.2.3 on Double-Quotes and $ :
 "even number of unescaped double-quotes or single-quotes, if any,
 shall occur".
>>>
>>> Concerning this point, these even number of double-quotes and even
>>> number of single-quotes are fulfilled with the example below:
>>>
>>>   echo "${foo-'a"b'"}"
>>>
>>> But is this valid?
>>
>> It's unspecified, so anything goes, as per
>>
>> http://austingroupbugs.net/view.php?id=221
>>
>> "For parameter expansions other than the four varieties that provide
>> for substring processing, within the string of characters from an
>> enclosed "${" to the matching '}', the double-quotes within which
>> the expansion occurs shall preserve the literal value of all
>> characters, with the exception of the characters double-quote,
>> backquote, , and . If any unescaped
>> double-quote characters occur within the string, other than in
>> embedded command substitutions, the behavior is unspecified."
> 
> But this will be only in Issue 8.
> 
> http://austingroupbugs.net/view.php?id=221 is about "poor
> wording", but I don't see where it the above unspecified
> in Issue 7.

OK.  Geoff's position is that the issue 7 text is a requirement on the
application, not the shell, in addition to the wording being ambiguous
about the intent that the requirement applies separately to single
and double quotes (i.e., you can't nest them).

As such, there wasn't any shell behavior to point to as correct when
interpretation 221 was being discussed, and part of the discussion
involved deciding what was correct and expressing it clearly.

The discussion, which took place in 2010, also included the point that
single quotes are not special when the expansion is within double quotes,
so there's no implication that the single quotes begin some separate
"single quote stream," and that shells didn't have to take single quotes
into account when finding the ending brace.

Since the single quotes aren't special, it would seem that the ksh93
behavior, at least, isn't correct and that the correct output is 'ab'.
But that depends on what shells do with the embedded double quotes.

So since the whole reason for the interpretation is that the wording was
bad and shells behaved differently, there can't be any conclusions
drawn from it.  It's a defect in the standard.  However...

The text in issue 8 was supposed to capture the original intent of issue 7,
even if the text in issue 7 didn't do a good job of expressing it.  If you
believe this, the construct is unspecified.

> 
> And one also has:
> 
> "For the four varieties of parameter expansion that provide for
> substring processing (see [xref to 2.6.2 Parameter Expansion]),
> within the string of characters from an enclosed "${" to the
> matching '}', the double-quotes within which the expansion occurs
> shall have no effect on the handling of any special characters."
> 
> There's no unspecified behavior concerning the double quotes.
> So, what about the following?
> 
>   echo "${foo#'a"b'"}"

In this case, it seems to me that the single quotes are special, and the
embedded double quotes are special, so the double quote preceding the
close brace quotes it, and the expansion is incomplete (no closing brace).

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Quoting: is "${foo-'a"b'"}" valid?

[Jilles Tjoelker]

On Fri, Sep 09, 2016 at 03:47:44PM +0200, Vincent Lefevre wrote:
> On 2016-09-09 08:18:57 -0400, shwares...@aol.com wrote:
> > No, it's not valid, that I see... For the purposes of counting the double  
> > quote in a"b loses it's special meaning because a single quote stream has 
> > been  started.

> What do you mean by "a single quote stream has been started", while
> in this context, the single quote is not a special character?

> For instance,

>   echo "${foo-'$(echo a)'}"

> outputs

>   'a'

> but neither

>   $(echo a)

> nor

>   a

> So, it seems that the single quote here is just like any normal
> character. In particular, it is output and does not prevent
> command substitution.

What happens in the Bourne shell, ksh93 and FreeBSD sh is that there can
be an unquoted part in word in "${var-word}" (for the + - = ?
varieties). As such, the first single quote in "${foo-'a"b'"}" is
literal but the second single quote introduces a single-quoted string,
and to terminate the word, '"}" is needed.

Unlike ksh93 and FreeBSD sh, the Bourne shell allows ending a
substitution with a different double-quote state than it started with,
so '} will also terminate the word in the Bourne shell.

Another example is "${a-"*"}" which will expand to the literal contents
of the variable if it is set, and generate pathnames otherwise. This
cannot be done as easily with standard features.

As said elsewhere in the thread, POSIX leaves double quotes in
"${var-word}" (+ - = ?) unspecified.

-- 
Jilles Tjoelker

Re: Quoting: is "${foo-'a"b'"}" valid?

[Vincent Lefevre]

On 2016-09-09 08:18:57 -0400, shwares...@aol.com wrote:
> No, it's not valid, that I see... For the purposes of counting the double  
> quote in a"b loses it's special meaning because a single quote stream has 
> been  started.

What do you mean by "a single quote stream has been started", while
in this context, the single quote is not a special character?

For instance,

  echo "${foo-'$(echo a)'}"

outputs

  'a'

but neither

  $(echo a)

nor

  a

So, it seems that the single quote here is just like any normal
character. In particular, it is output and does not prevent
command substitution.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Quoting: is "${foo-'a"b'"}" valid?

[Vincent Lefevre]

On 2016-09-09 09:02:11 -0400, Chet Ramey wrote:
> On 9/9/16 7:44 AM, Vincent Lefevre wrote:
> > On 2016-09-05 19:12:54 +, Mark Galeck wrote:
> >> The standard says in the section 2.2.3 on Double-Quotes and $ :
> >> "even number of unescaped double-quotes or single-quotes, if any,
> >> shall occur".
> > 
> > Concerning this point, these even number of double-quotes and even
> > number of single-quotes are fulfilled with the example below:
> > 
> >   echo "${foo-'a"b'"}"
> > 
> > But is this valid?
> 
> It's unspecified, so anything goes, as per
> 
> http://austingroupbugs.net/view.php?id=221
> 
> "For parameter expansions other than the four varieties that provide
> for substring processing, within the string of characters from an
> enclosed "${" to the matching '}', the double-quotes within which
> the expansion occurs shall preserve the literal value of all
> characters, with the exception of the characters double-quote,
> backquote, , and . If any unescaped
> double-quote characters occur within the string, other than in
> embedded command substitutions, the behavior is unspecified."

But this will be only in Issue 8.

http://austingroupbugs.net/view.php?id=221 is about "poor
wording", but I don't see where it the above unspecified
in Issue 7.

And one also has:

"For the four varieties of parameter expansion that provide for
substring processing (see [xref to 2.6.2 Parameter Expansion]),
within the string of characters from an enclosed "${" to the
matching '}', the double-quotes within which the expansion occurs
shall have no effect on the handling of any special characters."

There's no unspecified behavior concerning the double quotes.
So, what about the following?

  echo "${foo#'a"b'"}"

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Quoting: is "${foo-'a"b'"}" valid?

[Chet Ramey]

On 9/9/16 7:44 AM, Vincent Lefevre wrote:
> On 2016-09-05 19:12:54 +, Mark Galeck wrote:
>> The standard says in the section 2.2.3 on Double-Quotes and $ :
>> "even number of unescaped double-quotes or single-quotes, if any,
>> shall occur".
> 
> Concerning this point, these even number of double-quotes and even
> number of single-quotes are fulfilled with the example below:
> 
>   echo "${foo-'a"b'"}"
> 
> But is this valid?

It's unspecified, so anything goes, as per

http://austingroupbugs.net/view.php?id=221

"For parameter expansions other than the four varieties that provide
for substring processing, within the string of characters from an
enclosed "${" to the matching '}', the double-quotes within which
the expansion occurs shall preserve the literal value of all
characters, with the exception of the characters double-quote,
backquote, , and . If any unescaped
double-quote characters occur within the string, other than in
embedded command substitutions, the behavior is unspecified."

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Quoting: is "${foo-'a"b'"}" valid?

[Steffen Nurpmeso]

shwares...@aol.com wrote:
 ||> The standard says in the section 2.2.3 on Double-Quotes and $ :
 ||> "even number of unescaped double-quotes or single-quotes, if any,
 ||> shall occur".
 ||
 ||Concerning this point, these even number of double-quotes and even
 ||number of single-quotes are fulfilled with the example below:
 ||
 ||  echo "${foo-'a"b'"}"
 ||
 ||But is this valid?

 |No, it's not valid, that I see... For the purposes of counting the \
 |double quote in a"b loses it's special meaning because a single quote \
 |stream has been 
 |started. The double quote after the closing single quote is matched \

That is an interesting question, and what would have been my
thought, too.

 |by the double quote after the right brace. ksh is waiting for an additional\
 | right 
 |brace and double quote to be typed to complete the command, it seems, \
 |which is proper, and if done should output a"b}. The others appear \

Yes, i would also think the } is double-quote quoted, so this
should have ended up as a"b} and then awaiting more input.
I really wondered how the other interpretations materialize
(except being (bug-)compatible with each other)?

--steffen

Re: Quoting: is "${foo-'a"b'"}" valid?

[SHwareSyst]

No, it's not valid, that I see... For the purposes of counting the double  
quote in a"b loses it's special meaning because a single quote stream has 
been  started. The double quote after the closing single quote is matched by 
the  double quote after the right brace. ksh is waiting for an additional 
right brace  and double quote to be typed to complete the command, it seems, 
which is proper,  and if done should output a"b}. The others appear to be 
doing  quote removal on just the double quotes, treating the single quotes 
as regular  characters.
 
 
In a message dated 9/9/2016 7:44:55 A.M. Eastern Daylight Time,  
vincent-o...@vinc17.net writes:

On  2016-09-05 19:12:54 +, Mark Galeck wrote:
> The standard says in the  section 2.2.3 on Double-Quotes and $ :
> "even number of unescaped  double-quotes or single-quotes, if any,
> shall  occur".

Concerning this point, these even number of double-quotes and  even
number of single-quotes are fulfilled with the example  below:

echo "${foo-'a"b'"}"

But is this valid?

The  following shells output 'ab' (with the single quotes):
dash, bash --posix,  mksh, posh, zsh.

But not ksh93, which outputs a ">" prompt:

$  echo "${foo-'a"b'"}"
>

and if I type Ctrl-D, I get:

$ echo  "${foo-'a"b'"}"
> ksh93: syntax error: `'' unmatched

--  
Vincent Lefèvre  - Web:  
100% accessible validated (X)HTML - Blog:  
Work: CR INRIA - computer arithmetic /  AriC project (LIP,  ENS-Lyon)

Quoting: is "${foo-'a"b'"}" valid?

[Vincent Lefevre]

On 2016-09-05 19:12:54 +, Mark Galeck wrote:
> The standard says in the section 2.2.3 on Double-Quotes and $ :
> "even number of unescaped double-quotes or single-quotes, if any,
> shall occur".

Concerning this point, these even number of double-quotes and even
number of single-quotes are fulfilled with the example below:

  echo "${foo-'a"b'"}"

But is this valid?

The following shells output 'ab' (with the single quotes):
dash, bash --posix, mksh, posh, zsh.

But not ksh93, which outputs a ">" prompt:

$ echo "${foo-'a"b'"}"
>

and if I type Ctrl-D, I get:

$ echo "${foo-'a"b'"}"
> ksh93: syntax error: `'' unmatched

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Event [Austin Group teleconference +1-888-426-6840 PIN: 2115756] 2016-09-15 at 11:00 America/New_York created

[Single UNIX Specification]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.18//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:STANDARD
DTSTART:20161106T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20170312T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:57d27b78a3...@opengroup.org
DTSTAMP:20160909T090600Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20160909T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1-888-426-6840 PIN: 2115756\nDate/Time: 15-Sep-2016 at 11:00 
 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengro
 up.org/platform/single_unix_specification/events.php\n\n* All calls are an
 chored on US time **\n\nTopic: Austin Group teleconference\n--
 -\nAudio conference information\n-
 --\nCall-in toll free 
 number (US/Canada): +1-888-426-6840\nParticipant PIN: 2115756.\n\nAll Aust
 in Group participants are most welcome to join the call.\nThe call will la
 st for 1.5 hours .\nThis call is handling defect report processing.\n\nirc
 ://irc.freenode.org/austingroupbugs\nAn etherpad is usually up for a meeti
 ng\, with a URL using the date format as below:\n\nhttp://po...@posix.rhan
 sen.org:9001/p/201x-mm-dd\npassword=2115756#\nAdditional Call-in numbers:
 \nGermany Caller Paid0-69-2443-2290\nGermany  
Toll-Free   0800-000-1018\nUnited Kingdom  
  Caller Paid   0-20-30596451\nUnited Kingdom   Toll-Free  
 0800-368-0638\nUSA Caller Paid   2
 15-861-6239\nUSAToll-Free   888-426-68
 40\nDenmark Caller Paid32711870\nDenmark  
Toll-Free   80-717000\nCzech Republic  Call
 er Paid 2-39016353\nCzech Republic  Toll-Free 
   800-143-484\nCall-in numbers for other countries are available on re
 quest\n\nBug reports are available at:\nhttp://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20160915T11
DURATION:PT1H30M0S
LAST-MODIFIED:20160909T050600Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1-888-426-6840 PIN: 2115756
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics