Re: man bash does not list 'in' as a builtin command
On Tue, 2019-11-26 at 18:26 +0700, Robert Elz wrote: > With that in mind the message in question isn't really confusing at all. I agree. With one little exception. Bash has two levels of error checking, that can generate the message. 1) Command line parsing and interpreting. 2) Bash script parsing and interpreting. I looked first into the latter, my new code is always thought to have the error, before I suspect open source software quality. Then, I started suspecting the former, the CLI, then confirmed it. And it could only happen for the one word, 'in', and no other. A very special case indeed. No worthy of time to edit and debug and QA software. @Robert: Down Under is a very fine place to live, indeed. @Chris: I like the 'type' command. Thanks. BTW, I have named thousands of custom scripts, one letter, 2, 3, or 2 to 8 words, etc. Never had a problem with figuring out an error message, until this one. 'in' was the initials of the longer two words I wished to name it, but for keystroke counting purposes I wanted just two letters. I was going to use the command frequently for some days, 20-50 times a day. A testing script. I settled on 'inn' being next fastest to type. Peter
Re: Backslash missing in brace expansion
On 12/5/19 8:53 PM, Martin Schulte wrote:
>> It's an unquoted backslash, which is removed by quote removal when the
>> words are expanded. Look at the extra space between `[' and `]'; that's
>> the null argument resulting from the unquoted backslash.
>
> Yes - sure. But then I'm wondering why the unquoted backtick doesn't
> start command substitution:
>
> $ echo {Z..a}
> Z [ ] ^ _ ` a
> $ echo Z [ \ ] ^ _ ` a
>>
It's a reasonable question. The short answer is that brace expansion
takes place after parsing and results in multiple words.
Look at it this way. When the parser is reading a simple command, it
applies certain rules (matching quotes, metacharacter recognition, etc.)
and produces a list of words, which the shell expands and executes. Brace
expansion is similar in that it takes a single word and produces a list
of words which are then run through word expansion, but it does not apply
the same rules as the parser (or any rules, really).
What you end up with is a list of words: [, \, ], ^, _, `. a .
Each of those words is expanded as usual. When you get to the word that
consists of the single character "`", the expansion code checks whether
or not it's a valid command substitution, and, finding it's a single "`"
instead, leaves it unchanged.
The single backslash, as I explained earlier, is removed, resulting in a
null word after expansion.
This is an example of how you can use brace expansion to produce words
the parser would never have passed as valid.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Backslash missing in brace expansion
On 12/6/19 9:23 AM, Robert Elz wrote: > I'm not sure I accept the explanation for the \ missing though, quoting is > also a parser activity (though some of it also happens in pattern matching). > But normally, backslashes (or any other form of quoting) that result from > expansions are simply characters. Quote removal is only supposed to remove > quotes that were present on the original command line. Quote removal is a word expansion, and removes quotes that were present in the original word passed to word expansion. Brace expansion is performed before any of the POSIX word expansions, and is logically a separate step. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Backslash missing in brace expansion
Date:Fri, 6 Dec 2019 05:53:04 +0100 From:Martin Schulte Message-ID: <20191206055304.076d6115afa3a4f2a6a21...@schrader-schulte.de> | Yes - sure. But then I'm wondering why the unquoted backtick doesn't | start command substitution: Too late. Syntax elements must be recognised by the parser, they cannot (ever) appear from an expansion (if that's needed an "eval" is required). I'm not sure I accept the explanation for the \ missing though, quoting is also a parser activity (though some of it also happens in pattern matching). But normally, backslashes (or any other form of quoting) that result from expansions are simply characters. Quote removal is only supposed to remove quotes that were present on the original command line. kre
Re: Backslash missing in brace expansion
On 12/5/19 10:53 PM, Martin Schulte wrote:
(2019-11-11) x86_64 GNU/Linux $ echo ${BASH_VERSINFO[@]}
4 4 12 1 release x86_64-pc-linux-gnu
$ set -x
$ echo {Z..a}
+ echo Z '[' '' ']' '^' _ '`' a
Z [ ] ^ _ ` a
It looks as if the backslash (between [ and ] in ASCII code) is
missing in brace expansion. The same behaviour seems to be found in
bash 5.0.
It's an unquoted backslash, which is removed by quote removal when the
words are expanded. Look at the extra space between `[' and `]'; that's
the null argument resulting from the unquoted backslash.
Yes - sure. But then I'm wondering why the unquoted backtick doesn't
start command substitution:
It may be version dependent:
$ echo ${BASH_VERSINFO[@]}
5 0 7 1 release x86_64-redhat-linux-gnu
$ echo b{Z..a}d
bash: bad substitution: no closing "`" in `d
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: Backslash missing in brace expansion
On 12/6/19 11:27 AM, Chet Ramey wrote:
On 12/6/19 9:23 AM, Robert Elz wrote:
I'm not sure I accept the explanation for the \ missing though, quoting is
also a parser activity (though some of it also happens in pattern matching).
But normally, backslashes (or any other form of quoting) that result from
expansions are simply characters. Quote removal is only supposed to remove
quotes that were present on the original command line.
Quote removal is a word expansion, and removes quotes that were present in
the original word passed to word expansion. Brace expansion is performed
before any of the POSIX word expansions, and is logically a separate step.
Then that argues that {Z..a} should produce \\ and \', rather than bare
characters, so that the subsequent quote removal gets back to the
intended character.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: Backslash missing in brace expansion
On 6.12. 21:36, Eric Blake wrote:
On 12/5/19 10:53 PM, Martin Schulte wrote:
(2019-11-11) x86_64 GNU/Linux $ echo ${BASH_VERSINFO[@]}
4 4 12 1 release x86_64-pc-linux-gnu
$ set -x
$ echo {Z..a}
+ echo Z '[' '' ']' '^' _ '`' a
Z [ ] ^ _ ` a
It looks as if the backslash (between [ and ] in ASCII code) is
missing in brace expansion. The same behaviour seems to be found in
bash 5.0.
It's an unquoted backslash, which is removed by quote removal when the
words are expanded. Look at the extra space between `[' and `]'; that's
the null argument resulting from the unquoted backslash.
Yes - sure. But then I'm wondering why the unquoted backtick doesn't
start command substitution:
It may be version dependent:
$ echo ${BASH_VERSINFO[@]}
5 0 7 1 release x86_64-redhat-linux-gnu
$ echo b{Z..a}d
bash: bad substitution: no closing "`" in `d
I get that with 4.4 and 'echo b{Z..a}d' too, the trailing letter seems
to trigger it.
Which also doesn't seem to make sense, but one might argue that {Z..a}
doesn't make much sense in the first place. Seriously, is there an
actual use case for such a range?
It doesn't seem to even generalize from that if you go beyond letters,
so you can't do stuff like generating all the printable ASCII characters
with it in Bash.
--
Ilkka Virta / itvi...@iki.fi
Re: Backslash missing in brace expansion
On 12/6/19 12:29 PM, Ilkka Virta wrote:
>>> Yes - sure. But then I'm wondering why the unquoted backtick doesn't
>>> start command substitution:
>>
>> It may be version dependent:
>>
>> $ echo ${BASH_VERSINFO[@]}
>> 5 0 7 1 release x86_64-redhat-linux-gnu
>>
>> $ echo b{Z..a}d
>> bash: bad substitution: no closing "`" in `d
>
> I get that with 4.4 and 'echo b{Z..a}d' too, the trailing letter seems to
> trigger it.
That's an implementation decision bash makes. What you get from the above
brace expansion is the list
bZa, b[a, b\a, b]a, b^a, b_a, b`a, baa
As I said in the previous message, the expansion code leaves a single "`"
unchanged (it always has), but throws an error when it's an unterminated
command substitution that's more than a bare backquote.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
