Re: fd leak with {fd}>
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 quite. You still have to pick the file descriptor you want to use
>> with
>> `exec'. But you are not being forced to use it -- by all means, if you
>> think it's not what you need or want, feel free to avoid it and encourage
>> your friends to do the same. There have been unsuccessful new features --
>> the case-modifying expansions are one example of a swing and miss.
>>
>
> You seem to say that there are 2 aspects of this new feature, giving
> control on the fd
> and letting the system choose the number.
>
> Let's see the first aspect, you are saying that leaving the fd open doing
> "{ : } {fd}>file"
> is a feature to let the user control the file descriptor.
>
> But why would one use this when you can do:
>
> exec {fd}>file
>
> That is there is already exec to answer the problem of letting the user
> manage the fd,
> Why would you use another new, non intuitive non consistent feature?
>
Precisely so! Who would feel the need for this (mis-)feature. Anyone who
wants to control the persistence of the fd will use exec. No-one will feel
the need for { : ; } {fd}>file or expect that it could even work!
I would expect to be able to use { : ; } {fd}>/dev/null as a nasty idiom to
find a free descriptor number, I could not have expected it to leave the
descriptor open.
And in fact to emphasise the unexpected nature, it damages the concept of
compound commands:
# will not leave fd open
sleep 5 {fd}>/dev/null
# will not leave fd open
( sleep 5 ) {fd}>/dev/null
# will leave fd open
{ sleep 5 ; } {fd}>/dev/null
Can it be expected that using { } as an incremental edit to a script
(because an extra command needs inserted with the same IO) should leave the
descriptor dangling, but not if ( ) is used?
If too many parts of the documentation will need annotating with exceptions
it indicates a wrong expression of the feature.
For me having bashing assigning the fd number solves another problem.
>
For me too. It is a great feature. Heavenly!
But because that was not the only problem it "solved" I spent a few hours
tracking down what my problem was and isolated this behaviour.
Then I checked the documentation and saw that there was no remark to excuse
or explain this behaviour and filed a bug. Note that documentation would
have prevented me from filing a bug. It would not have helped me avoid
wasting time. I had to already track down the problem completely in order
to realise it was related to this feature.
So in short, as keeping the fd open is available through exec from ancient
times, and as it would be unexpected here, I think it is an
un-necessary confusion.
Sam
Disabling Job Control or Enabling Minimal Config Breaks Build
Bash Version: 4.2 Description: I downloaded a fresh copy of bash 4.2 from the GNU project archives ( http://ftp.gnu.org/gnu/bash/bash-4.2.tar.gz), configured with: ./configure --disable-job-control --enable-minimal-config --disable-readline (Self-Serving Explanation: I'm attempting to debug another issue with this system at the moment related to bash seemingly masking out the SIGWINCH signal and not acknowledging terminal resizing. http://serverfault.com/questions/452340 if anyone's feeling generous and wishes to take a look.) However, it seems both --disable-job-control and --enable-minimal-config break the build. Specifically, using --enable-minimal-config seems to disable aliases. This causes an error in parse.y: /Users/chet/src/bash/src/parse.y: In function 'shell_getc': /Users/chet/src/bash/src/parse.y:2399: error: label 'pop_alias' used but not defined make: *** [y.tab.o] Error 1 Looking at parse.y, the problem seems pretty clear. The label `pop_alias' is not defined if ALIAS is not defined. However, about 15 lines down there is a `goto_popalias' statement with no such condition. The issue with --disable-job-control seems like it may be similar, however I did not take the time to look any further in to it. execute_cmd.c: In function 'execute_pipeline': execute_cmd.c:2205: error 'job_control' undeclared (first use in this function) Repeat-By: * Download a copy of bash 4.2. * Configure with either or both of '--disable-job-control' and '--enable-minimal-config'. * Attempt to build. Replicated on Debian and Ubuntu. Unfortunately I don't have access to any other family of OS at the moment to ensure this isn't related to that somehow, however it doesn't seem like it would be.
Why is not every variable initialized to its data type specific default value upon declaration in Bash?
Hi folks, when I execute the following code in Bash version "GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)", I get: declare a declare -p a # Output: -bash: declare: a: not found declare -i b declare -p b # Output: -bash: declare: b: not found declare -a c declare -p c # Output: declare -a c='()' declare -A d declare -p d # Output: declare -A d='()' Arguably I think that the above variables should either be initialized in all cases or in none of them. That would seem more consistent rather than initializing only arrays upon declaration. Cheers, Tim -- `°< C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Re: How to initialize a read-only, global, associative array in Bash?
On 11/26/2012 10:45 PM, Tim Friske wrote:
Hi folks,
Hi
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='()'
I think there should be also -g but it is not
Why doesn't Bash initialize FOOBAR with ([foo]=bar) according to
declare -p? The same declaration works outside of a function, e.g.
declare -rgA FOOBAR=([foo]=bar)
declare -p FOOBAR
# Output: declare -Ar FOOBAR='([foo]="bar" )'
Similarly the following code but without FOOBAR being read-only works:
function foobar {
declare -gA FOOBAR
FOOBAR=([foo]=bar)
}
foobar
declare -p FOOBAR
# Output: declare -A FOOBAR='([foo]="bar" )'
Is this a bug or feature?
Cheers,
Tim
BTW: I couldn't find a "bashbug" RPM package in the Fedora 17
repositories; that's why I wrote this formless mail. Sorry for that.
/usr/bin/bashbug-64
I will try to add symlink or something. Thanks
--
`°<
C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Re: Why is not every variable initialized to its data type specific default value upon declaration in Bash?
On 11/27/12 5:03 AM, Tim Friske wrote: > Hi folks, > > when I execute the following code in Bash version "GNU bash, version > 4.1.10(4)-release (i686-pc-cygwin)", I get: > > declare a > declare -p a > # Output: -bash: declare: a: not found > declare -i b > declare -p b > # Output: -bash: declare: b: not found > declare -a c > declare -p c > # Output: declare -a c='()' > declare -A d > declare -p d > # Output: declare -A d='()' > > Arguably I think that the above variables should either be initialized > in all cases or in none of them. That would seem more consistent > rather than initializing only arrays upon declaration. Thanks for the report. This is an artifact of how the arrays/hash tables are initialized by `declare', as you suspect. The variable should remain undefined until explicitly assigned a value. I will take a look and see what effect that will have on other parts of the code. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Disabling Job Control or Enabling Minimal Config Breaks Build
On 11/26/12 10:12 PM, Adam Pippin wrote:
> Repeat-By:
>
> * Download a copy of bash 4.2.
> * Configure with either or both of '--disable-job-control' and
> '--enable-minimal-config'.
> * Attempt to build.
>
> Replicated on Debian and Ubuntu. Unfortunately I don't have access to any
> other family of OS at the moment to ensure this isn't related to that
> somehow, however it doesn't seem like it would be.
The job control compilation issue was fixed in patch 18 to bash-4.2. The
parse.y change to fix the pop_alias label problem is fixed in the attached
patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.2-patched/parse.y 2012-07-08 21:53:33.0 -0400
--- parse.y 2012-10-14 20:20:34.0 -0400
***
*** 2394,2397
--- 2392,2396
to consume the quoted newline and move to the next character in
the expansion. */
+ #if defined (ALIAS)
if (expanding_alias () && shell_input_line[shell_input_line_index+1] == '\0')
{
***
*** 2404,2408
goto next_alias_char; /* and get next character */
}
! else
goto restart_read;
}
--- 2403,2408
goto next_alias_char; /* and get next character */
}
! else
! #endif
goto restart_read;
}
How to presence-detect an array variable or subscript thereof with `test -v`?
Hi folks, I came accross the `-v` option of the `test` command and wondered how I would possibly test not only string- and integer- but also array variables as a whole and in parts. I thought it should be possible to say: declare -Ai foobar=([bar]=0) test -v foobar[foo] && echo true || echo false # Output: true test -v foobar[bar] && echo true || echo false # Output: true Even quoting doesn't help here except for the opposite results: test -v "foobar[foo]" && echo true || echo false # Output: false test -v "foobar[bar]" && echo true || echo false # Output: false Obviously the results should be "false" and "true", respectively. Apart from arrays everything else works as follows: test -v a && echo true || echo false # Output: false declare a="" test -v a && echo true || echo false # Output: true test -v b && echo true || echo false # Output: false declare -i b=0 test -v b && echo true || echo false # Output: true test -v c && echo true || echo false # Output: false declare -a c=() test -v c && echo true || echo false # Output: true Cheers, Tim -- -- `°< C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Re: How to presence-detect an array variable or subscript thereof with `test -v`?
On Tue, Nov 27, 2012 at 07:57:28PM +0100, Tim Friske wrote:
> I came accross the `-v` option of the `test` command and wondered how I
> would possibly test not only string- and integer- but also array variables
> as a whole and in parts.
Sounds more like a help-bash question than a bug-bash question.
For a single element, I'd drop the test -v entirely and just use the
standard methods:
if [[ ${array[i]+set} ]]; then echo "array element i is set"; fi
(See http://mywiki.wooledge.org/BashFAQ/083).
For whole arrays, it's murkier, because arrays and strings can be
transformed into each other at will. Referencing element 0 of an array
is the same thing as referencing a scalar by the same name:
$ unset array; array=(zero one two); echo "$array"
zero
$ unset string; string="foo"; echo "${string[0]}"
foo
However, bash actually does seem to track whether a variable was
initialized as a single-element array, or as a string:
$ unset a; a=(x); declare -p a
declare -a a='([0]="x")'
$ unset b; b=x; declare -p b
declare -- b="x"
So, if you care about that particular distinction, you could find some
bash-specific test (possibly "declare -p", or possibly something else)
to distinguish them. Otherwise, they are exactly the same:
$ echo "<$a> <$b> <${a[0]}> <${b[0]}> ${#a[*]} ${#b[*]}"
1 1
Re: How to initialize a read-only, global, associative array in Bash?
On 11/27/12 8:34 AM, Roman Rakus wrote:
> On 11/26/2012 10:45 PM, Tim Friske wrote:
>> Hi folks,
> Hi
>>
>> 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='()'
> I think there should be also -g but it is not
No. The -g option affects scoping at declaration time; it is not an
attribute.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Strange re-initialization of array. Bug or feature?
Hi folks,
I execute the following code with Bash version "GNU bash, Version
4.2.39(1)-release (x86_64-redhat-linux-gnu)" on Fedora 17:
# Returns 0 else 1 if the sourcing (source) script isn't keyed by its base
name in the global "ONCE" array yet.
#
# A script should include this script near the top with "source me_once ||
return 0" in order to get sourced itself only
# once.
#
# @return 0 on success, n != 0 on failure.
#
function me_once {
unset -f me_once
if [[ ! -v ONCE ]]; then
echo AAA
declare -gAi ONCE=()
fi
echo BBB
declare -p ONCE
declare -r a="${BASH_SOURCE[2]##*/}"
if (( ${ONCE[$a]:+1} )); then
return 1
else
ONCE+=(["$a"]=1)
echo CCC
declare -p ONCE
fi
}
me_once
If sourced at least twice from another script I get the following output
printed:
AAA
BBB
declare -A ONCE='()'
CCC
declare -A ONCE='([std.bash]="1" )'
BBB
declare -Ai ONCE='()'
CCC
declare -Ai ONCE='([std.bash]="1" )'
If I remove the initialization "=()" from "declare -gAi ONCE" I get the
following output printed:
AAA
BBB
declare -Ai ONCE='()'
CCC
declare -Ai ONCE='([std.bash]="1" )'
BBB
declare -Ai ONCE='([std.bash]="1" )'
The "declare -gAi ONCE=()" seems to get executed every time although
surrounded by "[[ ! -v ONCE ]]" whereas "echo AAA" within the same if-block
only the first time.
Is this a bug or feature?
Cheers,
Tim
--
--
`°<
C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
