Bron,
I'll agree that there are good reasons to keep this part (i.e. systems
sans shebang):
exec perl -x -S $0 ${1+"$@"} # -*-perl-*-
Or even to keep the second chunk, which searches for a Perl 5 interpreter:
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";
}
But my argument in re: Perl5 being over 20 years old bears on that.
The ugly, gnarly part is the final eval blob to protect potential Perl 4
users.
# 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__
And it's unnecessary given that the next line is:
require 5;
That eval's the thing which bullocks up the syntax highlighters and
tends to confuse idle readers.
How about we keep the former and ditch the latter?
-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
