Re: Any chance of multi-dimensional arrays?

In article , Eduardo Bustamante wrote: >There are a lot of general purpose languages (not shell languages), that >support multi-dimensional arrays. And these languages can call external >tools just fine. Python, Perl, Ruby, ... pick one. Even Awk has faked >support for multi-dimensional arrays.

Re: fd leak with {fd}>

On 11/22/12 5:18 PM, Sam Liddicott wrote: > > As an interesting aside it seems not to be possible to close the FD > within > > the block either: > > > > { echo $fd ; eval exec "$fd>&-" ; } {fd}> /dev/null > > But this is not. There should be a way to ensure the fd's survi

Re: problem with extended regular expression in bash 4.1

On Sat, Nov 24, 2012 at 10:29:30PM +, Lawrence Steeger wrote: > Alex Chupin (achupin cisco.com> writes: > > $ bash --version; s=12345;if [[ "$s" =~ '^[0-9]+$' ]]; then echo it is a > number; else echo it is NOT a number; fi > The single quotes are being used in the match. If you remove them,

Re: fd leak with {fd}>

On 11/23/12 2:04 AM, Pierre Gaston wrote: > It seems rather counter intuitive that the fd is not closed after leaving > the block. > With the normal redirection the fd is only available inside the block > > $ { : ;} 3>&1;echo bar >&3 > -bash: 3: Bad file descriptor > > if 3 is closed why should

Re: fd leak with {fd}>

On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey wrote: > On 11/23/12 2:04 AM, Pierre Gaston wrote: > > > It seems rather counter intuitive that the fd is not closed after leaving > > the block. > > With the normal redirection the fd is only available inside the block > > > > $ { : ;} 3>&1;echo bar >&

Re: problem with extended regular expression in bash 4.1

> It changed between bash 3.1 and 3.2, documented in the NEWS file. There is > > a "compat31" option that can be turned on to restore the 3.1 behavior. > As you see it works for me in 3.25

Re: Any chance of multi-dimensional arrays?

On Sun, Nov 25, 2012 at 06:33:19AM +0100, Rene Herman wrote: > I'm currently writing a larger bash script to manage my (ogg vorbis) > music collection, including maintaining tags. Vorbis files can and > (mine) often will contain repeated tags such as, say, "artist=David > Crosby" and "artist=Gra

Re: problem with extended regular expression in bash 4.1

Thank you guys for comprehensive explanation. Regards, Alexander Chupin

Re: fd leak with {fd}>

On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston wrote: > > > On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey wrote: > >> On 11/23/12 2:04 AM, Pierre Gaston wrote: >> >> > It seems rather counter intuitive that the fd is not closed after >> leaving >> > the block. >> > With the normal redirection the f

Re: problem with extended regular expression in bash 4.1

On Mon, 26 Nov 2012 15:03:35 +0100, Davide Brini wrote: > On Mon, 26 Nov 2012 05:40:09 -0800 (PST), chupin...@gmail.com wrote: > > > > It changed between bash 3.1 and 3.2, documented in the NEWS file. > > > There is > > > > > > a "compat31" option that can be turned on to restore the 3.1 behavi

Re: problem with extended regular expression in bash 4.1

On Mon, 26 Nov 2012 05:40:09 -0800 (PST), chupin...@gmail.com wrote: > > It changed between bash 3.1 and 3.2, documented in the NEWS file. There > > is > > > > a "compat31" option that can be turned on to restore the 3.1 behavior. > > > > As you see it works for me in 3.25 Then maybe you have

Re: fd leak with {fd}>

On Mon, Nov 26, 2012 at 1:49 PM, Pierre Gaston wrote: > > > On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston wrote: > >> >> >> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey wrote: >> >>> On 11/23/12 2:04 AM, Pierre Gaston wrote: >>> >>> > It seems rather counter intuitive that the fd is not closed af

Re: fd leak with {fd}>

On 11/26/12 8:41 AM, Pierre Gaston wrote: > > > On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey > wrote: > > On 11/23/12 2:04 AM, Pierre Gaston wrote: > > > It seems rather counter intuitive that the fd is not closed after > leaving > > the block. > > W

Re: fd leak with {fd}>

On 11/26/12 9:26 AM, Sam Liddicott wrote: > It seems that ksh93 behaves just like bash in this regard > Well, as I don't use it I don't really care, but I vote for this as a > bug as I fail to see the benefit of this behavior as i find it useless > and not consistent with the n

Re: problem with extended regular expression in bash 4.1

On 11/26/12 9:07 AM, Davide Brini wrote: >> Then maybe you have the compat31 option set (or your distro sets it for >> you), or you may have a patched, non-vanilla version of bash (redhat is >> well known for doing this). >> > > And indeed: > > https://groups.google.com/forum/?fromgroups=#!topic

Re: fd leak with {fd}>

On Mon, Nov 26, 2012 at 5:02 PM, Chet Ramey wrote: > On 11/26/12 9:26 AM, Sam Liddicott wrote: > > > It seems that ksh93 behaves just like bash in this regard > > Well, as I don't use it I don't really care, but I vote for this as a > > bug as I fail to see the benefit of this beh

Re: savestring() macro in general.h runs function arguments twice.

On 11/24/12 2:32 AM, John E. Malmberg wrote: > The execute_cmd.c module uses make_command_string() as a parameter to the > savestring() macro. > > This causes the savestring() macro to call that function twice(). Thanks, good catch. I made the same temporary variable fix you did. > I have not d

Re: fd leak with {fd}>

On 11/26/12 12:11 PM, Sam Liddicott wrote: > I explained how in the lines of my response that you deleted. > > It is potentially useless because: > > 1. it is non-obvious, most users will not expect this behaviour (unless > already initiated into the secret) and so will not try to get that ben

Re: Any chance of multi-dimensional arrays?

On 11/25/12 12:33 AM, Rene Herman wrote: > Good day. > > I know that bash arrays are 1 dimensional -- but are there any plans for > providing multi-dimensional arrays? I don't have any current plans to do so. I would take a look at any contributed code to add them, though. Chet -- ``The lyf

Re: RFE: read -d STRING

On 11/23/12 7:40 PM, Chris F.A. Johnson wrote: > >I would find it very useful to allow a string of delimiters to be >used with 'read -d', with any member of the string terminating the >input and the character used being stored in a variable, e.g. >READ_DELIM. Yes, this is still on

Re: fd leak with {fd}>

On Mon, 26 Nov 2012, Chet Ramey wrote: ,,, There have been unsuccessful new features -- the case-modifying expansions are one example of a swing and miss. A miss? I use them a lot. -- Chris F.A. Johnson, Author: Pro Bash Programming: Scripting the GNU/Linux

Re: fd leak with {fd}>

On Nov 26, 2012 2:48 PM, "Chet Ramey" wrote: > > On 11/26/12 12:11 PM, Sam Liddicott wrote: > > > I explained how in the lines of my response that you deleted. > > > > It is potentially useless because: > > > > 1. it is non-obvious, most users will not expect this behaviour (unless > > already ini

How to initialize a read-only, global, associative array in Bash?

Hi folks, I execute the following code in Bash version "GNU bash, Version 4.2.39(1)-release (x86_64-redhat-linux-gnu)": function foobar { declare -rgA FOOBAR=([foo]=bar) } foobar declare -p FOOBAR # Output: declare -Ar FOOBAR='()' Why doesn't Bash initialize FOOBAR with ([foo]=bar) according t

Re: fd leak with {fd}>

On 11/26/12 6:30 PM, Dennis Williamson wrote: > Case modification in Bash is a highly viewed and highly upvoted question on > Stack Overflow. Wow. I stand corrected. I had the impression it did not get very much use based on the discussion -- or lack thereof -- here and on help-bash. Chet --

Re: Any chance of multi-dimensional arrays?

On 11/26/2012 11:27 PM, Chet Ramey wrote: I know that bash arrays are 1 dimensional -- but are there any plans for providing multi-dimensional arrays? I don't have any current plans to do so. I would take a look at any contributed code to add them, though. Thanks for the reply. It's fairly

Re: fd leak with {fd}>

On Mon, Nov 26, 2012 at 10:48 PM, Chet Ramey wrote: > On 11/26/12 12:11 PM, Sam Liddicott wrote: > > 3. there already exists simple and explicit way to get the supposed > benefit > > using the existing mechanism "exec" > > Not quite. You still have to pick the file descriptor you want to use wit