On Thu, Mar 29, 2018 at 07:29:12AM +0200, Harald van Dijk wrote:
>
> You're right that what other shells implement doesn't allow any possibility
> of unescaped backslashes in the shell. But if what they do is what's
Well the only shell that does allow it is bash and its behaviour
is inconsistent a
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 behaviour
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 beh
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 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 explana
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 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 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?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.o
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 POSI
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
Hom
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 behav
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 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 change
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 ba
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
> become
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 not
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 al
On 3/27/18 10:55 AM, Herbert Xu wrote:
So going back to dash yes I think we should adopt the bash behaviour
for pathname expansion and keep the existing case semantics.
This patch does exactly that. Note that this patch does not work
unless you have already applied
https://patchwork.ke
On 3/27/18 11:32 PM, Jilles Tjoelker wrote:
I don't think it is clear at all. Note the final paragraph of 2.13.1:
] When pattern matching is used where shell quote removal is not
] performed [...]
This implies that special characters cannot be escaped using a backslash
in a context where shell
On Tue, Mar 27, 2018 at 08:19:19PM +0800, Herbert Xu wrote:
> On Tue, Mar 27, 2018 at 01:07:21PM +0200, Harald van Dijk wrote:
> > If POSIX specifies a result, and a shell applies an optimisation that causes
> > a different result to be produced, doesn't that inherently disallow that
> > optimisat
On 27/03/2018 20:24, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 08:01:10PM +0200, Harald van Dijk wrote:
Right. I guess we could change it so that CTLESC is preserved
to distinguish between the backslashes from parameter expansion
vs. backslashes from open input.
Thinking about it some more,
On Tue, Mar 27, 2018 at 08:01:10PM +0200, Harald van Dijk wrote:
>
> >Right. I guess we could change it so that CTLESC is preserved
> >to distinguish between the backslashes from parameter expansion
> >vs. backslashes from open input.
>
> Thinking about it some more, see below.
Actually let's no
On 27/03/2018 19:02, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 06:48:45PM +0200, Harald van Dijk wrote:
Backslashes coming from parameters, sure, but backslashes introduced by
preglob(), I'm not so sure.
Right. I guess we could change it so that CTLESC is preserved
to distinguish between the
On Tue, Mar 27, 2018 at 06:48:45PM +0200, Harald van Dijk wrote:
>
> Backslashes coming from parameters, sure, but backslashes introduced by
> preglob(), I'm not so sure.
Right. I guess we could change it so that CTLESC is preserved
to distinguish between the backslashes from parameter expansion
On 27/03/2018 18:04, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 05:54:53PM +0200, Harald van Dijk wrote:
I was thinking about not making backslashes set metaflag in expmeta(): when
the pathname component doesn't include *, ?, or [, but does include
backslashes, then the if (metaflag == 0) block
On Tue, Mar 27, 2018 at 05:54:53PM +0200, Harald van Dijk wrote:
>
> I was thinking about not making backslashes set metaflag in expmeta(): when
> the pathname component doesn't include *, ?, or [, but does include
> backslashes, then the if (metaflag == 0) block could handle that as long as
> it p
On 27/03/2018 17:14, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 02:57:12PM +0200, Harald van Dijk wrote:
That's a good point and wouldn't have too much of an impact on performance
of existing scripts. BTW, that means both expandmeta()'s metachars variable,
and expmeta()'s
if (metaflag == 0 |
On Tue, Mar 27, 2018 at 02:57:12PM +0200, Harald van Dijk wrote:
>
> That's a good point and wouldn't have too much of an impact on performance
> of existing scripts. BTW, that means both expandmeta()'s metachars variable,
> and expmeta()'s
>
> if (metaflag == 0 || lstat64(expdir, &statb) >= 0)
On 27/03/2018 14:19, Herbert Xu wrote:
Nowhere does it say that backslashes that come from the result of
parameter expansion is always literal.
So it's clear that any shell that treats the backslash as a literal
backslash is already broken.
By the literal POSIX wording, yes, but the fact remai
On Tue, Mar 27, 2018 at 01:07:21PM +0200, Harald van Dijk wrote:
>
> If POSIX specifies a result, and a shell applies an optimisation that causes
> a different result to be produced, doesn't that inherently disallow that
> optimisation? There may be some confusion and/or disagreement over what
> ex
On 27/03/2018 11:44, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 11:16:29AM +0200, Harald van Dijk wrote:
If you say that quote removal takes place on the original token (meaning
before parameter expansion), and if parameter expansion takes place before
pathname expansion, then there's nothing le
On Tue, Mar 27, 2018 at 11:16:29AM +0200, Harald van Dijk wrote:
>
> If you say that quote removal takes place on the original token (meaning
> before parameter expansion), and if parameter expansion takes place before
> pathname expansion, then there's nothing left to allow \* to behave
> differen
On 27/03/2018 10:55, Herbert Xu wrote:
Here is a better example:
a="/*/\nullx" b="/*/\null"; printf "%s\n" $a $b
dash currently prints
/*/\nullx
/*/\null
bash prints
/*/\nullx
/dev/null
You may argue the bash behaviour is inconsistent but it actually
On Mon, Mar 26, 2018 at 07:25:20PM +0200, Martijn Dekker wrote:
> Op 26-03-18 om 17:38 schreef Harald van Dijk:
> > And not by dash 0.5.4. Like I wrote, dash 0.5.5 had some bugs that were
> > fixed in 0.5.6, which mostly restored the behaviour to match <0.5.5.
>
> Ah, sorry. dash 0.5.4 and earlier
35 matches
Mail list logo