unbalanced parenthesis not recognized
Hi folks,
I am not sure, but shouldn't bash 5.1.4 complain about
: ${SSLDIR}:="${JM_WORK}/ssl"}
at least due to unbalanced parenthesis? The correct version
would be
: ${SSLDIR:="${JM_WORK}/ssl"}
Regards
Harri
Re: unbalanced parenthesis not recognized
On 2021-11-18 17:52:29, Robert Elz wrote:
Date:Thu, 18 Nov 2021 10:34:40 +0100
From:Harald Dunkel
Message-ID:
| at least due to unbalanced parenthesis?
Greg's reply was correct, but he didn't explicitly address that point.
In sh, characters like { } [ ] (but not ( and )) are just characters.
In some scenarios they're required to be paired for things to work, but
you can always simply use one (unquoted) anywhere there's a need. They
don't have to balance in any way.
"Some scenarios" is the point here. The parenthesis have to balance as
soon as it comes to shell parameter expansion, which is (or should have
been) the case here. Something like
: ${SSLDIR:="${JM_WORK}/ssl"
doesn't work, either.
You have to admit that this was a mean pitfall.
Thanx for your reply
Harri
Re: unbalanced parenthesis not recognized
Hi Chet,
On 2021-11-19 16:27:34, Chet Ramey wrote:
On 11/19/21 2:02 AM, Harald Dunkel wrote:
"Some scenarios" is the point here. The parenthesis have to balance as
soon as it comes to shell parameter expansion, which is (or should have
been) the case here.
OK. Let's look at the original example:
: ${SSLDIR}:="${JM_WORK}/ssl"}
Where do you think parameter expansion applies here, as far as the final
`}' in the string, and why should it "have been the case?" There are no
incomplete parameter expansions in this command; why should the shell
assume that a close brace appearing by itself should be matched somewhere?
I'm not saying that this shell construct is reasonable. The "should have
been" refers to the construct not working as I had intended, due to the
typo. Please excuse my bad English.
Surely I can just speak for myself, but to me it appears obvious that
there is something weird and that there is one closing bracket too much
in this line. I understand that bash doesn't produce an error about the
entire line, because it is valid bash code.
Regards
Harri
5.1 regression?
Hi folks,
a colleague pointed me to a changed behavior of bash 5.1.4 in Debian 11.
Would you mind to take a look at this code?
#! /bin/bash
# set -x
insert()
{
local data="$1"
local lineNumber="$2"
head -n "$lineNumber"
echo ' '
cat <<< "$data"
echo ' '
cat
}
text="this is line one
this is line two
this is line three
this is line four
this is line five
this is line six
this is line seven"
output="$( insert "Hello" 3 <<< "${text}" )"
echo "$output"
On bash 5.0.3 (Debian 10) it shows
this is line one
this is line two
this is line three
Hello
this is line four
this is line five
this is line six
this is line seven
On bash 5.1.4 (Debian 11) and 5.1.6 (openBSD 7.1) I get
this is line one
this is line two
this is line three
Hello
Lines 4 to 7 are lost. How comes? Is this a problem of
bash at all?
Every insightful comment is highly appreciated
Harri
weird behavior of set -e
Hi folks, A colleague pointed me to this problem: If I run ( set -e; ( false; echo x ) ) in bash 4.1.5, then there is no screen output, as expected. If I change this to ( set -e; ( false; echo x ) || echo y ) then I get "x" instead of "y". How comes? Any helpful comment would be highly appreciated. Harri
improving '{...}' in bash?
Hi folks,
This feels weird:
% echo x{1,2}x
x1x x2x
% echo x{1}x
x{1}x
% echo x{1..3,5}x
x1..3x x5x
I would have expected "x1x" and "x1x x2x x3x x5x".
Regards
Harri
Re: improving '{...}' in bash?
On 2024-07-23 11:10:23, Martin D Kealey wrote:
On Tue, 23 Jul 2024, 15:50 Harald Dunkel, wrote:
Hi folks,
This feels weird:
Did you read the manual before trying any of these?
Of course not. I just wanted to say, this {...} construct is rather
unintuitive to use. I know how to write this, but when I try to use
it, it feels I am breaking my fingers to enter the code.
No offense
Regards
Harri
