[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been set as RELATED TO issue 0001645. == https://www.austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Applied Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Approved Final Accepted Text:See https://www.austingroupbugs.net/view.php?id=953#c4214 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-10-21 09:30 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... related to 0001342 Aliases in command substitutions are ha... related to 0001645 execvp( ) requirements on arg0 are too ... == Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See https://www.austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152 2016-04-12 14:49 joerg Note
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been set as RELATED TO issue 0001342. == https://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Applied Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Approved Final Accepted Text:See https://austingroupbugs.net/view.php?id=953#c4214 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-10-21 09:30 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... related to 0001342 Aliases in command substitutions are ha... == Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See https://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152 2016-04-12 14:49 joerg Note Added: 0003153 2016-04-13 09:07 joerg Note
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has a resolution that has been APPLIED. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Applied Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Approved Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c4214 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-10-21 09:30 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See http://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152 2016-04-12 14:49 joerg Note Added: 0003153 2016-04-13 09:07 joerg Note Edited: 0003153 2016-04-13 17:15 chet_ramey Note
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Approved Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c4214 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-04-17 10:52 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0004366) agadmin (administrator) - 2019-04-17 10:52 http://austingroupbugs.net/view.php?id=953#c4366 -- Interpretation approved: 17 April 2019 Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See http://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Proposed Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c4214 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-02-07 17:15 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0004243) agadmin (administrator) - 2019-02-07 17:15 http://austingroupbugs.net/view.php?id=953#c4243 -- Interpretation proposed: 7 Feb 2019 Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See http://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Pending Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c4214 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-02-07 16:36 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See http://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152 2016-04-12 14:49 joerg Note Added: 0003153 2016-04-13 09:07 joerg Note Edited: 0003153 2016-04-13 17:15 chet_ramey Note Added: 0003154 2016-04-13 17:43 Don Cragun Note Edited:
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Harald van Dijk wrote, on 01 Feb 2019: > > On 01/02/2019 09:53, Geoff Clare wrote: > >I agree that's an improvement, but I see one slight problem with it: it > >says "tokens previously read from the input" but the previous tokens > >could have come from an alias substitution. Here's an attempt to fix > >that: > > > > * the TOKEN could be parsed as the command name word of a simple > >command (see [xref to Section 2.10]), based on this TOKEN and > >the tokens (if any) that preceded it, but ignoring whether any > >subsequent characters would allow that > > Good point, that looks better. I have updated note 4214 with this change and the other two changes discussed in this sub-thread. I also added the foo((123)) example to the application usage section on the alias page. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Date:Fri, 1 Feb 2019 20:46:18 + From:Harald van Dijk Message-ID: | Your proposed wording makes this conditional on whether or not | the token is the first in the input stream. That wasn't the intent - there was an alternation, either the first token (which is always subject to alias lookup) or one that follows tokens that have ended the previous command (etc) so we're starting a new one. Geoff's "if any" accomplished much thge same thing. Howeverm I don't pretend to be good at writing clear text, the more important part was what came after, not that part. kre
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 01/02/2019 09:56, Robert Elz wrote: Date:Fri, 1 Feb 2019 08:00:16 + From:Harald van Dijk Message-ID: <5cd22a9c-b213-8ffb-da45-f71057eba...@gigawatt.nl> | I was referring to the second token on the second line, which is foo, | not foo=bar. Oh, sorry, I was in too much of a rush this morning, and did not read all that carefully (or really, at all...) For that I might, if some different wording to what is currently proposed is needed, use something like: * the TOKEN is the first token observed, or follows other tokens which would allow this TOKEN to become the command word of a simple command [xref], should the (unrecognised yet) following tokens (if any) allow the token sequence to be parsed that way, but regardless of what tokens follow. That does not look right: this bullet point is the one that requires shells to not perform alias substitution on reserved words (since they would not be parsed as the command name word of a simple command). Your proposed wording makes this conditional on whether or not the token is the first in the input stream. Cheers, Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 01/02/2019 09:53, Geoff Clare wrote: I agree that's an improvement, but I see one slight problem with it: it says "tokens previously read from the input" but the previous tokens could have come from an alias substitution. Here's an attempt to fix that: * the TOKEN could be parsed as the command name word of a simple command (see [xref to Section 2.10]), based on this TOKEN and the tokens (if any) that preceded it, but ignoring whether any subsequent characters would allow that Good point, that looks better. Cheers, Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 01/02/2019 02:55, Robert Elz wrote: Date:Thu, 31 Jan 2019 22:04:30 + From:Harald van Dijk Message-ID: <126fa44f-05bb-abc2-d6c9-40b82b36f...@gigawatt.nl> |alias foo=bar |echo foo | | alias substitution should not be performed on "foo". foo=bar is one TOKEN, not 2 or 3, and the one char that aliases don't get to have in their names is '=' (except possibly the first) so even if a lookup was done on that, it can never match. No need for any special language to handle that case. I was referring to the second token on the second line, which is foo, not foo=bar. Cheers, Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Date:Thu, 31 Jan 2019 22:04:30 + From:Harald van Dijk Message-ID: <126fa44f-05bb-abc2-d6c9-40b82b36f...@gigawatt.nl> |alias foo=bar |echo foo | | alias substitution should not be performed on "foo". foo=bar is one TOKEN, not 2 or 3, and the one char that aliases don't get to have in their names is '=' (except possibly the first) so even if a lookup was done on that, it can never match. No need for any special language to handle that case. kre
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Harald van Dijk wrote, on 28 Jan 2019:
>
> >>> If it does not add this , and the last character of
> >>>the alias value could be part of an operator token, it is unspecified
> >>>whether the current token is delimited before token recognition is applied
> >>>to the character (if any) that followed the TOKEN in the input.
> >>
> >>Limiting this to operator tokens will mean, I believe, that in other cases
> >>(unterminated words, heredocs, comments) shells are required to treat the
> >>subsequent characters as part of whatever the alias substitution resulted
> >>in. Is that intentional? Many shells have some corner cases where the end of
> >>an alias substitution delimits a word:
> >>
> >> alias foo='echo $'
> >> foo((123))
> >
> >According to the current wording of note 4214 the foo here is not
> >subject to alias substitution (because of the last condition in the
> >bullet list, "the TOKEN will be parsed as the command name word of a
> >simple command ...")
> >
> >Since foo((123)) is a syntax error as far as the standard grammar is
> >concerned, shells can either report a syntax error or accept the syntax
> >as an extension (with unspecified results).
>
> This could be a re-hash of everyone telling me why that interpretation was
> wrong in the "Alias implementations being invalidated by proposed new
> wording?" thread. This interpretation would mean that
>
> alias foo=#
> foo ()
> {
> echo hello
> }
>
> must print nothing and define a function named foo, since foo is not the
> command name word of a simple command. Pretty much all shells do perform
> alias substitution here (the one exception I know of being mksh), so print
> hello and do not define any function.
>
> What everyone was telling me was that alias recognition happens once a token
> is read. The token just read is foo, and the parser is in a state where foo
> could be interpreted as the command name word of a simple command (without
> looking at the next characters), therefore it is subject to alias
> substitution. This applies to both the examples. If the proposed wording
> does not properly reflect that, that may be a problem in the wording.
Okay, it looks like that last bullet item doesn't match existing
practice. Instead of:
* the TOKEN will be parsed as the command name word of a simple
command when the grammatical rules in Section 2.10 are applied
how about:
* the TOKEN could be parsed as the command name word of a simple
command (see [xref to Section 2.10]), regardless of whether any
subsequent tokens in the input would allow that
> >>I think the text can be reduced to
> >>
> >> If it does not add this , it is unspecified whether the current
> >> token is delimited [...]
If the last bullet item is changed along the lines I suggested above,
then I agree with your suggested change here.
> >>This proposed resolution does not leave empty aliases (aliases not resulting
> >>in any token) unspecified.
> >
> >It does if the alias is truly empty. It says that token recognition
> >resumes "at the first character of the alias value". Thus it is silent
> >about the behaviour when there is no first character. However, you're
> >right that it should say something about other no-token values.
>
> Oh, I missed that. Right, there is no benefit in treating
>
> alias foo=""
> and
> alias foo=" "
>
> differently here. The former works in exactly the same shells as the latter,
> as far as I know.
>
> So should this be specified to work, and the shells in which it doesn't
> considered to be buggy?
>
> If so, would it suffice to change
>
> resuming at the first character of the alias value
>
> to
>
> resuming at the start of the alias value
That would be fine with me.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Date:Mon, 28 Jan 2019 12:53:27 + From:Stephane Chazelas Message-ID: <20190128125327.m3betjroiqodf...@chaz.gmail.com> | D'oh. Sorry. It looks like the same bug. Note that it affects | busybox sh and FreeBSD sh as well, so probably all ash-derived | shells (unless Robert already fixed that one on NetBSD). No. I don't consider aliases either useful, or important, enough to waste time on fixing weirdness. I had seen that one before, and unless a script using it ends right there (where the alias is used) it works as expected. It affects command line usage more (as the shell won't give up on PS2 prompting for more until it gets a command) but I think it unlikely that anyone would use an alias like that from the command line. Hence not worth bothering with... kre
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 28/01/2019 12:53, Stephane Chazelas wrote: D'oh. Sorry. It looks like the same bug. Note that it affects busybox sh and FreeBSD sh as well, so probably all ash-derived shells (unless Robert already fixed that one on NetBSD). I fixed it in mine back in September, so definitely not *all* ash-derived shells... :) That's how I could be sure enough to say it is easy to fix. Cheers, Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
2019-01-28 08:08:53 +, Harald van Dijk: [...] > > alias ifdebug= > > ifdebug echo DEBUG > > > > works fine in dash AFAICT. > > The non-DEBUG case is alias ifdebug=# to comment out the command. > > $ dash < > alias ifdebug=# > > ifdebug echo DEBUG > > EOF > dash: 3: Syntax error: end of file unexpected [...] D'oh. Sorry. It looks like the same bug. Note that it affects busybox sh and FreeBSD sh as well, so probably all ash-derived shells (unless Robert already fixed that one on NetBSD). Adding a "exit" at the end of your script works around it but not an empty or comment line. -- Stephane
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Harald van Dijk wrote, on 27 Jan 2019: > > On 18/01/2019 11:48, Austin Group Bug Tracker wrote: > >-- > > (0004214) geoffclare (manager) - 2019-01-18 11:48 > > http://austingroupbugs.net/view.php?id=953#c4214 > >-- > >Alternative resolution, based on kre's suggestion on the mailing list. [...] > A corner case which should probably remain unspecified is when the resulting > token partially results from an alias substitution of the same alias name at > any earlier recursion level: > > alias echo='ec\' > echo > ho hello > > Shells vary in how they treat this and I cannot see any value in requiring > any particular behaviour here: no sensible script is going to rely on this. > It could be left implicitly unspecified by the current proposed wording, but > could alternatively be made explicitly unspecified by something along the > lines of > > [...] > the TOKEN did not fully result from an alias substitution of the same > alias name at any earlier recursion level, and > optionally, the TOKEN did not partially result from an alias substitution > of the same alias name at any earlier recursion level, and > [...] I think there needs to be something explicit here. I'd prefer to try and word it without so much repetition. Perhaps: the TOKEN did not either fully or, optionally, partially result from an alias substitution of the same alias name at any earlier recursion level, and > > If it does not add this , and the last character of > >the alias value could be part of an operator token, it is unspecified > >whether the current token is delimited before token recognition is applied > >to the character (if any) that followed the TOKEN in the input. > > Limiting this to operator tokens will mean, I believe, that in other cases > (unterminated words, heredocs, comments) shells are required to treat the > subsequent characters as part of whatever the alias substitution resulted > in. Is that intentional? Many shells have some corner cases where the end of > an alias substitution delimits a word: > > alias foo='echo $' > foo((123)) According to the current wording of note 4214 the foo here is not subject to alias substitution (because of the last condition in the bullet list, "the TOKEN will be parsed as the command name word of a simple command ...") Since foo((123)) is a syntax error as far as the standard grammar is concerned, shells can either report a syntax error or accept the syntax as an extension (with unspecified results). > When this is combined with heredocs, shells again behave differently: > > alias foo='cat < $' > foo((123)) > EOF Again, foo((123)) is a syntax error as far as the standard grammar is concerned. > I think the text can be reduced to > > If it does not add this , it is unspecified whether the current > token is delimited [...] > > to let that be unspecified. This covers heredocs as well: they are specified > to be treated as a single word, so I would say they implicitly have > unspecified or undefined behaviour if the end of the alias substitution > causes that word to be delimited. This allows shells to continue treating > them in whatever way they do now. It does not cover comments, but I am not > aware of (released versions of) shells that do not handle those. I believe that within the standard grammar, unless the alias value ends with quoting or commenting "on", the only way a command word of a simple command can be delimited by something that can combine with the end of the alias value to form a token, is if the command word is delimited by &, ;, |, <, or >. In these cases the resulting token is an operator (&&, ;;, ||, and various redirections). In the cases where the value ends with quoting or commenting "on", I thought that all shells that don't add a space behave the same (or if they don't, they are considered buggy), so by making the behaviour unspecified only for operator tokens these cases would remain specified. > This proposed resolution does not leave empty aliases (aliases not resulting > in any token) unspecified. It does if the alias is truly empty. It says that token recognition resumes "at the first character of the alias value". Thus it is silent about the behaviour when there is no first character. However, you're right that it should say something about other no-token values. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 28/01/2019 06:38, Stephane Chazelas wrote: I'm saying POSIX should not make the behaviour unspecified for empty aliases. Only, if at all, when the expansion results in no command. Because empty aliases are useful when followed by something else like in the example I gave. That makes sense, though it may be difficult to specify properly. [...] And dash has no issue with that code. It does have an issue with exactly what you wrote: try putting ifdebug before the very last line in a script, in the non-DEBUG case where the command is commented out. [...] alias ifdebug= ifdebug echo DEBUG works fine in dash AFAICT. The non-DEBUG case is alias ifdebug=# to comment out the command. $ dash < alias ifdebug=# > ifdebug echo DEBUG > EOF dash: 3: Syntax error: end of file unexpected Cheers, Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 27/01/2019 21:17, Stephane Chazelas wrote:
2019-01-27 02:29:04 +, Harald van Dijk:
[...]
This proposed resolution does not leave empty aliases (aliases not resulting
in any token) unspecified. I mentioned them before, because they are
mishandled by at least one shell:
$ dash -c 'alias empty=
empty'
dash: 2: Syntax error: end of file unexpected
I'd be perfectly okay with considering that a bug in dash (I personally
consider it exactly that, and it's easy to fix), but I do not know whether
there are different situations in other shells that also fail for other
reasons and require major changes to their implementations of aliases to
solve.
[...]
But then again
alias empty=
{ empty; }
or
(empty)
Also fails in many shells (and don't fail in some shells where
{ ;} or () otherwise fails).
The problem is not that much about empty aliases here but about
when alias expansion results in no command where that's not
expected.
I cannot find any shell in which { empty; } and { ; } behave
differently. ksh and zsh accept this, with or without the empty alias.
Everything else I tried (bash, bosh, dash, mksh, pdksh, yash) rejects
it, again with or without the empty alias.
I cannot find any shell in which (empty) and ( ) behave differently.
mksh, pdksh and zsh accept this, everything else I tried rejects this,
with or without the alias.
I can find one where () and ( ) behave differently, zsh, which also
makes it one where () and (empty) behave differently. That is because ()
is read as a single token, but either the space or the empty alias
forces it to be read as two separate single-character tokens.
Empty aliases are useful and often used in things like:
if [ "$DEBUG" ]; then
alias ifdebug=
else
alias ifdebug='#'
fi
ifdebug log "$(cmd)"
If it were implemented with a function instead, cmd would still
be run. aliases avoids that but you need to remember to keep
your debug commands on a single line.
You could avoid empty aliases here to let it work in dash and support
multi-line commands at the same time:
if [ "$DEBUG" ]; then
alias ifdebug=': && '
else
alias ifdebug=': || '
fi
And dash has no issue with that code.
It does have an issue with exactly what you wrote: try putting ifdebug
before the very last line in a script, in the non-DEBUG case where the
command is commented out.
Cheers,
Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
2019-01-27 02:29:04 +, Harald van Dijk:
[...]
> This proposed resolution does not leave empty aliases (aliases not resulting
> in any token) unspecified. I mentioned them before, because they are
> mishandled by at least one shell:
>
> $ dash -c 'alias empty=
> empty'
> dash: 2: Syntax error: end of file unexpected
>
> I'd be perfectly okay with considering that a bug in dash (I personally
> consider it exactly that, and it's easy to fix), but I do not know whether
> there are different situations in other shells that also fail for other
> reasons and require major changes to their implementations of aliases to
> solve.
[...]
But then again
alias empty=
{ empty; }
or
(empty)
Also fails in many shells (and don't fail in some shells where
{ ;} or () otherwise fails).
The problem is not that much about empty aliases here but about
when alias expansion results in no command where that's not
expected.
Empty aliases are useful and often used in things like:
if [ "$DEBUG" ]; then
alias ifdebug=
else
alias ifdebug='#'
fi
ifdebug log "$(cmd)"
If it were implemented with a function instead, cmd would still
be run. aliases avoids that but you need to remember to keep
your debug commands on a single line.
And dash has no issue with that code. I'd say it's unlikely for
the dash issue (which I'd agree to call a bug) to be hit in
practice though you could imagine convoluted things like:
if [ "$DEBUG" ]; then
alias ifdebug= endifdebug=
else
alias ifdebug='if false; then' endifdebug=fi
fi
ifdebug
cmd
endifdebug
--
Stephane
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 18/01/2019 11:48, Austin Group Bug Tracker wrote: -- (0004214) geoffclare (manager) - 2019-01-18 11:48 http://austingroupbugs.net/view.php?id=953#c4214 -- Alternative resolution, based on kre's suggestion on the mailing list. [...] If the value of the alias replacing the word ends in a , the shell shall check the next command word for alias substitution; this process shall continue until a word is found that is not a valid alias or an alias value does not end in a .to:After a token has been categorized as type TOKEN (see [xref to 2.10.1]), including (recursively) any token resulting from an alias substitution, the TOKEN shall be subject to alias substitution if: the TOKEN does not contain any quoting characters, the TOKEN is a valid alias name (see XBD Section 3.10), an alias with that name is in effect, and the TOKEN did not result from an alias substitution of the same alias name at any earlier recursion level, except that if the TOKEN meets the above conditions and would be recognized as a reserved word (see [xref to 2.4 Reserved Words]) if it occurred in an appropriate place in the input, it is unspecified whether the TOKEN is subject to alias substitution. I believe this wording also solves a problem not covered by the earlier proposed resolution: alias echo=echo echo hello Alias recognition was specified to happen "[a]fter a token has been delimited" and "if the shell is not currently processing an alias of the same name", but after the first alias substitution, the resulting token is only delimited when the space is seen again, and at that point, the shell is no longer currently processing an alias of the same name. This proposed wording covers it by instead letting it depend on whether the token resulted from alias substitution. A corner case which should probably remain unspecified is when the resulting token partially results from an alias substitution of the same alias name at any earlier recursion level: alias echo='ec\' echo ho hello Shells vary in how they treat this and I cannot see any value in requiring any particular behaviour here: no sensible script is going to rely on this. It could be left implicitly unspecified by the current proposed wording, but could alternatively be made explicitly unspecified by something along the lines of [...] the TOKEN did not fully result from an alias substitution of the same alias name at any earlier recursion level, and optionally, the TOKEN did not partially result from an alias substitution of the same alias name at any earlier recursion level, and [...] If it does not add this , and the last character of the alias value could be part of an operator token, it is unspecified whether the current token is delimited before token recognition is applied to the character (if any) that followed the TOKEN in the input. Limiting this to operator tokens will mean, I believe, that in other cases (unterminated words, heredocs, comments) shells are required to treat the subsequent characters as part of whatever the alias substitution resulted in. Is that intentional? Many shells have some corner cases where the end of an alias substitution delimits a word: alias foo='echo $' foo((123)) When this is combined with heredocs, shells again behave differently: alias foo='cat <, it is unspecified whether the current token is delimited [...] to let that be unspecified. This covers heredocs as well: they are specified to be treated as a single word, so I would say they implicitly have unspecified or undefined behaviour if the end of the alias substitution causes that word to be delimited. This allows shells to continue treating them in whatever way they do now. It does not cover comments, but I am not aware of (released versions of) shells that do not handle those. This proposed resolution does not leave empty aliases (aliases not resulting in any token) unspecified. I mentioned them before, because they are mishandled by at least one shell: $ dash -c 'alias empty= empty' dash: 2: Syntax error: end of file unexpected I'd be perfectly okay with considering that a bug in dash (I personally consider it exactly that, and it's easy to fix), but I do not know whether there are different situations in other shells that also fail for other reasons and require major changes to their implementations of aliases to solve. Cheers, Harald van Dijk
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Pending Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c3113 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-01-18 11:48 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0004214) geoffclare (manager) - 2019-01-18 11:48 http://austingroupbugs.net/view.php?id=953#c4214 -- Alternative resolution, based on kre's suggestion on the mailing list. All page and line numbers are for the 2016 and 2018 editions. On page 2348 line 74794-74805 (XCU 2.3.1 Alias Substitution), change:After a token has been delimited, but before applying the grammatical rules in Section 2.10, a resulting word that is identified to be the command name word of a simple command shall be examined to determine whether it is an unquoted, valid alias name. However, reserved words in correct grammatical context shall not be candidates for alias substitution. A valid alias name (see XBD Section 3.10) shall be one that has been defined by the alias utility and not subsequently undefined using unalias. Implementations also may provide predefined valid aliases that are in effect when the shell is invoked. To prevent infinite loops in recursive aliasing, if the shell is not currently processing an alias of the same name, the word shall be replaced by the value of the alias; otherwise, it shall not be replaced. If the value of the alias replacing the word ends in a , the shell shall check the next command word for alias substitution; this process shall continue until a word is found that is not a valid alias or an alias value does not end in a .to:After a token has been categorized as type TOKEN (see [xref to 2.10.1]), including (recursively) any token resulting from an alias substitution, the TOKEN shall be subject to alias substitution if: the TOKEN does not contain any quoting characters, the TOKEN is a valid alias name (see XBD Section 3.10), an alias with that name is in effect, and the TOKEN did not result from an alias substitution of the same alias name at any earlier recursion level, except that if the TOKEN meets the above conditions and would be recognized as a reserved word (see [xref to 2.4 Reserved Words]) if it occurred in an appropriate place in the input, it is unspecified whether the TOKEN is subject to alias substitution. When a TOKEN is subject to alias substitution, the value of the alias shall be processed as if it had been read from the input instead of the TOKEN, with token recognition (see [xref to 2.3 Token Recognition]) resuming at the first character of the alias value. When the end of the alias value is reached, the shell may behave as if an additional character had been read from the input after the TOKEN that was replaced. If it does not add this , and the last character of the alias value could be part of an operator token, it is unspecified whether the current token is delimited before token recognition is applied to the character (if any) that followed the TOKEN in the input. Note: a future version of this standard may disallow adding this . If the value of the alias replacing the TOKEN ends in a that would be unquoted after substitution, and optionally if it ends in a that would be quoted after substitution, the shell shall check the next token in the input, if it is a TOKEN,
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Stephane Chazelas wrote, on 09 Jan 2019: > > I'd rather POSIX forbade applications to use "while", "until", > "do", "select", "time", etc in alias names, or leave it > unspecified whether aliases for those are expanded. I have updated bugnote 4201 to make this unspecified. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
I have made the changes below in bugnote 4201, and also the one that Harald spotted (removal of ", unlike the contents of a dot script"). Regards, Geoff. Geoff Clare wrote, on 09 Jan 2019: > > Robert Elz wrote, on 09 Jan 2019: > > > > There are just a couple of minor points that I have with your > > wording, one where I think a little more clarity is needed, and > > one where your wording isn't quite correct. > > > > > > | ... change to: > > > > | After a TOKEN has been delimited, > > > > This is where I think a little extra clarity would help, and > > I'd change that to be > > > > After a token of type TOKEN [xref XCU 2.10.1] has > > been delimited, > > > > just to make it clear that TOKEN is a specific type of token, > > and not just a weird typographical convention (it helps readers > > interpret the meaning more easily). > > The sentence before this (at the end of 2.3) is "Once a token is > delimited, it is categorized as required by the grammar in [xref to > 2.10]", so I'd like to go with: > > After a token has been categorized as type TOKEN (see [xref to 2.10.1]), > > > | If the value of the alias replacing the TOKEN ends in a that > > would > > | be unquoted after substitution, and optionally if it ends in a > > that > > | would be quoted after substitution, the shell shall check the next > > TOKEN in > > | the input for alias substitution; > > > > This is where the wording is incorrect, it is not the next TOKEN, which > > would imply simply skipping intermediate operators, etc, but the next > > token, if and only if, it is a TOKEN, that it is considered for alias > > substitution. > [...] > > > > So I would change > > shall check the next TOKEN in the input > > into > > shall check the next token in the input, if it is a TOKEN, > > Good catch - I'll make that change. > > I've also just noticed that 2.10.1 and 2.10.2 have TOKEN in bold everywhere, > so I suppose I should do the same. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 1/11/19 8:15 AM, Stephane Chazelas wrote: > 2019-01-10 19:01:08 -0500, Chet Ramey: >> On 1/10/19 5:29 PM, Stephane Chazelas wrote: >> >>> In any case, by no longer allowing pipelines, redirections, >>> multiple commands, keywords, comments in alias values, empty or >>> blank aliases, that proposed change breaks many applications, >>> especially scripts. >> >> I'm not sure making those cases unspecified "breaks many applications." >> Shells, even posix shells in posix mode, are free to accept any or >> all of the above, just as they do today. > [...] > > I re-used kre's "break" here which I believe he meant as: would > make applications no longer conformant (IOW, applications would > mean to be modified to be confomant again, or may not be > portable to newer shells written based on the new text of the > standard). Maybe. However, until those hypothetical future shells appear, the applications are no less portable than they are today. They will run under the same shells they run under now. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 1/11/19 5:27 AM, Joerg Schilling wrote: > Stephane Chazelas wrote: > >> alias for=pour >> alias do=faire >> alias to_french='echo ' >> >> for word in for do; do >> eval "to_french $word" >> done >> >> (which already doesn't work in bash except in posix mode nor in >> zsh in posix mode or not). > > From looking at the error message from bash. it seems that the reason why > bash > fails here is that it parses scripts as a whole and thus does not expand > aliases inside scripts at all. The latter is true by default; the former is not. You can enable alias expansion in non-interactive shells with an option. > If you check the same in an interactive bash 5, you even get error messages > that lead to an implementation bug. There's no bug. Bash allows reserved words to be alias expanded when not in posix mode. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Stephane Chazelas wrote: > alias for=pour > alias do=faire > alias to_french='echo ' > > for word in for do; do > eval "to_french $word" > done > > (which already doesn't work in bash except in posix mode nor in > zsh in posix mode or not). >From looking at the error message from bash. it seems that the reason why bash fails here is that it parses scripts as a whole and thus does not expand aliases inside scripts at all. If you check the same in an interactive bash 5, you even get error messages that lead to an implementation bug. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 1/10/19 5:29 PM, Stephane Chazelas wrote: > In any case, by no longer allowing pipelines, redirections, > multiple commands, keywords, comments in alias values, empty or > blank aliases, that proposed change breaks many applications, > especially scripts. I'm not sure making those cases unspecified "breaks many applications." Shells, even posix shells in posix mode, are free to accept any or all of the above, just as they do today. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
2019-01-10 04:00:37 +0700, Robert Elz:
[...]
> Nor can we tell the shells not to expand words that would be
> keywords when used elsewhere as currently users have the
> ability to do that, and we cannot break existing conforming
> applications.
[...]
It seems there's been a misunderstanding. I'm not proposing to
break shell implementations. My proposed change would on the
contrary give more freedom to implementations while giving
slightly less freedom to applications (in areas where nobody
cares anyway) and also align with existing implementations
(including zsh, bash when not in POSIX mode, and AT ksh).
I've just realised I had already made that point in 2016 at
http://austingroupbugs.net/view.php?id=953#c3195
To rephrase it:
Currently and with the currently proposed change, the spec more
or less tells us, the application writers:
> You can pick whatever name you want for your alias provided
> it's a [a-zA-Z0-9_!%@,]* name (and unspecified if not)
>
> If you pick a name that happens to be the name of any of the
> shell reserved words (if, do, in, !, while...), that alias
> will be expanded except in the situations where that name is
> recognised as a reserved word.
What I'm saying is that it would be more useful to make it:
> You can pick whatever name you want for your alias provided
> it's a [a-zA-Z0-9_!%@,]+ name and is not the name of a shell
> reserved word (and unspecified if not)
(also note the change from * to + above)
And leave off the part about expansion or not of aliases for
reserved words since one can't use a reserved word as an alias.
That allows shells to do the more sensible thing of allowing
aliasing reserved words like bash or zsh do (when not in sh
mode) or ksh (for "select" only, not a concern here as portable
applications can't use "select", aliases or not, except quoted)
The only applications that that proposed change would break
would be the hypothetical ones that would do things like:
alias for=pour
alias do=faire
alias to_french='echo '
for word in for do; do
eval "to_french $word"
done
(which already doesn't work in bash except in posix mode nor in
zsh in posix mode or not).
I'm not aware that anybody uses aliases that way. The trailing
blank thing is more about "alias env='env '" when you want your
aliases (but here aliases to commands not to random French
words) to be expanded after "env".
In any case, by no longer allowing pipelines, redirections,
multiple commands, keywords, comments in alias values, empty or
blank aliases, that proposed change breaks many applications,
especially scripts. The ones that are least likely to be broken
are the interactive usage ones like "alias ll='ls -l'" or "alias
sudo='sudo '", but no one cares about POSIX compliance
interactively.
For instance, among my posts on unix.stackexchange.com, at a
quick glance, these would have alias usages that would become
non-conformant:
https://unix.stackexchange.com/a/63868
https://unix.stackexchange.com/a/65113
https://unix.stackexchange.com/a/86785
https://unix.stackexchange.com/a/146147
https://unix.stackexchange.com/a/174681
https://unix.stackexchange.com/a/253505
https://unix.stackexchange.com/a/323132
https://unix.stackexchange.com/a/367112
https://unix.stackexchange.com/a/372484
https://unix.stackexchange.com/a/375157
https://unix.stackexchange.com/a/388257
https://unix.stackexchange.com/a/388697
https://unix.stackexchange.com/a/390285
https://unix.stackexchange.com/a/462760
https://unix.stackexchange.com/a/469773
https://unix.stackexchange.com/a/485501
And most usages of "alias" by modernish
(https://github.com/modernish/modernish):
~/git/modernish$ grep -Pr '^\s*alias\s' .
./bin/modernish:alias readonly='typeset -rg' ;;
./bin/modernish:alias test=test 2>|/dev/null || _Msh_have FTL_NOALIAS 'No
support for aliases at all.'
./bin/modernish:alias _Msh_testFn=:
./bin/modernish:alias local=typeset
./bin/modernish:alias not='! ' # note: final space = continue to
expand aliases
./bin/modernish:alias so='{ let "$?==0"; }' # we'll add 'let' to shells
without it
./bin/modernish:alias forever='while :;'
./bin/modernish:alias die='_Msh_doExit 128'
./bin/modernish:alias exit=_Msh_doExit
./bin/modernish:alias export=_Msh_issetExHandleExport
./bin/modernish:alias shellquoteparams='{ '\
./bin/modernish:alias source='_Msh_doSource "$#" "$@"'
./bin/modernish:alias let='let --'
./bin/modernish:alias readonly='typeset -r"$([[ -o posixbuiltins ]] &&
builtin echo g)"'
./libexec/modernish/var/local.mm:alias LOCAL="{ ${_Msh_sL_ksh93}unset -v
_Msh_sL; { _Msh_sL_LOCAL ${_Msh_sL_LINENO}"
./libexec/modernish/var/local.mm:alias BEGIN="}; isset _Msh_sL &&
_Msh_sL_temp() { eval \"\${_Msh_PPs+unset -v _Msh_PPs; set -- \${_Msh_PPs}}\"; "
./libexec/modernish/var/local.mm:alias END="} || die 'LOCAL: init lost';
_Msh_sL_temp \"\$@\"; _Msh_sL_END \"\$?\" ${_Msh_sL_LINENO}; }"
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Harald van Dijk wrote, on 09 Jan 2019: > > > http://austingroupbugs.net/view.php?id=953#c4201 [...] > >(In other words, the contents of the ENV file are not parsed as a single > >compound_list, unlike the contents of a dot script. This > >distinction matters because it influences when aliases take > >effect.) > > This last bit was part of an earlier version, but it no longer fits now that > the contents of a dot script are no longer required to be parsed as a > compound_list. The rest of the comment still makes perfect sense if you take > out the ", unlike the contents of a dot script" bit, I think. Well spotted. I agree that ", unlike the contents of a dot script" should be removed. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
On 09/01/2019 12:29, Austin Group Bug Tracker wrote: [...] > -- (0004201) geoffclare (manager) - 2019-01-09 12:29 http://austingroupbugs.net/view.php?id=953#c4201 -- This is a proposed new resolution which addresses comments made since http://austingroupbugs.net/view.php?id=953#c3113 both here and on the mailing list. There have been a lot of comments, so if I missed anything please reply on the mailing list and (if I agree) I will edit this note. [...] On page 2351 line 74901-74904 (XCU 2.5.3 Shell Variables) change:This variable, when and only when an interactive shell is invoked, shall be subjected to parameter expansion (see Section 2.6.2) by the shell and the resulting value shall be used as a pathname of a file containing shell commands to execute in the current environment.to:This variable, when and only when an interactive shell is invoked, shall be subjected to parameter expansion (see Section 2.6.2) by the shell and the resulting value shall be used as a pathname of a file. Before any interactive commands are read, the shell shall tokenize (see [xref to XCU 2.3 Token Recognition]) the contents of the file, parse the tokens as a program (see [xref to XCU 2.10 Shell Grammar]), and execute the resulting commands in the current environment. (In other words, the contents of the ENV file are not parsed as a single compound_list, unlike the contents of a dot script. This distinction matters because it influences when aliases take effect.) This last bit was part of an earlier version, but it no longer fits now that the contents of a dot script are no longer required to be parsed as a compound_list. The rest of the comment still makes perfect sense if you take out the ", unlike the contents of a dot script" bit, I think. Cheers, Harald van Dijk
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Date:Wed, 9 Jan 2019 17:35:10 +
From:Stephane Chazelas
Message-ID: <20190109173510.xn4hdeqphbffb...@chaz.gmail.com>
| I'd rather POSIX forbade applications to use "while", "until",
| "do", "select", "time", etc in alias names, or leave it
| unspecified whether aliases for those are expanded.
A lot of what you say I think, which I believe to be mostly correct,
comes down to the issue of for whom the standard is intended.
As long as it is expected that the audience is script writers, then
the doc should tell them what they can expect will work, and
what will not (or may not) so that portable applications can be
created. I think the current wording does that, as shells do actuall
allow aliases to be created for keywords (in all shells for the ones
that are also English words - or similar, like fi etc, and in some shells
even for the others (! { ...).
I don't think we are in a position to forbid anything, even if we wanted,
but I assume you mean "would result in unspecified behaviour" if
an application makes an alias for a keyword - I'd have no real problem
with that.
| but more about not requiring limitations of the original implementation
when
| they're not justified.
If that were the objective, then the audience of the standard would need
to be the shell implementors, rather than the script writers. And in that
case I assume the objective would be to allow exactly what you wanted
to forbid just above (though in your message, the two quoted occurred in
the alternate sequence) and instead allow the shell to expand aliases that
are keywords, everywhere. I'd have no problem with that either.
As long as we're not explicitly covering both audiences (with different
text for each when required) we cannot really do both however. Many
(most, perhaps even all) shells do not allow an alias to replace an
actual keyword (as distinct to a word with the same spelling used elsewhere)
so we cannot suggest that it even might be OK. Nor can we tell the
shells not to expand words that would be keywords when used elsewhere
as currently users have the ability to do that, and we cannot break
existing conforming applications.
So, rock, meet the hard place...
kre
ps: the one incorrect (but irrelevant for your points) part of your message
was the "alias 'while=until'" ... since "until" is a keyword, that's not an
alias that expands to what could be a simple command, and any use of
it (in any context) would be unspecified. However you made no us
e anywhere of that :"until", it could have just as easily been "foo", so
this is an insignificant issue.
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
One concern I have is that if I understand correctly, it
*allows* application to do:
alias 'while=until'
(though doesn't for other keywords like "{", "!")
and then *requires* implementations to expand "while" in
alias 'echo_expand=echo '
echo_expand while
and *requires* implementations *not* to expand "while" in
while true; do ...; done
Which prevents implementations from doing the kind of alias
expansion done by csh or zsh (more useful IMO, as it is then
similar to what the C preprocessor macro expansion does and was
I beleive the original intension for aliases; that can be useful
for all sorts of code instrumentation though quite limited with
out parameterized aliases).
Also, again, ksh88 (and so the POSIX sh of most commercial
Unices) does allow "select" (a keyword, as allowed by POSIX) to
be aliased.
Currently, in POSIX mode, zsh doesn't do alias expansion for
keywords, including in the echo_expand case. It's not about zsh,
I'm sure zsh will align to whatever POSIX requires for its POSIX
mode, but more about not requiring limitations of the original
implementation when they're not justified.
I'd rather POSIX forbade applications to use "while", "until",
"do", "select", "time", etc in alias names, or leave it
unspecified whether aliases for those are expanded.
--
Stephane
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Robert Elz wrote, on 09 Jan 2019: > > There are just a couple of minor points that I have with your > wording, one where I think a little more clarity is needed, and > one where your wording isn't quite correct. > > > | ... change to: > > | After a TOKEN has been delimited, > > This is where I think a little extra clarity would help, and > I'd change that to be > > After a token of type TOKEN [xref XCU 2.10.1] has > been delimited, > > just to make it clear that TOKEN is a specific type of token, > and not just a weird typographical convention (it helps readers > interpret the meaning more easily). The sentence before this (at the end of 2.3) is "Once a token is delimited, it is categorized as required by the grammar in [xref to 2.10]", so I'd like to go with: After a token has been categorized as type TOKEN (see [xref to 2.10.1]), > | If the value of the alias replacing the TOKEN ends in a that would > | be unquoted after substitution, and optionally if it ends in a > that > | would be quoted after substitution, the shell shall check the next TOKEN > in > | the input for alias substitution; > > This is where the wording is incorrect, it is not the next TOKEN, which > would imply simply skipping intermediate operators, etc, but the next > token, if and only if, it is a TOKEN, that it is considered for alias > substitution. [...] > > So I would change > shall check the next TOKEN in the input > into > shall check the next token in the input, if it is a TOKEN, Good catch - I'll make that change. I've also just noticed that 2.10.1 and 2.10.2 have TOKEN in bold everywhere, so I suppose I should do the same. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
Date:Wed, 9 Jan 2019 12:29:45 + From:Austin Group Bug Tracker Message-ID: <95df9c99cbc201dbbf9de3d53079d...@austingroupbugs.net> | please reply on the | mailing list and (if I agree) I will edit this note. I wish the part of all of this that really belongs in the resolution of issue 1055 had been left for that one rather than all included here, and then, one assumes also all included there - as that issue covers more than aliases, yet has the exact same issues. That said, I don't disagree with the proposed resolution of any of that issue in your new wording as it affects aliases, it just ought all be worded more generally so it applies to everything. There are just a couple of minor points that I have with your wording, one where I think a little more clarity is needed, and one where your wording isn't quite correct. | ... change to: | After a TOKEN has been delimited, This is where I think a little extra clarity would help, and I'd change that to be After a token of type TOKEN [xref XCU 2.10.1] has been delimited, just to make it clear that TOKEN is a specific type of token, and not just a weird typographical convention (it helps readers interpret the meaning more easily). | If the value of the alias replacing the TOKEN ends in a that would | be unquoted after substitution, and optionally if it ends in a that | would be quoted after substitution, the shell shall check the next TOKEN in | the input for alias substitution; This is where the wording is incorrect, it is not the next TOKEN, which would imply simply skipping intermediate operators, etc, but the next token, if and only if, it is a TOKEN, that it is considered for alias substitution. There is exactly one chance for this particular alias lookup, blink and you miss it - the very next token needs to be a valid alias, otherwise the whole thing stops.Only whitespace that produces no tokens can intervene (in the original input) between the TOKEN that was the alias with a value ending with a blank, and the prospective new alias TOKEN. Even a comment appearing between ends it, not because of the comment, which the lexer just drops, but because a comment only ends when a newline is seen, and that's an operator token, and so cannot be aliased. (Of course, usually then the next word would be looked up as an alias anyway, as the word in a command word position, but that was not because of the trailing blank.) So I would change shall check the next TOKEN in the input into shall check the next token in the input, if it is a TOKEN, kre
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Pending Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c3113 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-01-09 12:29 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0004201) geoffclare (manager) - 2019-01-09 12:29 http://austingroupbugs.net/view.php?id=953#c4201 -- This is a proposed new resolution which addresses comments made since http://austingroupbugs.net/view.php?id=953#c3113 both here and on the mailing list. There have been a lot of comments, so if I missed anything please reply on the mailing list and (if I agree) I will edit this note. All page and line numbers are for the 2016 and 2018 editions. On page 2348 line 74794-74805 (XCU 2.3.1 Alias Substitution), change:After a token has been delimited, but before applying the grammatical rules in Section 2.10, a resulting word that is identified to be the command name word of a simple command shall be examined to determine whether it is an unquoted, valid alias name. However, reserved words in correct grammatical context shall not be candidates for alias substitution. A valid alias name (see XBD Section 3.10) shall be one that has been defined by the alias utility and not subsequently undefined using unalias. Implementations also may provide predefined valid aliases that are in effect when the shell is invoked. To prevent infinite loops in recursive aliasing, if the shell is not currently processing an alias of the same name, the word shall be replaced by the value of the alias; otherwise, it shall not be replaced. If the value of the alias replacing the word ends in a , the shell shall check the next command word for alias substitution; this process shall continue until a word is found that is not a valid alias or an alias value does not end in a .to:After a TOKEN has been delimited, including (recursively) any token resulting from an alias substitution, the TOKEN shall be subject to alias substitution if: the TOKEN does not contain any quoting characters, the TOKEN is a valid alias name (see XBD Section 3.10), an alias with that name is in effect, the TOKEN did not result from an alias substitition of the same alias name at any earlier recursion level, the TOKEN is not recognized as a reserved word (see [xref to 2.4 Reserved Words] and the examples in [xref to XRAT C.2.3.1]), and the TOKEN will be parsed as the command name word of a simple command when the grammatical rules in Section 2.10 are applied. An implementation may defer the effect of a change to an alias but the change shall take effect no later than the completion of the currently executing complete_command (see [xref to XCU 2.10 Shell Grammar]). Changes to aliases shall not take effect out of order. Implementations may provide predefined aliases that are in effect when the shell is invoked. If the value of the alias is not a simple command (see [xref to 2.9.1]), or contains any of: a comment a variable assignment a redirection unbalanced single-quotes or double-quotes (except within a command substitution), the behavior is unspecified. When a TOKEN is subject to alias substitution, the value of the alias shall be processed to form tokens (see [xref to 2.3]) and the resulting tokens shall replace the TOKEN. If the value of the alias
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Approved Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c3113 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2017-01-18 15:25 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0003553) ajosey (manager) - 2017-01-18 15:25 http://austingroupbugs.net/view.php?id=953#c3553 -- Interpretation Approved: 18 Jan 2017 Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See http://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152
