The following issue has a resolution that has been APPLIED.
==
https://austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned
Hey folks.
A while ago we had this discussion about pattern matching notation and
characters vs. bytes.
Back then, Harald von Dijk did some investigation on whether the
standard could be changed to allow for bytes (and not just characters)
without breaking all kinds of shells.
IIRC, when he
The following issue has been RESOLVED.
==
https://austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
On 5/18/22 9:46 PM, Christoph Anton Mitterer via austin-group-l at The Open
Group wrote:
The above, I'm not quite sure what these tell/prove...
I assume the ones with '?': that for all except bash/fnmatch '?'
matches both, valid characters and a single byte that is no character.
And the
On 20/05/2022 01:11, Christoph Anton Mitterer wrote:
On Thu, 2022-05-19 at 09:05 +0100, Harald van Dijk wrote:
The above, AFAIU, mean that any shell/fnmatch matches a valid
multibyte
character... but also a byte that is not a character in the locale.
Correct, though as I wrote later on, the
On Thu, 2022-05-19 at 09:05 +0100, Harald van Dijk wrote:
> >
> > The above, AFAIU, mean that any shell/fnmatch matches a valid
> > multibyte
> > character... but also a byte that is not a character in the locale.
>
> Correct, though as I wrote later on, the way they go about it is
> different.
On 15/05/2022 16:14, Harald van Dijk via austin-group-l at The Open
Group wrote:
On 19/04/2022 01:52, Harald van Dijk via austin-group-l at The Open
Group wrote:
On 15/04/2022 04:57, Christoph Anton Mitterer wrote:
On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l
at The
On 19/05/2022 02:46, Christoph Anton Mitterer wrote:
On Sun, 2022-05-15 at 16:14 +0100, Harald van Dijk wrote:
Please see the tests and results here.
So dash/ash/mksh/posh/pdksh,... and every other shell that doesn't
handle locales at all (and thus works in the C locale)... is anyway
always
On Sun, 2022-05-15 at 16:14 +0100, Harald van Dijk wrote:
> Please see the tests and results here.
So dash/ash/mksh/posh/pdksh,... and every other shell that doesn't
handle locales at all (and thus works in the C locale)... is anyway
always right (except for bugs), since any (non-NUL) byte is
On 19/04/2022 01:52, Harald van Dijk via austin-group-l at The Open
Group wrote:
On 15/04/2022 04:57, Christoph Anton Mitterer wrote:
On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l
at The Open Group wrote:
If there is interest in getting this standardised, I can spend
[accidentally replied privately, re-sending to list]
On 22/04/2022 10:54, Geoff Clare via austin-group-l at The Open Group wrote:
Harald van Dijk wrote, on 15 Apr 2022:
For the most part(*), those shells that support locales appear to already be
in agreement that single bytes that do not form
Harald van Dijk wrote, on 15 Apr 2022:
>
> For the most part(*), those shells that support locales appear to already be
> in agreement that single bytes that do not form a valid multi-byte character
> are interpreted as single characters that can be matched with *, with ?, and
> with those single
Robert Elz wrote, on 15 Apr 2022:
>
> | That is how things are at present. The suggested changes just make it
> | explicit.
>
> Yes, I know, but that's what I am suggesting that we not do in this one case.
>
> | Do you have an alternative proposal?
>
> Only to the extent of "do nothing".
Hey.
On Tue, 2022-04-19 at 01:52 +0100, Harald van Dijk wrote:
> Even I did not to apply this to pattern matching. The
> lexical locale, the locale used for lexing, is only used for lexing,
> i.e. for recognising tokens, not to how those tokens are then
> interpreted later on. If locale comes
On 15/04/2022 04:57, Christoph Anton Mitterer wrote:
On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l
at The Open Group wrote:
Hmm, I would.
I like that :-D This would have been the preferred alternative I've
asked for to look at, in the ticket.
Shells
are not in
On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l
at The Open Group wrote:
> Hmm, I would.
I like that :-D This would have been the preferred alternative I've
asked for to look at, in the ticket.
> Shells
> are not in agreement on whether such single bytes can be matched
On Tue, 2022-04-12 at 18:54 +0700, Robert Elz via austin-group-l at The
Open Group wrote:
> The point was that, at least as I read the proposed text, you're
> defining
> things like '*' to only work (reliably as specified) when the locale
> is
> POSIX (aka C). In the user's locale, who knows
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
Date:Thu, 14 Apr 2022 09:42:37 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20220414084237.GA15370@localhost>
| That is how things are at present. The suggested changes just make it
| explicit.
Yes, I know, but that's what I am
Robert Elz wrote, on 12 Apr 2022:
>
> | 1. The vast majority of apps will never need to do that because they know
> | (or can assume) that the pathnames they handle either always use the
> | portable filename character set or use the user's locale.
>
> The latter, perhaps, the former,
Date:Tue, 12 Apr 2022 08:51:51 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID: <1541e949d4c9cd28467acf6033bfd...@austingroupbugs.net>
That is, Geoff Clare:
| 1. The vast majority of apps will never need to do that because
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
The following issue has been set as RELATED TO issue 0001561.
==
https://austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
The following issue has been SUBMITTED.
==
https://www.austingroupbugs.net/view.php?id=1564
==
Reported By:calestyo
Assigned To:
30 matches
Mail list logo
