Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Harald van Dijk
On 22/06/2019 13:40, Stephane Chazelas wrote: 2019-06-22 09:07:40 +0100, Harald van Dijk: [...] In theory, pathname expansion is supposed to be done for every word, no matter which characters it contains. Even in something as simple as [...] That's your way to look at it. That's the way

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Stephane Chazelas
2019-06-22 09:07:40 +0100, Harald van Dijk: [...] > > > In theory, pathname expansion is supposed to be done for every word, no > > > matter which characters it contains. Even in something as simple as [...] > > That's your way to look at it. > > That's the way it's specified in POSIX. Note that

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Shware Systems
The backslash may or may not be removed per 2.13.1, since it is not followed by a shell or pattern special char. While the first paragraph there is explicit it is to be removed for the usual cases, whatever the following char is, the last paragraph has the wording only the specials are

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Shware Systems
Sorry, I inverted the conditional; it calls list_quote_escapes(), to the same effect of preserving  backslashes, as '\' is quoted there and NUL strings. The source values is how I've stated, effectively, so your assertion no shells treat it that way is bogus. That the routines that do the

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Stephane Chazelas
2019-06-21 23:58:32 +0100, Harald van Dijk: [...] > In theory, pathname expansion is supposed to be done for every word, no > matter which characters it contains. Even in something as simple as > > echo hello > > both words undergo pathname expansion. The first word is supposed to be > matched

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Stephane Chazelas
2019-06-22 07:04:37 +0700, Robert Elz: [...] > | You just shot yourself in both feet there :-) > | > | 1- read without -r also handles \, > > So, rather than droning on about that error of mine, simply > assume I used read -r instead. Because you have realised \ was way too overloaded? >

[1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1234 == Reported By:stephane Assigned To:

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Harald van Dijk
On 22/06/2019 07:51, Stephane Chazelas wrote: 2019-06-21 23:58:32 +0100, Harald van Dijk: [...] In theory, pathname expansion is supposed to be done for every word, no matter which characters it contains. Even in something as simple as echo hello both words undergo pathname expansion. The

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-22 Thread Harald van Dijk
On 22/06/2019 01:46, Robert Elz wrote: Date:Fri, 21 Jun 2019 23:58:32 +0100 From:Harald van Dijk Message-ID: <49108c83-bd68-a329-25c5-118b0f911...@gigawatt.nl> | Obviously, this means that pathname expansion produces "echo", | regardless of the contents