Re: DEBUG trap in a background shell steals controlling terminal forcing parent shell to exit
On 6/18/24 4:55 PM, Mark March wrote: I am working with a large Bash code base where most scripts disable job control and the DEBUG trap is used extensively. I noticed that if I tried to run my scripts in the background, the interactive shell that started them would immediately exit on any keyboard input. A simple repro is to run bash +m -c "/bin/echo ; trap 'trap DEBUG' DEBUG ; sleep 10" & in an interactive shell with job control enabled. Hit Enter a few times. The shell that launched this background process exits. The background process itself appears to be killed by a signal. Thanks for the report. The attached patch should fix your issue, though there might be some corner cases. Let me know. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ *** ../bash-20240609/trap.c Fri May 3 12:12:38 2024 --- trap.c Wed Jun 26 10:41:40 2024 *** *** 1287,1291 restore_pgrp_pipe (save_pipe); # endif ! if (pipeline_pgrp > 0 && ((subshell_environment & (SUBSHELL_ASYNC|SUBSHELL_PIPE)) == 0)) give_terminal_to (pipeline_pgrp, 1); --- 1287,1293 restore_pgrp_pipe (save_pipe); # endif ! /* If the trap command gave the terminal to another process group, !restore it. XXX - check running_in_background? */ ! if (job_control && pipeline_pgrp > 0 && ((subshell_environment & (SUBSHELL_ASYNC|SUBSHELL_PIPE)) == 0)) give_terminal_to (pipeline_pgrp, 1); OpenPGP_signature.asc Description: OpenPGP digital signature
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Wed, Jun 26, 2024 at 11:50 PM Martin D Kealey
wrote:
>
>
>
> On Thu, 27 Jun 2024 at 06:30, Chet Ramey wrote:
>>
>> On 6/26/24 2:18 PM, Zachary Santer wrote:
>>
>> >> On Tue, Jun 11, 2024, 12:49 PM Zachary Santer wrote:
>> >>>
>> >>> $ array=( zero one two three four five six )
>> >>> $ printf '%s\n' "${array[@]( 1 5 )}"
>> >>> one
>> >>> five
>> >
>> > This is different functionality.
>>
>> Equivalent to printf '%s\n' "${array[1}" "${array[5]}". The innovation Zach
>> wants is to have a single word expansion to do this.
>
>
> Surely the point is to handle the case where we don't know in advance how
> many elements will be wanted.
>
> In effect, it would mimic Perl's @array[@indeces] and @hash{@keys}
> functionality, where we supply an arbitrary list of indices or subscripts,
> and get back the corresponding values.
>
> Using the proposed syntax we would be able to write:
>
> array=( '' one two three four five six )
> indices=( 1 0 6 7 5 )
> printf '%s, ' "${array[@]( "${indices[@]}" )}"
> printf end\\n
>
> to get
>
> one, , six, five, end
>
> (Note that there are only 4 words resulting from the expansion, since there
> is no element '7' in 'array'. Unfortunately - and unlike Perl - Bash doesn't
> have "undef", so we have to make do with getting back fewer values in the
> resulting list if some requested array elements are unset, or if some indices
> exceed the size of the array.)
This, though I would add the caveat that 'set -u'/'set -o nounset'
should cause this expansion to fail and the script to error out if you
supply an index without a matching value.
> I agree that this syntax looks ugly, but since [@] and [*] don't function as
> subscripts, it's tricky to improve on.
>
> My suggestion would be to generalise, turning [@] and [*] into fixed
> syntactic tokens that can be combined with "ordinary" subscripting, or left
> without subscripts to retain their current meanings:
>
> "${array[*][index]}" (a long-hand version of "${array[index]}")
> "${array[@][index]}" (gives "${array[index]}" if it exists, but is
> completely elided if it doesn't - similar to how "$@" can result in no words,
> not an empty word)
I'm not sure how interested people are in having multidimensional
indexed arrays, but that's what this looks like. Like if you start
with a two-dimensional array
[ [ a b c d e ]
[ f g h i j ]
[ k l m n o ]
[ p q r s t ]
[ u v w x y ] ],
expanding "${array[@][3]}" might give you "c" "h" "m" "r" "w".
I am not asking for multidimensional array support here.
And I guess my "${array[@]( index )}" would give the same behavior as
your "${array[@][index]}".
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Thu, Jun 27, 2024 at 1:08 AM Oğuz wrote:
>
> Why not extend the arithmetic expansion syntax to allow generating multiple
> results when subscripting indexed arrays? Like `${a[1; 2; 4]}', `${a[3..5;
> 7]}', `${a[1..10..3]}', etc.
Doing this, you lose the ability to provide the list of indices you're
interested in in the form of an array. This list couldn't be arbitrary
and generated at run-time.
> These would expand like `$@' when in double quotes and like `$*' when being
> assigned to a variable.
"${*}" expansion is also necessary in other situations than when
assigning to variables. It must be possible to still specify "${@}"
and "${*}" expansion explicitly.
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Thu, Jun 27, 2024 at 9:12 AM Zachary Santer wrote:
>
> This, though I would add the caveat that 'set -u'/'set -o nounset'
> should cause this expansion to fail and the script to error out if you
> supply an index without a matching value.
> And I guess my "${array[@]( index )}" would give the same behavior as
> your "${array[@][index]}".
Though "${array[@]}" doesn't result in an error with 'set -u' when
array is empty. Which is good. I'm not complaining about that. Given
that, you might want the same behavior from "${array[@]( index )}",
which would of course still apply when you are providing multiple
indices. Not sure of the best way this would work.
Re: history-search-backward clobbers history
On 6/19/24 9:45 AM, Andreas Schwab wrote: $ printf 'echo 1234\necho 2345\necho 3456\n' > history $ HOME=$PWD HISTFILE=history TERM=xterm bash --norc -i <<<$'\20\eb1\e[5~\nhistory\n\20\20\eb2\e[5~\nhistory' bash-5.3$ echo 1234 1234 bash-5.3$ history 1 echo 1234 2 echo 2345 3 echo 13456 4 echo 1234 5 history bash-5.3$ echo 2345 2345 bash-5.3$ history 1 echo 1234 2 echo 2345 3 echo 13456 4 echo 21234 5 history 6 echo 2345 7 history bash-5.3$ exit $ cat history echo 1234 echo 2345 echo 3456 echo 21234 history echo 2345 history It took me a long time to figure this out, and it's completely dependent on this particular set of data. You have `histappend' set (it's set by default, but this would happen anyway because you have fewer history lines added during that shell session than are in the history list). Bash adds four commands to the history list during this session, starting with the `echo 21234' (it doesn't know about readline's changes to the history list). It appends those four commands to the history file, which happens to leave the `echo 3456' unchanged -- coincidentally the first history entry changed by moving around the history list and editing. You don't have revert-all-at-newline set, so history entries are still modified and still have undo lists at shell exit, and the modified entries are written out. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Thu, 27 Jun 2024, 17:08 Oğuz, wrote:
> On Thursday, June 27, 2024, Martin D Kealey
> wrote:
>
>> [...]
>
>
> That's too much to read
>
You're under no obligation to read what I write, but then kindly don't
pretend that you're "replying" to me.
Perl is not a good example to follow.
>
Perl isn't a perfect language, but it's an immense improvement over the
Shell language, even with Bash's enhancements, and more to the point, it's
an example that proves that it's possible to evolve and rebuild a language
to escape from various archaic crazinesses.
In particular modern Perl scripts no longer use dynamic scoping, unquoted
words that may or may not be string literals, or magic variables to
globally tweak behaviours. (Those things are still there, but it's possible
to avoid using them because there are better ways to get the same results.)
Why not extend the arithmetic expansion syntax to allow generating multiple
> results when subscripting indexed arrays?
>
Why limit this to subscripts?
Why not use that for generating lists directly?
Like `${a[1; 2; 4]}', `${a[3..5; 7]}', `${a[1..10..3]}', etc. These would
> expand like `$@' when in double quotes and like `$*' when being assigned to
> a variable.
>
Why limit this to numeric indexing?
Why not support associative arrays?
-Martin
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Friday, June 28, 2024, Martin D Kealey wrote: > modern Perl scripts > No such thing. Perl is a dead language, and for good reason. Why limit this to subscripts? > Where else do you need it? > Why not use that for generating lists directly? > Doesn't brace expansion already do that? Why limit this to numeric indexing? > Because you can implement it without breaking old scripts, `a; b' is a valid associative array key. > Why not support associative arrays? > No way to do that without making array expansion syntax ten times uglier or completely changing it. Bash is too good to ruin like that. -- Oğuz
