Re: Debian bug #929178: wrong trap displayed inside functions

On 3/25/24 3:47 PM, Gioele Barabucci wrote: On 25/03/24 18:13, Oğuz wrote: On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci > wrote:  > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. Because

Re: Debian bug #929178: wrong trap displayed inside functions

On 3/25/24 11:45 AM, Gioele Barabucci wrote: Hi, I'm forwarding a minor issue originally reported in . If a function does not set a trap, `trap` will output the command set by the caller. This is just a cosmetic issue, the right trap will be run at runtime.

Re: Debian bug #929178: wrong trap displayed inside functions

On 25/03/24 18:13, Oğuz wrote: On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci > wrote: > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. Because they are two very commonly used /bin/sh, and

Re: Debian bug #929178: wrong trap displayed inside functions

At 2024-03-25T21:05:02+0300, Oğuz wrote: > On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson > wrote: > > [1] > > [1] http... > > I keep seeing this. Why don't you guys just paste the link? I believe I am. https://lists.gnu.org/archive/html/bug-bash/2024-03/msg00207.html And if that gets

Re: feat: exit 1 "file not found"

teknopaul writes: > Hi not sure if this is the correct forum... I believe this is the correct forum. > exit builtin accepts one and only one arg currently. > > Would it be backwards compatible and generally useful to support > echoing a reason for exiting? > > test -f file || exit 2 "file not

Re: Debian bug #929178: wrong trap displayed inside functions

On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson wrote: > [1] > [1] http... I keep seeing this. Why don't you guys just paste the link?

Re: Debian bug #929178: wrong trap displayed inside functions

At 2024-03-25T19:13:39+0200, Oğuz wrote: > On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci wrote: > > Just for reference, neither dash nor busybox sh preserve the > > caller's trap: > > I don't know why you think they are relevant. dash doesn't even support > `x=$(trap)', which is mandated by

Debian bug #929178: wrong trap displayed inside functions

On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci wrote: > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. dash doesn't even support `x=$(trap)', which is mandated by POSIX to work; and busybox sh is a bare-bones shell for

Re: Debian bug #929178: wrong trap displayed inside functions

On 25/03/24 17:12, Oğuz wrote: On Monday, March 25, 2024, Gioele Barabucci > wrote: If a function does not set a trap, `trap` will output the command set by the caller. This is just a cosmetic issue, the right trap will be run at runtime. Doesn't POSIX

Debian bug #929178: wrong trap displayed inside functions

On Monday, March 25, 2024, Gioele Barabucci wrote: > > If a function does not set a trap, `trap` will output the command set by > the caller. This is just a cosmetic issue, the right trap will be run at > runtime. > Doesn't POSIX allow this? How else do you propose we save the trap set for an

Debian bug #929178: wrong trap displayed inside functions

Hi, I'm forwarding a minor issue originally reported in . If a function does not set a trap, `trap` will output the command set by the caller. This is just a cosmetic issue, the right trap will be run at runtime. To reproduce this issue: #!/bin/bash

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On 3/24/24 1:04 PM, Zachary Santer wrote: On Fri, Mar 22, 2024 at 11:23 AM Chet Ramey wrote: This is what you can do with @K. https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00119.html Word splitting doesn't happen on the rhs of an assignment statement, so you use eval. The @K

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 3/22/24 2:02 AM, Gioele Barabucci wrote: For various reasons. First of all, because it confuses users (there are various bug reports in Debian for this specific issue). More technically, because non-builtin commands are treated differently, for example /bin/echo (from

Re: Add option to just print history, with no added timestamps or line numbers

On 3/24/24 11:39 PM, Lawrence Velázquez wrote: On Sun, Mar 24, 2024, at 11:01 PM, Dan Jacobson wrote: P.S., "\t%s" seems to have an extra space squeezed between them with bash: "\t %s", unless perhaps the spec says that %s always starts with a space. The standard doesn't say that, so in