Variable set with stdin pipe action fails leaving empty variable

[sanvila]

Hi. After I updated procmail to version 3.24 in Debian, I received the following report
from Bob Proulx which I believe deserves attention:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028356

Thanks.

[sanvila]

Hello. To reproduce, I'm using a .procmailrc file like this:

LOGFILE=$HOME/.cache/procmail.log
VERBOSE=yes

:0 h
SUBJECT=|formail -cXSubject:|cat

MYVAR=$SUBJECT

:0
/dev/null

and this command to test:

echo "Subject: thesubject" | formail | procmail

A sane procmail will show a line like this in the logfile:

procmail: Assigning "MYVAR=Subject: thesubject"

but the current version shows this instead:

procmail: Assigning "MYVAR="

According to my tests, this bug is already present in the commit tagged as v3.23pre.

This is all the info I have so far.

[paulgevers]

I don't like pinging bugs, but in Debian we treat this problem as serious which means that the new version missed the bookworm release and now is still blocking migration of the latest version to testing. Even without a fix, a comment on how the procmail developers view this bug would be welcome.

[BuGlessRB]

It has slipped by. I'll look into it this week.

[sanvila]

Hello. Any news about this?

As Paul Gevers has pointed out, having a serious bug for such a long time is an undesired anomaly for us. Currently, the old version seems to be better for general use than 3.24, because it does not suffer from this regression, so if this is not going to be fixed in a long time, I'll have to consider reuploading the old version using a version string like 3.24.really.3.23pre to fix the anomaly.

Thanks.

[voidzero]

@BuGlessRB any update on this?

[dorchain]

@BuGlessRB
Ping

[leonerd]

I too am interested in this bug. It is currently causing my entire mail delivery system to fail.

[leonerd]

I have a simpler demonstration that shows the breakage.

A receipe like:

:0
|socat stdin stderr

behaves as expected - it pipes the entire content of the mail into stderr that turns up in the mail system log. This is good.

But a receipe like:

:0
DUMMYVAR=|socat stdin stderr

causes no extra lines of log in the file. Doing other bits of scripting and so on, shows that in the VAR=... case, the invoked script receives no bytes on its stdin stream - it just sees EOF immediately.

[jmtd]

Looks like procmail > 3.22 will not make it into the next Debian stable release, either (13 days until hard freeze)

[snarkophilus]

I've been using the fix in my pull request for a couple of weeks no and haven't noticed any problems. The breakage happened in the big 5281aac roll up patch.