[32955] in Perl-Users-Digest
Perl-Users Digest, Issue: 4231 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 5 16:09:20 2014
Date: Thu, 5 Jun 2014 13:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 5 Jun 2014 Volume: 11 Number: 4231
Today's topics:
Re: binary file creation clarification <rweikusat@mobileactivedefense.com>
Re: Can't locate object method "new" via package <poornima.lokhande@gmail.com>
Re: Can't locate object method "new" via package <poornima.lokhande@gmail.com>
Re: Can't locate object method "new" via package <rweikusat@mobileactivedefense.com>
Re: Delicious Perl bug <nospam-abuse@ilyaz.org>
filllable PDFs with Perl <cartercc@gmail.com>
Re: filllable PDFs with Perl <justin.1401@purestblue.com>
Re: filllable PDFs with Perl <Vorzakir@invalid.invalid>
Re: Perl 5.20 and CGI <gravitalsun@hotmail.foo>
Re: Perl 5.20 and CGI <cartercc@gmail.com>
Re: Perl 5.20 and CGI <sbryce@scottbryce.com>
Re: Perl 5.20 and CGI <gravitalsun@hotmail.foo>
Re: Perl 5.20 and CGI <m@rtij.nl.invlalid>
Re: Perl 5.20 and CGI <sbryce@scottbryce.com>
Re: Perl 5.20 and CGI <sbryce@scottbryce.com>
Re: Perl 5.20 and CGI <rweikusat@mobileactivedefense.com>
Re: sorting file according to a unicode column <gravitalsun@hotmail.foo>
Re: sorting file according to a unicode column <hjp-usenet3@hjp.at>
Re: stupid adjectives must die <cal@example.invalid>
Re: stupid adjectives must die <*@eli.users.panix.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 04 Jun 2014 13:16:33 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: binary file creation clarification
Message-Id: <87ppiodg4e.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> IJALAB <balaji.draj@gmail.com> writes:
>> I have a file in the following format in txt file
>> ff68 adde ed5b 9ddc fe3d 7ad8 cf1c 2f39 c81c fbde be2a fcdf b9d9 e838
>> 6a6c 0d4e 493e 9d2a 5f3c cc89 490c 29c9 efad 3d7e fc1b fb2b 3cae 7e0b
>> 9c2f 3d6a 9df9 598e 5cfb daaa 2deb 79bd 1d99 8da8 98ab bfda b87d 194e
>> ce2b a9db a899 cd6a 5af8 793c 5e1c af9e cf3c 9c9e c8bc fa9d ed9b 0bde
>> aff8 7bcd 9fde 1abe 4b8b 5959 4839 2b9e 0d69 1b29 3d7d 0e9f ccba 2e8b
>> f94a cbed fe3e 5dbe ad1a eda9 ce1d cf7a 3fca bc8e ff08 cbda 69bf cd1d
>>
>> This is basically a jpeg file content and i need to make this file to
>> .bin file so that i want to check if the jpeg is opening fine.
>>
>> Can someone help on how this can be done. I am trying with the
>> following code but since i have not used pack till now, i am not sure
>> of my mistake. thanks for the help.
>
> Assuming that the byte order should be identical to the one in the text
> file (ie, ff68 should end up as 0xff, 0x68 and not 0x68, 0xff), the
> following loop works:
>
> my $data;
> while ($data = <INFILE>) {
> for ($data) {
> /\G([0-9a-f]{4})/gc && do {
> print $outfile (pack('H4', $1));
> redo;
> };
>
> /\G\s+/gc and redo;
>
> /\G$/ and last;
>
> die("Huh?\n");
> }
> }
Assuming that input files don't contain errors, that debugging the code
is not intended and that having multiple copies of the data in memory is
no problem, this can also be written as
perl -e 'print pack "(H4)*", map { split " " } <>'
The input data can either be read from STDIN or from a file (or sequence
of files) passed as arguments, output will be written to STDOUT.
------------------------------
Date: Thu, 5 Jun 2014 05:34:54 -0700 (PDT)
From: poornima lokhande <poornima.lokhande@gmail.com>
Subject: Re: Can't locate object method "new" via package
Message-Id: <d8eeeaac-64a1-4e06-9bec-a779272be06b@googlegroups.com>
Hello,
I am having a similar issue. Unsure if I should start a topic or can continue here. Until now, I was using perl 5.12 and my code was working fine. Now we upgraded to fedora19 and perl 5.16, my code errors saying
Can't locate object method "new" via package "MyModule" .
I have been using the inheritance concept in MyMdule to use a common constructor from a parent class "ParentModule".
package ParentModule;
use SomeModule::API;
our @ISA = qw(Exporter SomeModule::API);
sub new{
my $class = shift;
my %settings;
my $self = $class->SUPER::new(\%settings);
bless $self, $class;
return $self;
}
package MyModule;
our @ISA = qw(Exporter NetMRI::BVT::BVTCommon);
#use parent constructor
test.pl #my script to test the setup
use MyModule;
my $obj = MyModule->new(@input);
$obj->$method;
Can anyone please help with what has changed from perl 5.12 to 5.16 thats causing this error. Or what change can I make in order to get this working.
I have even tried writing a constructor in MyModule using SUPER::new, but get the error saying
Can't locate object method "new" via package "MyModule::SUPER"
------------------------------
Date: Thu, 5 Jun 2014 05:37:17 -0700 (PDT)
From: poornima lokhande <poornima.lokhande@gmail.com>
Subject: Re: Can't locate object method "new" via package
Message-Id: <2554c1ec-e6c2-40cd-a433-7cd9ade11ef7@googlegroups.com>
Hello,
I am having a similar issue. Unsure if I should start a topic or can continue here. Until now, I was using perl 5.12 and my code was working fine. Now we upgraded to fedora19 and perl 5.16, my code errors saying
Can't locate object method "new" via package "MyModule" .
I have been using the inheritance concept in MyMdule to use a common constructor from a parent class "ParentModule".
package ParentModule;
use SomeModule::API;
our @ISA = qw(Exporter SomeModule::API);
sub new{
my $class = shift;
my %settings;
my $self = $class->SUPER::new(\%settings);
bless $self, $class;
return $self;
}
package MyModule;
our @ISA = qw(Exporter ParentModule);
#use parent constructor
sub method{
....
}
test.pl #my script to test the setup
use MyModule;
my $obj = MyModule->new(@input);
$obj->method;
Can anyone please help with what has changed from perl 5.12 to 5.16 thats causing this error. Or what change can I make in order to get this working.
I have even tried writing a constructor in MyModule using SUPER::new, but get the error saying
Can't locate object method "new" via package "MyModule::SUPER"
------------------------------
Date: Thu, 05 Jun 2014 15:20:58 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can't locate object method "new" via package
Message-Id: <8761kfxws5.fsf@sable.mobileactivedefense.com>
poornima lokhande <poornima.lokhande@gmail.com> writes:
> I am having a similar issue. Unsure if I should start a topic or can continue here. Until now, I was using perl 5.12 and my code was working fine. Now we upgraded to fedora19 and perl 5.16, my code errors saying
> Can't locate object method "new" via package "MyModule" .
> I have been using the inheritance concept in MyMdule to use a common constructor from a parent class "ParentModule".
>
> package ParentModule;
> use SomeModule::API;
> our @ISA = qw(Exporter SomeModule::API);
>
> sub new{
> my $class = shift;
> my %settings;
> my $self = $class->SUPER::new(\%settings);
> bless $self, $class;
> return $self;
> }
>
> package MyModule;
> our @ISA = qw(Exporter NetMRI::BVT::BVTCommon);
>
> #use parent constructor
>
>
>
> test.pl #my script to test the setup
> use MyModule;
>
> my $obj = MyModule->new(@input);
> $obj->$method;
Since MyModule isn't derived from ParentMode, there's no way it could
possibly inherit ParentModule methods.
------------------------------
Date: Wed, 4 Jun 2014 04:42:59 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Delicious Perl bug
Message-Id: <lmm84j$1vv$1@dont-email.me>
On 2014-06-01, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
>> P.S. BTW, I cannot get -d go past line 1 (even with v). Why?
>
> Because there is only one line?
Wrong. What `perl -d' reports is
main::(-e:0): BEGIN { require 'perl5db.pl' };LINE: while (<>) {chomp;
DB<1> v
1: s[a]
DB<1>
So not only `v' does not report anything on the line 0 (which we KNOW
debugger KNOWS about), but it also does not report anyting for lines 2
etc.
Morevoer, doing
/cont
locks the debugger more-or-less hard.
Ilya
------------------------------
Date: Wed, 4 Jun 2014 06:36:27 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: filllable PDFs with Perl
Message-Id: <05fe8018-4bae-4309-aee7-72d94cac8dd2@googlegroups.com>
I've had good success with spitting out PDFs from Perl scripts for years, using both PDF::API2 and custom built LaTeX source files.
I now have a requirement to generate a number of fillable PDFs. These will be bulk emailed, to be filled in by the user and printed.
Does anyone know, right off hand, of a good way to do that in Perl?
Thanks, CC.
------------------------------
Date: Thu, 5 Jun 2014 10:05:31 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: filllable PDFs with Perl
Message-Id: <rfo56b-tcj.ln1@zem.masonsmusic.co.uk>
On 2014-06-04, ccc31807 <cartercc@gmail.com> wrote:
> I've had good success with spitting out PDFs from Perl scripts for years, using both PDF::API2 and custom built LaTeX source files.
>
> I now have a requirement to generate a number of fillable PDFs. These will be bulk emailed, to be filled in by the user and printed.
>
> Does anyone know, right off hand, of a good way to do that in Perl?
I too would be interested in knowing how to create fillable PDFs. I
find many hits on Google, but no solution, and search.cpan.org wasn't
coming up with anything either. I can't believe there's not a module
for it!
Maybe one of the other PDF modules could be used to analyse an
existing PDF that contains a fillable-form, and from that could be
deduced what needs to be put into the PDF?
Justin.
--
Justin C, by the sea.
------------------------------
Date: Thu, 5 Jun 2014 13:50:55 +0000 (UTC)
From: Randy Westlund <Vorzakir@invalid.invalid>
Subject: Re: filllable PDFs with Perl
Message-Id: <lmpsjv$on4$1@dont-email.me>
On 2014-06-05, Justin C wrote:
> On 2014-06-04, ccc31807 <cartercc@gmail.com> wrote:
>> I've had good success with spitting out PDFs from Perl scripts for years, using both PDF::API2 and custom built LaTeX source files.
>>
>> I now have a requirement to generate a number of fillable PDFs. These will be bulk emailed, to be filled in by the user and printed.
>>
>> Does anyone know, right off hand, of a good way to do that in Perl?
>
>
> I too would be interested in knowing how to create fillable PDFs. I
> find many hits on Google, but no solution, and search.cpan.org wasn't
> coming up with anything either. I can't believe there's not a module
> for it!
>
> Maybe one of the other PDF modules could be used to analyse an
> existing PDF that contains a fillable-form, and from that could be
> deduced what needs to be put into the PDF?
>
>
> Justin.
>
I use Template::Latex to generate PDFs. I've never needed a
fillable form, but a quick google search indicates that LaTex should
be able to do that quite easily.
http://tex.stackexchange.com/questions/14842/creating-fillable-pdfs
------------------------------
Date: Wed, 04 Jun 2014 02:14:28 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Perl 5.20 and CGI
Message-Id: <lmlkt2$1u4k$1@news.ntua.gr>
Στις 3/6/2014 18:26, ο/η ccc31807 έγραψε:
> I very occasionally do LAMP stacks with Perl, and I have always used CGI.pm, which has always worked well for me.
>
> Now that Perl 5.20 has deprecated the CGI.pm, what is the more modern way to do this?
>
> Thanks, CC.
>
i do not need any gozilla framework to think for me.
I want to print what I want where I want using CGI.pm
Do you want to talk about productivity for CGI vs gozilla-frameworks ? no problem.
------------------------------
Date: Wed, 4 Jun 2014 06:13:29 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Perl 5.20 and CGI
Message-Id: <de474267-e08e-49dd-b0fe-4501be61e3b0@googlegroups.com>
On Tuesday, June 3, 2014 7:14:28 PM UTC-4, George Mpouras wrote:
> i do not need any gozilla framework to think for me.
> I want to print what I want where I want using CGI.pm
> Do you want to talk about productivity for CGI vs gozilla-frameworks ? no problem.
George,
I totally agree! I habitually build my own custom framework for each web app I do. It's simple, crude, but does what I need and no more.
I've looked at some of the Perl frameworks, and really don't have the stomach for it. Yes, I really would like to have a conversation about the productivity for CGI versus Godzilla Framework.
CC.
------------------------------
Date: Wed, 04 Jun 2014 07:14:18 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Perl 5.20 and CGI
Message-Id: <lmn63k$eha$1@dont-email.me>
On 6/3/2014 5:14 PM, George Mpouras wrote:
> I do not need any godzilla framework to think for me.
I have been looking at Dancer, and I have come to the same conclusion.
All I need is a module that will parse the input from the client. I am
perfectly happy with HTML::Template and DBI. I don't need substitutes
for these written into the framework. One of the problems with CGI.PM is
that it does far more than you actually need it to do. Dancer is no
different in that regard. And I would have to modify some of my own
modules to work in a PSGI environment.
Are we just switching from one bloated method to another?
------------------------------
Date: Wed, 04 Jun 2014 21:27:23 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Perl 5.20 and CGI
Message-Id: <lmnoes$20gj$1@news.ntua.gr>
Στις 4/6/2014 16:14, ο/η Scott Bryce έγραψε:
> On 6/3/2014 5:14 PM, George Mpouras wrote:
>> I do not need any godzilla framework to think for me.
>
> I have been looking at Dancer, and I have come to the same conclusion.
> All I need is a module that will parse the input from the client. I am
> perfectly happy with HTML::Template and DBI. I don't need substitutes
> for these written into the framework. One of the problems with CGI.PM is
> that it does far more than you actually need it to do. Dancer is no
> different in that regard. And I would have to modify some of my own
> modules to work in a PSGI environment.
>
> Are we just switching from one bloated method to another?
>
I also look at Dancer as a CGI alternative more than once.
So I come to the task to create some forms and drop down lists filled dynamic from DB
tables. It is something that I am doing at CGI with blind eyes, and with Dancer is beyond
headache. So the next move is ... CGI
------------------------------
Date: Wed, 4 Jun 2014 21:11:33 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Perl 5.20 and CGI
Message-Id: <5k746b-qcf.ln1@news.rtij.nl>
On Wed, 04 Jun 2014 21:27:23 +0300, George Mpouras wrote:
> Στις 4/6/2014 16:14, ο/η Scott Bryce έγραψε:
>> On 6/3/2014 5:14 PM, George Mpouras wrote:
>>> I do not need any godzilla framework to think for me.
>>
>> I have been looking at Dancer, and I have come to the same conclusion.
>> All I need is a module that will parse the input from the client. I am
>> perfectly happy with HTML::Template and DBI. I don't need substitutes
>> for these written into the framework. One of the problems with CGI.PM
>> is that it does far more than you actually need it to do. Dancer is no
>> different in that regard. And I would have to modify some of my own
>> modules to work in a PSGI environment.
>>
>> Are we just switching from one bloated method to another?
>>
>>
>
> I also look at Dancer as a CGI alternative more than once.
> So I come to the task to create some forms and drop down lists filled
> dynamic from DB tables. It is something that I am doing at CGI with
> blind eyes, and with Dancer is beyond headache. So the next move is ...
> CGI
May I suggest Dancer::Plugin::SimpleCRUD? (disclaimer, I'm a contributor
to DPSC).
I use CGI.pm (mostly with TT) or Dancer (with TT) when appropriate. Both
are to heavy. Both are simple to use. Dancer needs Plack or needs to run
stand-alone, which is IMO a big disadvantage when you just want something
simple. With Dancer and plugins I can solve problems quickly. No need to
write all that boilerplate, just focus on what you want to do.
M4
------------------------------
Date: Wed, 04 Jun 2014 13:32:17 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Perl 5.20 and CGI
Message-Id: <lmns82$tgq$1@dont-email.me>
On 6/4/2014 12:27 PM, George Mpouras wrote:
> I also look at Dancer as a CGI alternative more than once. So I come
> to the task to create some forms and drop down lists filled dynamic
> from DB tables. It is something that I am doing at CGI with blind
> eyes, and with Dancer is beyond headache. So the next move is ...
> CGI
Some, please, correct me if I am wrong, but Dancer appears to set up a
whole application environment for every script. I have a website that is
composed of hundreds of CGI scripts, each serving a specific purpose. It
would be insane to have a separate environment set up on the server for
each script.
Is there a simple way for a script to communicate with the server via
PSGI without all the additional whistles and bells of an application
framework?
------------------------------
Date: Thu, 05 Jun 2014 12:14:10 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Perl 5.20 and CGI
Message-Id: <lmqc1l$25m$1@dont-email.me>
On 6/4/2014 12:27 PM, George Mpouras wrote:
> I also look at Dancer as a CGI alternative more than once. So I come
> to the task to create some forms and drop down lists filled dynamic
> from DB tables. It is something that I am doing at CGI with blind
> eyes, and with Dancer is beyond headache. So the next move is ...
> CGI
I am coming to the same conclusion.
Dancer, and other similar frameworks seem to be intended for use to
develop apps that do one task or a group of related tasks and are fairly
stable once they are released. I maintain web sites made up of hundreds
of scripts that each do one very targeted task, and are continually
under development. It seems like it would be a pain to do this under PSGI.
I found an example that uses Plack::Request and Plack::Response. The
docs discourage their use directly, but it seems cleaner than using a
framework built on top of them. Doing a little digging, it seems that
the server needs to be reconfigured and restarted each time a new app is
uploaded. This is more trouble than using CGI, which only requires a new
script to be uploaded to the server and the permissions set, especially
in an environment where new scripts are continually being added to the site.
So, it looks like I am sticking with CGI, at least for the short term. I
am looking at CGI::Minimal and CGI::Cookies to replace CGI.PM. With the
exception of parsing cookies, even CGI::Minimal does more than I need it to.
I usually develop in three phases:
1) Scripts are written to run outside of the HTTP environment. Inputs
are hard coded into the script and output is sent to a file, sans
headers. The file is opened in an appropriate viewer.
2) Once it is working properly, the script is tweaked to allow it to run
in an HTTP environment, and tested locally. Hard coded inputs are REMed
out, and the output is sent to the server/browser.
3) After it works in the HTTP environment, the script is uploaded to a
web server.
CGI.PM allows for this type of development easily. CGI::Minimal and
CGI::Cookies will require some extra tweaking of the script. It seems
that CGI::Minimal will lock up if is is not run in an HTTP environment.
CGI.PM does not. And CGI::Cookies will throw an error if I try to get
the value of a non-existing cookie. CGI.PM simple returns a NULL value.
A slight re-write of my boilerplate will take care of that problem.
If any of my observations are wrong, or my conclusions don't make sense,
I am open to input from those who are better at this than I am.
------------------------------
Date: Thu, 05 Jun 2014 21:02:17 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl 5.20 and CGI
Message-Id: <8738fjw2eu.fsf@sable.mobileactivedefense.com>
Scott Bryce <sbryce@scottbryce.com> writes:
> On 6/4/2014 12:27 PM, George Mpouras wrote:
>> I also look at Dancer as a CGI alternative more than once. So I come
>> to the task to create some forms and drop down lists filled dynamic
>> from DB tables. It is something that I am doing at CGI with blind
>> eyes, and with Dancer is beyond headache. So the next move is ...
>> CGI
>
> I am coming to the same conclusion.
>
> Dancer, and other similar frameworks seem to be intended for use to
> develop apps that do one task or a group of related tasks and are fairly
> stable once they are released. I maintain web sites made up of hundreds
> of scripts that each do one very targeted task, and are continually
> under development. It seems like it would be a pain to do this under
> PSGI.
Minus a few procedural infelicities you observed, eg, the inability to
exchange just a small part of 'the combined application', that's just a
different way to structure 'an application' (here refering to the
total functionality of 'the web site'): You're accustomed to CGI which
means that you build 'the web site' as a set of independent,
(presumably) cooperating programs and don't waste time worrying about
'creating processes to run programs' and the overhead is really usually
negligent on systems (like Linux) where 'process creation' is 'fast'
(after all, people used this model to build complex applications used by
relatively large numbers of users running on hardware which would seem
very puny when compared with current smartphones).
But there's also the competing (and actually older since it is really
'classic mainframe programming') approach that 'The Computer' executes
'The Program' (which is only started once, hence, the amortized cost of
process creation and program execution is zero) and 'The Program'
provides all required functionality via 'sub-programs' which are
integral parts of it. Other benefits of that would be that 'sharing
infrastructure code' is easier this way (since everything is part of a
single program, any subroutine can invoke any other subroutine) and that
different parts of 'the program' can cooperate by using 'shared
variables' instead of 'some IPC mechanism' (be it only creating files on
the file system). It is also easier to deal with by (relatively)
inexperienced programmers because 'add some more code to the existing
program in order to provide yet another feature' is a more
straight-forward operation than 'write a new program to do that' (and
integrate it into the existing environment in a way which requires using
tools other than "The Programming Language" and libraries written in it
which are also part of 'The Program').
NB: I usually prefer the first approach, however, everything I've ever
done via CGI was 'rather simple', while the most complex web application
I'm dealing with is a single, large 'frameworked' Java program (I'm also
dealing with things other than web application and have built some
pretty complex things from relatively simple, indepdendent parts, but
this may not be comparable).
------------------------------
Date: Wed, 04 Jun 2014 01:17:37 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: sorting file according to a unicode column
Message-Id: <lmlhif$1lbc$1@news.ntua.gr>
Στις 3/6/2014 11:57, ο/η ehabaziz2001@gmail.com έγραψε:
> How can I eecute it under dos . Is like this ?
>
> F:\COMPILER\Perl\bin\perl sorting.pl input_file.log
>
>
>
> بتاريخ الاثنين، 2 يونيو، 2014 UTC+2 9:13:37 م، كتب Rainer Weikusat:
>> ehabaziz2001@gmail.com writes:
>>
>>> I am running perl under XP dos box.
>>
>>> ------------------------------------
>>
>>> I got that errors after running :
>>
>>> F:\COMPILER\Perl\bin\perl sorting.pl 1.log
At windows using the notepad++ create a script lets say the test.pl and write there the
Perl code. then all you have to do is execute
test.pl inputdata.txt outputsorted.txt
copy/paste the following lines at test.pl
################################################################################
use strict;
use warnings;
my $file_input = exists $ARGV[0] ? (-f $ARGV[0] ? $ARGV[0]: die "The input file does not
exist\n") : die "You did not define the input file\n";
my $file_output = exists $ARGV[1] ? $ARGV[1] : die "You did not define any output file\n";
my $column = 9; # use this column for sorting
my $offset_start= 29; # importand position of the column start (count from 0)
my $offset_end = 50; # importand position of the column end (count from 0)
my @lines;
open IN, '<:utf8', $file_input or die "Fatal error \"$!\"\n";
while (<IN>) {
chomp;
my $order_by = (split /\|/, $_, -1)[$column];
my $Length = length $order_by;
my $offend = $offset_end > $Length ? $Length : $offset_end;
$order_by = substr $order_by, $offset_start, ($offend-$offset_start);
push @lines, [$order_by, $_]
}
close IN;
open OUT, '>:utf8', $file_output or die "Fatal error \"$!\"\n";
foreach (sort { $a->[0] cmp $b->[0] } @lines) {
print OUT "$_->[1]\n"
}
close OUT;
------------------------------
Date: Thu, 5 Jun 2014 14:00:14 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: sorting file according to a unicode column
Message-Id: <slrnlp0muf.r53.hjp-usenet3@hrunkner.hjp.at>
On 2014-06-02 11:01, George Mpouras <gravitalsun@hotmail.foo> wrote:
> If you are on a proper installed linux system and your files are already
> valid utf8, then you do not need the definitions
> # open FILE, '>:utf8',
> # binmode STDOUT, ':utf8';
Yes, you do, if you want a definition of offset meaningful for a user.
Consider this file:
---------------
Grüß Gott de_at
Καλημέρα gr
こんにちは jp
---------------
The first column is 11 characters wide, the second takes the rest, and
you want to sort by the second column. So you get the key with
my $key = substr($_, 11);
right?
But the German umlauts and Greek characters are each 2 bytes in utf-8
and the Japanese characters are 3 bytes. So what's the correct offset
for each line? You can't tell a priori, because it depends on the
specific characters in the first column. But if you decode the UTF-8
first, it's just 11 characters and you don't have to worry about how
many bytes it is.
So, this produces the correct output:
#!/usr/bin/perl
use warnings;
use strict;
use autodie;
my $enc = ':encoding(UTF-8)';
#my $enc = '';
open(my $in_fh, "<$enc", $ARGV[0]);
binmode(STDOUT, $enc);
my @lines;
while (<$in_fh>) {
chomp;
my $key = substr($_, 11);
push @lines, [ $key, $_ ];
}
@lines = sort { $a->[0] cmp $b->[0] } @lines;
for (@lines) {
print "$_->[1] [$_->[0]]\n";
}
But if you use the empty $enc, it produces garbage.
Of course in reality it is more complicated.
Japanese and Chinese characters are often displayed at double width,
so if I had edited my file to make the columns match up nicely in my
editor, the last line would have needed an offset of 6 instead of 11.
And for many characters there is a composed and a decomposed form: "Ü"
could be <LATIN SMALL LETTER U WITH DIAERESIS> or <LATIN SMALL LETTER U>
+ <COMBINING DIARESIS>. The latter of course counts as two characters
for substr.
Management summary: Avoid character offsets in file formats.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 04 Jun 2014 15:05:58 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: stupid adjectives must die
Message-Id: <bv9ji6Fb95uU1@mid.individual.net>
On 06/03/2014 01:38 PM, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>
> [...]
>
>> it doesn't imply that the more traditional (as seen from the perspective of
>> 197x) concepts supposed to provide an alternative have suddenly become
>> 'modern' because their devoted followers are meanwhile to young to know
>> that they're actually traditionalist.
>
> Rant continued: I think I'm really tired of the adjective 'modern' in
> itself. For most practical purpose, that fell out of use at the end of
> the first third of the last century when the fact that the people who
> used to label themselves as 'modern' didn't represent the ultimate
> culimination of human cultural history couldn't be explained away any
> longer and it really doesn't mean anything except someone asserting
> that his opinions are inherently more valuable than someone else's
> opinions because they're his opinions and not someone else's, IOW,
> whoever uses it unironically is a common dimwit --- surely an ageless
> human trait but most certainly not a new one.
>
The problem with the word "modern" is that it becomes untrue the instant
it's used and becomes increasingly-so as a function of time:
http://www.imdb.com/title/tt0062362/?ref_=nv_sr_1
I use "contemporary" instead.
--
Cal
------------------------------
Date: Thu, 5 Jun 2014 00:27:37 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: stupid adjectives must die
Message-Id: <eli$1406042003@qz.little-neck.ny.us>
In comp.lang.perl.misc, Cal Dershowitz <cal@example.invalid> wrote:
> On 06/03/2014 01:38 PM, Rainer Weikusat wrote:
> > Rant continued: I think I'm really tired of the adjective 'modern' in
> > itself. For most practical purpose, that fell out of use at the end of
> > the first third of the last century when the fact that the people who
> The problem with the word "modern" is that it becomes untrue the instant
> it's used and becomes increasingly-so as a function of time:
> http://www.imdb.com/title/tt0062362/?ref_=nv_sr_1
Huh. I was totally expecting it to be the page for this:
http://www.youtube.com/watch?v=o-x2QArMpEQ
To further support your claim: Over at archive.org, you can't search
earlier than 1800, but there are over 20 results for that one year:
https://archive.org/search.php?query=title%3A%28modern%29%20AND%20date%3A[1800-01-01%20TO%201800-12-31]
Successful men of modern times (1800)
https://archive.org/details/successfulmenofm00reli
Chapter III is "Successful Engineers and Inventors" has dates going to
1821, suggesting the title page date is a lie, however. Still, the
principle discussion of the chapter is about events of the 1700s.
Elijah
------
nothing about successful women in there, it seems
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4231
***************************************
