On Tue, Mar 27, 2018 at 08:38:01PM +0200, Harald van Dijk wrote:
>
> >My inclination is to just drop the /d\ev issue and use the bash
> >behaviour until such a time that bash changes or POSIX changes.
>
> What would need to change in POSIX to convince you to change dash to match
> what you were
On 28/03/2018 08:18, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 08:38:01PM +0200, Harald van Dijk wrote:
My inclination is to just drop the /d\ev issue and use the bash
behaviour until such a time that bash changes or POSIX changes.
What would need to change in POSIX to convince you to
On 28/03/2018 09:31, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 08:52:57AM +0200, Harald van Dijk wrote:
I seriously cannot understand the logic of pushing a break from traditional
ash behaviour and from all shells apart from bash, giving POSIX as a reason
for doing it, and then giving the
On Wed, Mar 28, 2018 at 08:52:57AM +0200, Harald van Dijk wrote:
>
> I seriously cannot understand the logic of pushing a break from traditional
> ash behaviour and from all shells apart from bash, giving POSIX as a reason
> for doing it, and then giving the behaviour of all those other shells as
On Tue, Mar 27, 2018 at 11:32:36PM +0200, Jilles Tjoelker wrote:
>
> This implies that special characters cannot be escaped using a backslash
> in a context where shell quote removal is performed. Instead, special
My argument would be that in the context of parameter expansion
quote removal is
On 28/03/2018 08:23, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 12:19:17AM +0200, Harald van Dijk wrote:
This introduces a buffer overread. When expmeta() sees a backslash, it
assumes it can just skip the next character, assuming the next character is
not a forward slash. By treating expanded
On Wed, Mar 28, 2018 at 12:19:17AM +0200, Harald van Dijk wrote:
>
> This introduces a buffer overread. When expmeta() sees a backslash, it
> assumes it can just skip the next character, assuming the next character is
> not a forward slash. By treating expanded backslashes as unquoted, it
>
On Wed, Mar 28, 2018 at 12:03:24PM +0200, Harald van Dijk wrote:
>
> When expanded backslashes are no longer treated as quoted, this would call
> expmeta() with the pattern *\, that is with a single unquoted trailing
> backslash, so:
>
> expand.c:1333
>
> if (*p == '\\')
On Wed, Mar 28, 2018 at 12:53:31PM +0200, Harald van Dijk wrote:
>
> I don't think this allows dash's behaviour of taking the backslash as a
> literal, since that still allows a match to succeed. bash lets such a
> pattern never match. In other shells, there is no way to get into this
> situation,
On Wed, Mar 28, 2018 at 09:38:04AM +0200, Harald van Dijk wrote:
>
> Also, it's just as logical to restore the case pattern matching to its
> traditional behaviour to align it with pathname expansion.
No I think that makes no sense and clearly contradicts POSIX.
Cheers,
--
Email: Herbert Xu
On 28/03/2018 11:52, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 08:44:28AM +0200, Harald van Dijk wrote:
Test case:
$v='*\'
set -- $v
I don't see how this would cause an overrun, can you please explain
it for me?
Line numbers are from 0.5.9.1.
When expanded backslashes are no longer
On 28/03/2018 12:37, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 12:03:24PM +0200, Harald van Dijk wrote:
When expanded backslashes are no longer treated as quoted, this would call
expmeta() with the pattern *\, that is with a single unquoted trailing
backslash, so:
[...]
Thanks for the
On 28/03/2018 13:00, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 12:53:31PM +0200, Harald van Dijk wrote:
[un-snip]
If a pattern ends with an unescaped , it is unspecified whether the pattern does not match anything or the pattern is treated as invalid.
I don't think this allows dash's
On 3/29/18 6:42 AM, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 03:06:32PM +0200, Harald van Dijk wrote:
Since bash itself is inconsistent, and POSIX unclear,
What exactly is unclear about the sentence of POSIX that I quoted? Is there
a legitimate interpretation of "It is unspecified whether A
On Wed, Mar 28, 2018 at 03:06:32PM +0200, Harald van Dijk wrote:
>
> >Since bash itself is inconsistent, and POSIX unclear,
> What exactly is unclear about the sentence of POSIX that I quoted? Is there
> a legitimate interpretation of "It is unspecified whether A or B" that
> allows other
On 28/03/2018 10:16, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 09:38:04AM +0200, Harald van Dijk wrote:
Also, it's just as logical to restore the case pattern matching to its
traditional behaviour to align it with pathname expansion.
No I think that makes no sense and clearly contradicts
16 matches
Mail list logo
