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?
>
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 f
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 of
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 actua
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
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 it's
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 treated
2019-06-22 13:57:44 +0100, Harald van Dijk:
[...]
> > But in bash5's
> >
> > files='/a/\b/??/x/*'
> > ls -d $files
> >
> > That \ becomes a globbing operator, so we get the same list of
> > files as in a literal /a/[b]/??/x/*, not a literal /a/\b/??/x/*
>
> That doesn't sound right. The backslas
On 22/06/2019 15:34, Shware Systems wrote:
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
On 6/22/19 8:22 AM, Shware Systems wrote:
> Sorry, I inverted the conditional; it calls list_quote_escapes(), to the
> same effect of preserving backslashes, as '\' is quoted there and NUL
> strings.
That's not what quote_escapes() (which is what list_quote_escapes()
eventually calls) does. But
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
11 matches
Mail list logo
