Can't use --print-id with variable assignment

[PhrozenByte]

Using GNU Bash 4.4 on Ubuntu 18.04 (yes, legacy system, but still supported due to Ubuntu Pro, so... 🤷 I assume newer versions are affected as well) I can't use --print-id to assign the notification's ID to a variable.

The following works as expected:

$ src/notify-send.sh --print-id Test
Warning: The notification service on your device doesn't support
         hyperlinks in it's body text. So they will be filtered out.
Warning: The notification service on your device doesn't support
         images in it's body text. So they will be filtered out.
91

However, assigning the output (i.e. the notification's ID) to a variable fails:

$ FOO="$(src/notify-send.sh --print-id Test)"
src/notify-send.sh: 70: …/src/notify-common.d/setup.sh: cannot create /proc/21236/fd/pipe:[60224718]: Directory nonexistent
Warning: The notification service on your device doesn't support
         hyperlinks in it's body text. So they will be filtered out.
Warning: The notification service on your device doesn't support
         images in it's body text. So they will be filtered out.

The issue seems to be that you expect /proc/$$/fd/1 and /proc/$$/fd/2 ($FD1 and $FD2 variables in ./src/notify-common.d/setup.sh, lines 40+41) to always link to a path. However, this isn't true when the script's output is assigned to a variable; it's some magic value like pipe:[60224718] then.

I'm not entirely sure whether all this shell magic in ./src/notify-common.d/setup.sh is even necessary? 🤔 It seems like (I'm not entirely sure though) that this (i.e. redirecting stdout and stderr to a logfile and then printing it again) is solely used for debugging purposes. Why not wrap the whole logfile logic in if $LOGGING; then …; fi? That's exactly what I did locally and nothing seems to break. See pull request #2

System info:

$ bash --version
GNU bash, Version 4.4.20(1)-release (x86_64-pc-linux-gnu)
$ lsb_release -a
LSB Version:	core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.6 LTS
Release:	18.04
Codename:	bionic
$ uname -a
Linux dev 5.4.0-187-generic #207~18.04.1-Ubuntu SMP Thu Jun 13 15:01:12 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Off topic: Is there any other way to disable the warnings than piping stderr to /dev/null?

[M3TIOR]

To answer your off topic question, those warnings could absolutely be put behind the logging flag you established
earlier. In truth I wanted to make the logger more intricate like I did with my flopped apt-user.sh project, so that I could put the warnings behind a level like 2 for warning with the default logger level set to error only.

My brain's focused on other things ATM so IDK when if ever I'll get back to this. But you are right that those are obnoxious; especially when you're not in a position to upgrade the capabilities of an offending notification server or prevent an offending client from authoring Hypertext Markup notifications to a server that doesn't support it.

[M3TIOR]

I hope that having merged your PR puts this into an operable enough state for you for the time being. If you or someone else doesn't address it first, I'll try and eventually get back to it.

[PhrozenByte]

Thanks for the explanations. In regards of the server capability warnings I've just opened issue #5 to track this separately, it's not really related to the --print-id issue.

Back to topic: As far as I understand your code right you're trying to write stdout and stderr to both a logfile and the original fds. With Bash and zsh this would be pretty easy (exec > >(tee -a "$LOGFILE.1")), but POSIX-only makes things more complicated. However, there's always an equivalent. The following PoC should do the trick:

#!/bin/bash
LOGFILE=foo
echo -n > $LOGFILE.1
echo -n > $LOGFILE.2

( tail -f $LOGFILE.1 ) &
( tail -f $LOGFILE.2 >&2 ) &
trap 'kill $(jobs -p)' 0
exec 1>>$LOGFILE.1
exec 2>>"$LOGFILE.2"

foo() {
    echo "printing on stdout"
    echo "printing on stderr" >&2
}

echo "pre function"
VAR="$(foo)"
echo "var = $VAR"
echo "post function"

stdout and stderr might still get mixed up, but that's unavoidable I think.