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