Re: unbalanced parenthesis not recognized

[Harald Dunkel]

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

Re: unbalanced parenthesis not recognized

[Greg Wooledge]

On Mon, Nov 22, 2021 at 09:03:39AM +0100, Harald Dunkel wrote:
> > : ${SSLDIR}:="${JM_WORK}/ssl"}

> 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.

Sure, a human (programmer) looking at this command might be able to
spot the error and guess what the intended command was.

Bash itself can't.  As you said, it's a valid command, so bash has no
reason to complain about it.

Maybe what you want is a "linter" (e.g. shellcheck).  Using the online
version  gives me this result:

---
Line 1:
: ${SSLDIR}:="${JM_WORK}/ssl"}
^-- SC2148 (error): Tips depend on target shell and yours is unknown. Add a 
shebang or a 'shell' directive.
  ^-- SC2086 (info): Double quote to prevent globbing and word splitting.
 ^-- SC1083 (warning): This } is literal. Check 
expression (missing ;/\n?) or quote it.

Did you mean: (apply this, apply all SC2086)
: "${SSLDIR}":="${JM_WORK}/ssl"}
---

That's not too bad.  Better than I expected, actually.  The suggested
correction at the end isn't helpful, but the SC1083 warning in the
middle is.

Re: Crash when using ulimit -n

[Chet Ramey]

On 11/21/21 8:34 PM, balasr wrote:

> Bash Version: 5.1
> Patch Level: 8
> Release Status: release
> 
> Description:
>     Calling ulimit -n 1024 results in the message "Warning: Program 
> '/bin/bash' crashed." and bash locks up.
> 
> Repeat-By:
>     1. Open bash
>     2. Enter `ulimit -n 1024'

Sorry, I can't reproduce this.


-- 
``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: Crash when using ulimit -n

[balasr]

Thanks for trying

It seems hibernation was the problem. I did a fresh reboot and the problem went 
 away.

On 22/11/2021 15:05, Chet Ramey wrote:
> On 11/21/21 8:34 PM, balasr wrote:
>
>> Bash Version: 5.1
>> Patch Level: 8
>> Release Status: release
>>
>> Description:
>>     Calling ulimit -n 1024 results in the message "Warning: Program 
>> '/bin/bash' crashed." and bash locks up.
>>
>> Repeat-By:
>>     1. Open bash
>>     2. Enter `ulimit -n 1024'
> Sorry, I can't reproduce this.
>
>