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

[Bron Gondwana]

It's there because lots of people on non-Linux systems have their perl
in somewhere other than /usr/bin.  It is annoying for syntax
highlighting, though we could work around that with some build magic.


It works fine, there's no reason to remove it.



The rehash stuff no the other hand, yeah - those scripts should be
fixed.  I don't have time to do it today before the rc though!


Bron.



On Fri, 13 Jan 2017, at 10:30, ellie timoney via Cyrus-devel wrote:

> 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)

> 



--

  Bron Gondwana

  brong at fastmail.fm




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