Hello Maintainer,

I have send the  following  message  to  <procmail@lists.rwth-aachen.de>
but I think, the Debia BTS should aware of this:
----8<------------------------------------------------------------------
Hello,

I have:

----[ '/usr/share/tdtools-procmail/INC_tdmailserialnumber' ]------------
<snip>
:0
* ^X-TDMailSerialnumber: \/.*[0-9]
{
  NUMBER=${MATCH}

  :0
  * ? test -z "${NUMBER}"
  { LOG="Weird problem with the serialnumber${NL}"
    :0
    .TDMailSerialnumber/
  }

  LENGHT=`echo ${#NUMBER}`
}
------------------------------------------------------------------------

and I get this weird error:

----[ '~/Maildir_sandbox/.sandbox.log' ]--------------------------------
procmail: [16338] Tue Mar 18 19:54:32 2008
procmail: Assigning "SHELL=/bin/bash"
procmail: Assigning "PATH=/home/michelle.konzack/bin:/bin:/usr/bin:/sbin:/usr/sbin"
procmail: Assigning "MAILDIR=/home/michelle.konzack/Maildir_sandbox"
procmail: Assigning "DEFAULT=/home/michelle.konzack/Maildir_sandbox/"
procmail: Assigning "NL=
"
procmail: Assigning "STN=
"
procmail: Assigning "COMSAT=no"
procmail: Assigning "COMSAT=no"
procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "LINEBUF=65536"
procmail: Assigning "FLT_DIR=/home/michelle.konzack/.tddebdevel/projects/tdtools-procmail/tdtools-procmail-1.0.0/src"
procmail: Assigning "PROCMAIL_DIR=/home/michelle.konzack/.procmail"
procmail: Assigning "INCLUDERC=/home/michelle.konzack/.tddebdevel/projects/tdtools-procmail/tdtools-procmail-1.0.0/src/INC_tdmailserialnumber"
<snip>
procmail: Assigning "MATCH="
procmail: Matched "8068632"
procmail: Match on "^X-TDMailSerialnumber: \/.*[0-9]"
procmail: Assigning "NUMBER=8068632"
procmail: Executing " test -z "${NUMBER}""
procmail: Non-zero exitcode (1) from " test -z "${NUMBER}""
procmail: No match on " test -z "${NUMBER}""
procmail: Bad substitution of ""
procmail: Executing "echo,NUMBER}"
procmail: Assigning "LENGHT=NUMBER}"
procmail: Assigning "LASTFOLDER=/home/michelle.konzack/Maildir_sandbox/new/1205866472.16338_0.tp570.private"
 Subject: SINCERE APPEAL TO YOU
  Folder: /home/michelle.konzack/Maildir_sandbox/new/1205866472.16338_	   4742
------------------------------------------------------------------------

OK the error

    procmail: Bad substitution of ""

is in this line:

    LENGHT=`echo ${#NUMBER}`

and procmail try to execute:

    procmail: Executing "echo,NUMBER}"

which mean, even if I have  declared  "SHELL=/bin/bash"  the  procmailrc
is not correctly parsed.

The version on my Laptop (Sarge) is :

    procmail v3.22 2001/09/10

and on my new VIA EPIA Workstation:

----[ command 'apt-cache policy procmail' ]-----------------
procmail:
  Installiert:3.22-16
  Mögliche Pakete:3.22-16
  Versions-Tabelle:
 *** 3.22-16 0
       1000 ftp://ftp2.de.debian.org sid/main Packages
        500 ftp://ftp2.de.debian.org lenny/main Packages
        500 ftp://ftp2.de.debian.org etch/main Packages
        100 /var/lib/dpkg/status
     3.22-11 0
        500 ftp://ftp2.de.debian.org sarge/main Packages
------------------------------------------------------------

so, from Sarge over Etch and Lenny to Sid, the same version.

I think, this parse error should be solved.
----8<------------------------------------------------------------------


Thanks, Greetings and nice Day
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

It seems that the parser is too old (20 years?) in procmail.

The solution is to put a "; :" at the end of the command so  we need
to change from

      LENGTH=`echo ${#VAR}`
to
      LENGTH=`echo ${#VAR} ; :`

which execute directly

      bash -c "echo ${#VAR}"

and then it works.  Since AFAIK ${#VAR} is POSIX, I think,
this should be noted in the "procmailrc" or "procmailex" manpage.

Thanks, Greetings and nice Day
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

retitle 472214 procmail fails to support ${#var} expansion
thanks

procmailrc(5) BUGS section now lists this limitation.  It should
probably be mentioned more prominently, or (ideally) fixed..  In case
it's not clear, Michelle's "; :" workaround causes procmail to
evaluate the expression in the shell (per SHELLMETAS) rather than
internally.

20 years ago, the ${#...} directive didn't exist, I believe.  But since
support for it is easy, I'll include it in an update.