State of Perl scripts in tools, esp. in re: hash

ellie timoney ellie at fastmail.com
Thu Jan 12 18:30:50 EST 2017


I'm 100% in favour of discarding the "exec perl" hack -- solely because
it confuses syntax highlighting something fierce :P


But I have no particular familiarity with its historical context,
so can't reliably evaluate whether it's still needed for some
obscure reason


On Fri, Jan 13, 2017, at 06:08 AM, Nic Bernstein via Cyrus-devel wrote:
> Folks,

>  I've been working on an upgrade from 2.4.18 to 3.0.0rc1, and
>  simultaneously adding to Nicola's fine Upgrading document.  Along the
>  way, however, I've encountered several anomalies with the wide
>  assortment of Perl scripts accumulated in cyrus-imapd/tools.  There's
>  a lot of them, they often overlap and sometimes don't inter-operate.
> 

>  For example, 'rehash' understands the 'fulldirhash' setting, but
>  'dohash' does not.  Furthermore, that setting, when processed by
>  'rehash', results in directories named "A" - "Z", but most of the
>  other tools, such as 'translatesieve' or 'upgradesieve' (why so
>  many?) explicitly expect these to be lower cased, "a" - "z":
> 
>> foreach $i ("a".."z") { ...
>> 

> and so ignore the fulldirhash-ed directories.

> 

>  Also, most of the Perl scripts still have this sort of baggage:

>
>> exec perl -x -S $0 ${1+"$@"} # -*-perl-*- ... if ($] !~ /^5\..*/) { #
>> uh-oh. this isn't perl 5. foreach (split(/:/, $ENV{PATH})) { # try to
>> find "perl5". exec("$_/perl5", "-x", "-S", $0, @ARGV) if (-x
>> "$_/perl5"); } # we failed. bail. die "Your perl is too old; I need
>> perl 5.\n"; }  # load the real script. this is isolated in an 'eval'
>> so perl4 won't # choke on the perl5-isms. eval join("\n", <DATA>); if
>> ($@) { die "$@"; }  __END__ require 5; ...
>>
> Given that Perl5 was released over twenty years ago, do we really need
> this, as opposed to say, "#!/usr/bin/perl -w"?  Hell, we could even
> parameterize that and substitute with @PERL@?
> 

>  Just asking, because one needs a tool such as translatesieve to
>  handle the transition to ``unixhierarchysep: yes'', and as it sits,
>  that tool won't work.  I'm happy to fix it, but would like guidance
>  on how far to go.
> 

>  Cheers,

>      -nic

>
> -- Nic Bernstein                             nic at onlight.com
> Onlight, Inc.                             www.onlight.com 6525 W
> Bluemound Road, Suite 24           v. 414.272.4477 Milwaukee,
> Wisconsin  53213-4073
>
> Email had 1 attachment:


>  * nic.vcf
>   1k (text/x-vcard)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20170113/8a54c21c/attachment.html>


More information about the Cyrus-devel mailing list