Re: funsub questions
On 12/17/23 10:47 PM, Zachary Santer wrote: As a follow-on question, why would this be implemented only now? From the very beginning, capturing the stdout of an external command involved forking a subshell, and soon (assuming funsubs remain when 5.3 is released) it won't have to. It feels like something changed to make this feasible when it hadn't been before. I suppose it was mostly the work I did to make command substitution parsing call the bison parser recursively instead of using the ad-hoc scheme that had been in place for years. Once you identify all the relevant parser state, the alternate nofork command substitution becomes easier. Time and motivation are always factors, of course. -- ``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: Job control: process running from pipe doesn't get focus
On 12/15/23 12:28 PM, Maksym Telychko wrote:
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
Process does not become foreground when run from a pipe.
Repeat-By:
Conditions are very special, and I am not sure who in the chain is cause
of bug.
In short the bug in the following line, but it should executed not from a
running terminal emulator:
uxterm -e bash -c 'echo /etc/fstab | { FILE="$(cat)" ; sudoedit
"$FILE" ; }'
It line of script must be run automatically from the WM.
The chain to reproduce:
| sway wm | | uxterm| | bash ... sudoedit |
| i3 wm | --> | alacritty | -> | |
| weston | | | | |
swaywm config file:
exec_always uxterm -e bash -c 'echo /etc/fstab | { FILE="$(cat)" ; sudoedit
"$FILE" ; }'
If sudoedit running not from a pipe, it works good. Some of terminal
emulators do not reproduces
the problem, such as `foot` or `xfce4-terminal`.
The result of the chain is an editor isn't gain a focus and I cant type
anything.
Again, I'm not sure that is definetely bash, but could you please check
that. Thank you.
You might start by running a system call tracer like strace against the
sudoedit process or the bash process that's calling it and seeing what
they're doing.
--
``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: issue with debug trap
On Sat, 16 Dec 2023 at 07:21, Giacomo Comes wrote:
> debugon () {
> trap 'if (($?)); then echo "$((LINENO-1)): $(sed -n "$((LINENO-1))p"
> "$0")" ; fi' DEBUG
> }
> debugoff () {
> trap '' DEBUG
> }
>
>
Although LINENO is the command that's about to be executed, that does not
imply that LINENO-1 is necessarily the line that contains the command just
executed, whose status is in $?.
It could be wrong if there's a loop or branch, or even just blank lines.
Another problem is that it doesn't tell you which file the line is in.
A better approach is to remember the current line and then use that during
the next trap, perhaps something more like this:
# adjust to taste, especially if you like colour
debug_fmt='%-3u %s:%u %.40s\n'
debug_file=$BASH_SOURCE
debug_line=$LINENO
debugtrace() {
local e=$?
if ((e)) ; then
read -r debug_command < <( tail -n +$debug_line < "$debug_file" )
printf >&2 "$debug_fmt" "$e" \
"${debug_file##*/}" \
"$debug_line" \
"$debug_command"
fi
IFS=' ' read debug_line debug_file < <( caller )
}
debugon() { trap debugtrace DEBUG; }
debugoff() { trap '' DEBUG; }
-Martin
Re: A feature request regarding redirection to variables
On Mon, Dec 18, 2023 at 7:39 AM Luke Tidd wrote:
>
> A very common thing I need to do when writing bash is to collect both
> the stdout and stderr of a command. This can be done relatively
> reasonably with files but it would be very attractive to be able to
> redirect these directly to a variable some how.
The new no-fork command substitution feature already allows this:
$ f(){ echo foo; echo bar >&2;}
$ a=${ { b=${ f;};} 2>&1;}
$ declare -p a b
declare -- a="bar"
declare -- b="foo"
You just need to wait for the next release
