Hi,
Below is the patch for the new 'errfail' option.
Please note that this is MINIMAL implementation. It will cover the cases
below. Possible to think about this as replacing every ';' (or new line
line that terminate statements) with '&&' - forcing execution to break.
.
Patch is minimal (less th
On Tue, Jul 5, 2022, at 7:01 AM, Yair Lenga wrote:
> Below is the patch for the new 'errfail' option.
This doesn't apply cleanly to "devel". I assume you made it against
"master", which isn't the development branch -- "devel" is. Sorry
I forgot to mention that earlier.
--
vq
On Fri, Jul 1, 2022, at 4:07 AM, Vangelis Natsios wrote:
> When creating an alias containing a path ending with a non-latin (e.g.
> greek) directory name, a space character is appended to the end of the
> path, causing the alias to fail.
Not quite: Neither "paths" nor "non-Latin" characters are ne
From: hanskobe...@gmail.com
To: bug-bash@gnu.org
Subject: [bug] Bind + readline state corruption
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux 4602
Hi Martin,
Thanks for taking the time to review my proposal.
Wanted to highlight that the implementation was less than 3 hour (fun) job - no
trouble at all. Credit should go to current bash dev team (I am being told it’s
a team of 1) - for keeping organized, well written, documented code !
I’m
On Tue, Jul 5, 2022, at 5:18 PM, Yair Lenga wrote:
> I’m not in front of my desktop, so I can not verify behavior, but here
> is my expectation - let me know if it make sense, in the context of the
> project goal - every unhandled failed statement should unwind execution
> up, until explicitly h
Sent from my iPad
> On Jul 6, 2022, at 1:07 AM, Lawrence Velázquez wrote:
>
> On Tue, Jul 5, 2022, at 5:18 PM, Yair Lenga wrote:
>> I’m not in front of my desktop, so I can not verify behavior, but here
>> is my expectation - let me know if it make sense, in the context of the
>> project g
On Tue, Jul 5, 2022, at 6:34 PM, Yair Lenga wrote:
> I probably did not described the intended behavior clearly. I believe
> both cases should behave identical under errfail. The loop will ‘break’
> on the first iteration (false when word = a). Same for the all looping
> commands. I believe this
My opinion is that we should be looking at the expected behavior - for a
developer that want to implement ”strong” error handling: any error will break
execution until explicitly handled. In the same spirit as the ‘try … catch’
that from JavaScript, python, groovy, etc.
So: assuming f1 does no
On Tue, Jul 5, 2022, at 8:09 PM, Yair Lenga wrote:
> My opinion is that we should be looking at the expected behavior - for
> a developer that want to implement ”strong” error handling: any error
> will break execution until explicitly handled. In the same spirit as
> the ‘try … catch’ that fro
On Wed, 6 Jul 2022 at 08:34, Yair Lenga wrote:
> in general, for complex scripts, I prefer to move the ‘main’ logic into a
> function (‘main’, ‘run’,…). This make it possible to keep clean name space.
> Otherwise, all the main variables are becoming global: see below for ‘x’.
> With many variable
Hi.
I agree that the bash local variables are less than ideal (dynamic scope vs
local scope). However, we got to use what we have. In that context, using
'main' has lot of value - documentation, declarative, etc.
In my projects, we use "named" main to create reusable code (e.g. date
calculator ca
12 matches
Mail list logo
