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

Nic Bernstein nic at onlight.com
Fri Jan 13 08:00:25 EST 2017


I can (and, honestly, already have) fix translatesieve, and a similar 
fix can be added to upgradesieve or any other of these scripts.  I think 
rehash should be left alone, as anyone who's already used hashing has 
what they have, which means they may already have upper-case 
directories.  Let's not break that.

I'll have something committed in an hour or two.
     -nic

On 01/12/2017 10:54 PM, Bron Gondwana via Cyrus-devel wrote:
> 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 Bernsteinnic at onlight.com <mailto:nic at onlight.com>
>>> Onlight, Inc.www.onlight.com <http://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
>
>

-- 
Nic Bernstein                             nic at onlight.com
Onlight Inc.                              www.onlight.com
6525 W Bluemound Rd., Ste 24	          v. 414.272.4477
Milwaukee, Wisconsin  53213-4073	  f. 414.290.0335

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


More information about the Cyrus-devel mailing list