The following issue has been set as RELATED TO issue 0001645.
==
https://www.austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
The following issue has been set as RELATED TO issue 0001342.
==
https://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
The following issue has a resolution that has been APPLIED.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
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
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
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,
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
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".
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
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
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
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*
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:
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
>
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,
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
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
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
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
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
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
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
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
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
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
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
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
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
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*
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
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
37 matches
Mail list logo