Linda Walsh writes:
> If I am using a var as an index in a for loop
> as in:
>
> for((i=0; i<10; ++i)); do : done
>
> or 2) as an iterator as in
>
> for i in {1..10}; do : done
>
> **and** such usage is in a function,
>
> the default is to promote 'i' to 'global' status,
This behaviour is sh
On Wed, Oct 07, 2015 at 10:44:20PM -0500, Eduardo A. Bustamante López wrote:
> > Repeat-By:
> > shopt -u extglob
> > isnum () ( shopt -s extglob; case "$1" in [1-9]*([0-9])) return 0 ;;
> > *) return 1 ;; esac; )
>
> Remember that bash parses and interprets the script line-by-line. If yo
On 10/6/15 8:27 AM, bash...@jonkmans.nl wrote:
> Bash Version: 4.3
> Patch Level: 30
> Release Status: release
>
> Description:
> The shell gives a syntax error when defining a function that uses the
> extended pattern matching operators.
This is fundamental to how the shell works. The s
On 10/7/15 7:38 PM, Linda Walsh wrote:
> I was thinking ... lets say we had 1 or 2 abbreviation
> keywords, at least 1 being "int=declare -i",
> and ease-of-use "my=declare"
>
> that could then allow the "declare" of the 'for' iterator
> as local, in-line.
>
> i.e. instead of predeclaring them w
Chet Ramey wrote:
These change the syntax of the shell in incompatible ways.
---
I think I had the feeling of ensuring compatibility as being important
and changing things in incompatible ways . "That's not easily changed w/o potential
chaos..."
The arithetic `for' command takes arithmetic
On 10/8/15 1:48 PM, Linda Walsh wrote:
>> The arithetic `for' command takes arithmetic expressions, not shell
>> commands, and the `for' command takes a name (identifier), not a
>> shell command. Aside from any syntactic sugar (`int', `my'), these
>> are not consistent with how the shell grammar
> I think you're overlooking what I referred to above: that the exit status
> of a command substitution doesn't have any effect on whether the parent's
> command succeeds or fails except in one case: the right-hand-side of an
> assignment statement that is the last assignment in a command consistin
On 10/5/15 5:37 PM, Christoph Gysin wrote:
>> The parent shell (the one that enabled -e) should be the one to make the
>> decision about whether or not the shell exits. The exit status of the
>> command substitution doesn't make a difference except in one special case,
>> so inheriting errexit and
Chet Ramey wrote:
I understand the problems of working with 10+ year old code that's
been patched through the roof and trying to add _anything_ to the
design. Thus the proposal of keeping the idea around if bash was
ever refactored such that implementing a change like this wouldn't be
a big de
> I know you don't want to hear this, but you really need to stop thinking
> of set -e as "error checking". It is an obsolescent historical anomaly
> that bash is required to support because POSIX specifies it. It isn't
> useful for any purpose, and people who insist on using it are simply
> caus
On Thu, Oct 08, 2015 at 09:36:59PM +0300, Christoph Gysin wrote:
> But this issue brings a new corner case:
>
> func() {
> cmd1
> cmd2
> }
>
> var=$(func)
>
> This won't work, because set -e is stripped inside the substitution,
> so the whole function runs without error checking.
11 matches
Mail list logo
