Re: fd leak with {fd}>

2012-12-01 Thread Chet Ramey
On 12/1/12 1:00 AM, Dan Douglas wrote: > > I believe one of the motivations for named FDs other than automatic FD > allocation, and the reason they remain open, was probably to deal with > organizing and grouping coprocesses so that you could follow the variable > names rather than the FDs dir

Re: fd leak with {fd}>

2012-11-30 Thread Dan Douglas
On Monday, November 26, 2012 11:57:33 AM Chet Ramey wrote: > 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 no

Re: fd leak with {fd}>

2012-11-27 Thread Sam Liddicott
On Tue, Nov 27, 2012 at 7:08 AM, Pierre Gaston wrote: > > > 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 qu

Re: fd leak with {fd}>

2012-11-26 Thread Pierre Gaston
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

Re: fd leak with {fd}>

2012-11-26 Thread Chet Ramey
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: fd leak with {fd}>

2012-11-26 Thread Dennis Williamson
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

Re: fd leak with {fd}>

2012-11-26 Thread Chris F.A. Johnson
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}>

2012-11-26 Thread Chet Ramey
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: fd leak with {fd}>

2012-11-26 Thread Sam Liddicott
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: fd leak with {fd}>

2012-11-26 Thread Chet Ramey
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: fd leak with {fd}>

2012-11-26 Thread Chet Ramey
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}>

2012-11-26 Thread Sam Liddicott
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}>

2012-11-26 Thread Pierre Gaston
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: fd leak with {fd}>

2012-11-26 Thread Pierre Gaston
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: fd leak with {fd}>

2012-11-26 Thread Chet Ramey
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}>

2012-11-26 Thread Chet Ramey
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: fd leak with {fd}>

2012-11-22 Thread Pierre Gaston
On Thu, Nov 22, 2012 at 9:15 PM, Chet Ramey wrote: > On 11/16/12 10:47 AM, Sam Liddicott wrote: > > Repeated executions of: { echo $fd ; } {fd}> /dev/null > > will emit different numbers, indicating that fd is not closed when the > > block completes. > > This is intentional. Having been given a

Re: fd leak with {fd}>

2012-11-22 Thread Sam Liddicott
On Thu, Nov 22, 2012 at 7:15 PM, Chet Ramey wrote: > On 11/16/12 10:47 AM, Sam Liddicott wrote: > > Repeated executions of: { echo $fd ; } {fd}> /dev/null > > will emit different numbers, indicating that fd is not closed when the > > block completes. > > This is intentional. Having been given a

Re: fd leak with {fd}>

2012-11-22 Thread Chet Ramey
On 11/16/12 10:47 AM, Sam Liddicott wrote: > Repeated executions of: { echo $fd ; } {fd}> /dev/null > will emit different numbers, indicating that fd is not closed when the > block completes. This is intentional. Having been given a handle to the file descriptor, the shell programmer is assumed t

fd leak with {fd}>

2012-11-16 Thread Sam Liddicott
Repeated executions of: { echo $fd ; } {fd}> /dev/null will emit different numbers, indicating that fd is not closed when the block completes. 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