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 bernstein...@onlight.com <mailto:n...@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
br...@fastmail.fm
--
Nic Bernstein n...@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
