[32635] in Perl-Users-Digest
Perl-Users Digest, Issue: 3911 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 29 14:09:29 2013
Date: Fri, 29 Mar 2013 11:09:07 -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 Fri, 29 Mar 2013 Volume: 11 Number: 3911
Today's topics:
"if" as modifier causes incorrect tainted messages? bwooster47@gmail.com
Re: "if" as modifier causes incorrect tainted messages? <ben@morrow.me.uk>
accessor methods (was: Perl method names are not tied t <rweikusat@mssgmbh.com>
Different array length depending on whether it is retur paulburton0@gmail.com
Re: Different array length depending on whether it is r <ben@morrow.me.uk>
Re: Different array length depending on whether it is r <rweikusat@mssgmbh.com>
Re: Different array length depending on whether it is r <paulburton0@gmail.com>
Internal encapsulation [was: accessor methods] <ben@morrow.me.uk>
Strange behavior of "use if" (a conditional "use" with <usenet@davidfilmer.com>
Re: Strange behavior of "use if" (a conditional "use" w <bjoern@hoehrmann.de>
Re: Strange behavior of "use if" (a conditional "use" w <ben@morrow.me.uk>
Re: Strange behavior of "use if" (a conditional "use" w <derykus@gmail.com>
Text::BibTeX -- bibgrep-like script? <friendly@yorku.ca>
Re: Text::BibTeX -- bibgrep-like script? <nospam@lisse.NA>
Re: Text::BibTeX -- bibgrep-like script? <rweikusat@mssgmbh.com>
Re: Text::BibTeX -- bibgrep-like script? <friendly@yorku.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 28 Mar 2013 14:45:00 -0700 (PDT)
From: bwooster47@gmail.com
Subject: "if" as modifier causes incorrect tainted messages?
Message-Id: <f5e58b78-9e99-434f-9394-9d47e6b4e17b@googlegroups.com>
I've searched for this issue but did not find any documents or discussions - does anyone know if this is expected, and if so, why?
In a CGI script running with -Tw, a "statement if something" causes script abort with message about insecure dependency while the same thing unrolled in an "if something {statement}" works fine.
Here's the entire runnable cgi script:
use strict;
use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
$ENV{PATH} = '';
my $query = new CGI;
my $input_boolean = $query->param('boolean');
print $query->header();
print "Test started. ";
print `/bin/echo TRUE. ` if ($input_boolean);
# Insecure dependency in `` while running with -T switch at /usr/lib/cgi-bin/cgi-test.pl line 14.
# But this line below is fine:
if ($input_boolean) { print `/bin/echo TRUE. `; }
print "Test done.";
exit (0);
------------------------------
Date: Thu, 28 Mar 2013 22:37:17 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: "if" as modifier causes incorrect tainted messages?
Message-Id: <t9te2a-qq41.ln1@anubis.morrow.me.uk>
Quoth bwooster47@gmail.com:
> I've searched for this issue but did not find any documents or
> discussions - does anyone know if this is expected, and if so, why?
>
> In a CGI script running with -Tw, a "statement if something" causes
> script abort with message about insecure dependency while the same thing
> unrolled in an "if something {statement}" works fine.
>
> Here's the entire runnable cgi script:
[snip test case which can be reduced to:]
~% perl -Te'eval "1" if $^X'
Insecure dependency in eval while running with -T switch at -e line 1.
~% perl -Te'if ($^X) { eval "1" }'
~%
This has been officially declared not-a-bug, though it's not entirely
clear to me why: it seems to be to do with internal optimisation of the
taint checking; that is, if one part of an expression is tainted, the
whole expression is considered tainted (to avoid having to make taint
checks for every operator) so the eval (in my case) is disallowed. See
https://rt.perl.org/rt3/Public/Bug/Display.html?id=17867 .
Ben
------------------------------
Date: Wed, 27 Mar 2013 10:50:42 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: accessor methods (was: Perl method names are not tied to specific packages)
Message-Id: <87k3otp14t.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> NB: The obvious implication is that no 'method' which only expects to
> work with a 'thing' providing access to a certain set of 'named
> properties' actually belongs to the 'the class proper'.
Out of curiosity, I did an internet search on 'accessor method' and
the result was mostly that people think they're supposed to provide
'public' access the state of an object BUT NOT because this enables
J. Random Get-shit-done-quickly to - well - get shit done quickly by
'hijacking' methods of an existing class with the help of supplanting
the implementation instead of using it as it was supposed to be used
according to its actual 'public interface'. The 'book' example Ben
Morrow posted was actually a good example of that: The so-called
'derived class' can only 'overload' the so-called 'methods' returning
the price and discount values because the guy who created the
so-called 'derived class' was familiar with the implementation of the
so-called 'superclass' to a sufficient degree to know that this change
wouldn't break anything.
Also, some of the concerns I voiced about that are by no means things
"only a totally crazy guy like XXX" could ever come up with: There's
an article on perl monks about that,
http://www.perlmonks.org/?node_id=309952
with the usual string of 'just let me fiddle with it, sweatheart'
'persuasion replies' attached and a more cogently written
text, although actually about Java, is available here:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
This also includes some of the things I tried to express but
more-or-less failed, specifically in the idea that this essentially
turns an object into a 'C structure with higher overhead' and that
this is a natural idea for a procedural programmer trying to behave
'in an object-oriented way' for the sake of outward conformance.
------------------------------
Date: Thu, 28 Mar 2013 09:51:40 -0700 (PDT)
From: paulburton0@gmail.com
Subject: Different array length depending on whether it is returned from a subroutine
Message-Id: <79ee40b9-6502-4660-9fa9-4b2c228a351f@googlegroups.com>
This script is for a very basic web api client that I'm making. The server =
returns json and I'm using JSON:XS to decode that to native perl data struc=
tures. My problem is that I'm having trouble with an array that I'm returni=
ng from a subroutine. If I do not return the array (or arrayref), I can pri=
nt all the elements of the array using foreach. If I *do* return the array =
(or arrayref), only one element is added to the array. See annotated code b=
elow. (Unfortunately, this code won't run as-is because API access requires=
OAuth details that I can't share.) I'm hoping that there's an idiosyncrasy=
in perl (or huge stupid mistake that I'm not seeing) that someone can poin=
t out just looking at the code. I've seen similar questions asked elsewhere=
, but there's never a satisfactory answer (if any).
[... head of script snipped (oauth details, module declarations, etc.) ...]
sub fetch_likes{
my $offset =3D shift;
my $r;
if ($offset){
$r =3D $ua->get("http://api.tumblr.com/v2/user/likes?limit=3D20&off=
set=3D$offset");
}else{
$r =3D $ua->get("http://api.tumblr.com/v2/user/likes?limit=3D20");
}
my $response =3D $r->content();
my $json =3D JSON::XS->new->decode ($response);
my $likes =3D ${$json}{'response'}{'liked_posts'};
return $likes; # This is an arrayref
}
sub get_image_urls{
# This function expects a reference to an array containing liked posts.
# Such a reference is returned from fetch_likes()
my $likes =3D shift;
foreach (@$likes) {
my $photos =3D ${$_}{'photos'};
my @urls; # This initializes the array that I want to return.
foreach (@$photos){
push (@urls, ${$_}{'original_size'}{'url'}); # Populate the arr=
ay
}
foreach (@urls){ # This prints every element in the array (20 or so=
),
print; # but *only* of the 'return' line below is comment=
ed
print"\n";
}
return \@urls; # Return the array reference. If this is uncommented=
,
# the foreach immediately above it will only output =
one
# array element. Behavior is the same if it's not a=
=20
# reference
}
}
# Main
my $ref_to_likes =3D fetch_likes();
my $ref_to_urls =3D get_image_urls($ref_to_likes);
foreach (@$ref_to_urls){ # This block behaves exactly like the one in=20
# the get_image_urls sub, depending on whether=20
# the return of that sub is commented or not.
print;
print "\n";
}
------------------------------
Date: Thu, 28 Mar 2013 19:00:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Different array length depending on whether it is returned from a subroutine
Message-Id: <oige2a-ia31.ln1@anubis.morrow.me.uk>
Quoth paulburton0@gmail.com:
[...]
>
> sub get_image_urls{
[...]
> foreach (@$likes) {
> my $photos = ${$_}{'photos'};
> my @urls; # This initializes the array that I want to return.
>
> foreach (@$photos){
> push (@urls, ${$_}{'original_size'}{'url'}); # Populate the array
> }
>
> foreach (@urls){ # This prints every element in the array (20 or so),
> print; # but *only* of the 'return' line below is commented
> print"\n";
> }
I think this array only ever has one element in it? If you print it out,
using Data::Dumper or Data::Dump (Data::Dump gives clearer output, but
you need to install it from CPAN) you can see what's actually happening:
use Data::Dump qw/pp/;
warn "PHOTOS: " . pp $photos;
warn "URLS: " . pp \@urls;
> return \@urls; # Return the array reference. If this is uncommented,
> # the foreach immediately above it will only output one
> # array element. Behavior is the same if it's not a
> # reference
This return is inside the @$likes loop, so that loop will only go around
once and then immediately return. I assume that your @$photos array ends
up with only one value in it, which is why you only get one value
returned from the loop.
Probably you want to run both loops all the way before processing @urls,
something like
my @urls;
for my $like (@$likes) {
my $photos = ${$like}{photos};
for my $photo (@$photos) {
push @urls, ${$photo}{original_size}{url};
}
}
# now print and return @urls
Note that I have changed these loops to use an explicit variable rather
than the implicit $_: it's very confusing to use $_ for two different
layers of nested loops.
As a separate issue, I would write this using map instead:
my @urls =
map $$_{original_size}{url},
map @$_,
map $$_{photos},
@$likes;
but that's really just a question of style. Writing it out longhand with
for and push is fine if you're happier with that.
Ben
------------------------------
Date: Thu, 28 Mar 2013 20:25:16 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Different array length depending on whether it is returned from a subroutine
Message-Id: <874nfvclw3.fsf@sapphire.mobileactivedefense.com>
paulburton0@gmail.com writes:
[...]
> my $likes = ${$json}{'response'}{'liked_posts'};
A general remark: Perl has (meanwhile and since a while) a
dereferencing operator. And the {} automatically quote arguments which
are 'simple idenifiers'. Considering both, the line above could be
written as
my $likes = $json->{response}{liked_posts}
eliminating some of the 'line noise' characters.
>
> sub get_image_urls{
>
> # This function expects a reference to an array containing liked posts.
> # Such a reference is returned from fetch_likes()
>
> my $likes = shift;
>
> foreach (@$likes) {
>
> my $photos = ${$_}{'photos'};
>
> my @urls; # This initializes the array that I want to return.
>
> foreach (@$photos){
>
> push (@urls, ${$_}{'original_size'}{'url'}); # Populate the array
> }
>
> foreach (@urls){ # This prints every element in the array (20 or so),
> print; # but *only* of the 'return' line below is commented
> print"\n";
> }
>
> return \@urls; # Return the array reference. If this is uncommented,
> # the foreach immediately above it will only output one
> # array element. Behavior is the same if it's not a
> # reference
> }
> }
You didn't per chance mean to place the return \@urls after the outer
foreach loop? With the code as it is quoted here, only the first
element in @$likes will ever be processed because the subroutine
returns at the end of the first iteration of the outer loop.
------------------------------
Date: Fri, 29 Mar 2013 07:03:54 -0700 (PDT)
From: Paul Burton <paulburton0@gmail.com>
Subject: Re: Different array length depending on whether it is returned from a subroutine
Message-Id: <d9b4cd66-9d1d-4861-bf58-d144a0cffdcc@googlegroups.com>
On Thursday, March 28, 2013 4:25:16 PM UTC-4, Rainer Weikusat wrote:
> You didn't per chance mean to place the return \@urls after the outer
>
> foreach loop? With the code as it is quoted here, only the first
>
> element in @$likes will ever be processed because the subroutine
>
> returns at the end of the first iteration of the outer loop.
That was it. I just lost track of curly braces I guess. Thanks a lot for the second pair of eyes on this. And thanks to everyone who replied for the stylistic/practical tips as well.
------------------------------
Date: Thu, 28 Mar 2013 02:13:52 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Internal encapsulation [was: accessor methods]
Message-Id: <0klc2a-u1j.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
> > NB: The obvious implication is that no 'method' which only expects to
> > work with a 'thing' providing access to a certain set of 'named
> > properties' actually belongs to the 'the class proper'.
>
> Out of curiosity, I did an internet search on 'accessor method' and
> the result was mostly that people think they're supposed to provide
> 'public' access the state of an object BUT NOT because this enables
> J. Random Get-shit-done-quickly to - well - get shit done quickly by
> 'hijacking' methods of an existing class with the help of supplanting
> the implementation instead of using it as it was supposed to be used
> according to its actual 'public interface'. The 'book' example Ben
> Morrow posted was actually a good example of that: The so-called
> 'derived class' can only 'overload' the so-called 'methods' returning
> the price and discount values because the guy who created the
> so-called 'derived class' was familiar with the implementation of the
> so-called 'superclass' to a sufficient degree to know that this change
> wouldn't break anything.
OK, let me try one more time, because I think this is important. My
original point was not, primarily, about accessor methods, though it
came up in that context; it was more along the lines of 'methods should,
wherever reasonable, avoid relying on the internals of the object they are
called on, and instead use either the public interface or a well-defined
subclassing interface'.
In Moose terms I might express this as 'as much code as possible should
be moved out of classes and into roles, which only rely on the object
implementing certain methods' since, as you have pointed out, when you
recast code like that these methods become, strictly speaking,
independent of the class they are applied to. However, absent Moose (or
some other implementation of roles), they end up going in the class
anyway, because there's no other way to get the dispatch to work right.
Let me give you an example of this: a real, non-contrived example, this
time, meaning it will require a bit of explanation. The Template Toolkit
(TT2) is a widely-used template system for Perl. It lets you write your
templates in a simple languge with constructions like
[% IF items.size %]
<h2>Items:</h2>
<table>
[% FOR i IN items %]
<tr><th>[% i.name %]</th><td>[% i.value %]</td></tr>
[% END %]
</table>
[% ELSE %]
<p>There are no items.
[% END %]
while abstracting out the details of accessing the data: for instance,
the values in the 'items' list can be hashrefs of precomputed data or
objects which calculate the values on the fly, and the '.' TT2 operator
will work correctly with either.
The list itself is what I'm interested in here. The usual way of passing
a list to a template is to pass an arrayref, and [% FOR %] will iterate
over the referenced array much like Perl's 'for my $i (@$list)'.
However, TT2 actually performs this iteration by creating a
Template::Iterator object pointing to the array, and you can (according
to the documentation) cause [% FOR %] to iterate over things other than
arrays by passing in a Template::Iterator object directly.
So, I had reason to want to pass in a 'list' which was actually an
object referencing an open database cursor. So I create a subclass of
Template::Iterator which holds a ref to a Cursor object (and, in fact,
since that's currently all it holds I implemented it as a blessed scalar
ref, but that's not really relevant), and I start looking at the methods
I need to implement.
get_next: this returns the next value from the iterator; my Cursor
has a ->next method, so this is easy.
index: this returns the index of the current iteration. Again, my
Cursor object counts rows already, so this is easy.
There are some more methods that aren't relevent here; the ones which
are relevent are
parity: this returns "odd" and "even" for alternate rows. If it did
this by calling ->index and using the result, I could just inherit
it; however, it doesn't do that, instead it accesses the internal
->{COUNT} attribute directly. This means I have to reimplement
effectively the same logic again, for no good reason.
odd and even: these return true or false depending on the parity.
Again, if they were implemented by calling ->parity and using that,
I could ignore them; but they're not, so I need to reimplement these
as well.
first: this returns true if we are on the first row, false
otherwise. Unlike ->parity, which seems pretty useless to me, this
is actually quite useful, for situations like
[% FOR i IN items %]
[% IF loop.first %]<p>[% ELSE %]<br>[% END %][% i %]
[% END %]
('loop' is a magic TT2 variable which refers to the
Template::Iterator object for the current loop). Again, I would say
this ought to have been implemented as '->index() == 0'; and again,
it's actually implemented by accessing the underlying hashref, so if
I want it to work for my subclass I have to override it.
I seem to find this all the time with non-Moose Perl classes. Too often
they just aren't designed to have a clean subclassing interface, and one
of the reasons for that is this habit of accessing the underlying data
structure directly. At least if there's a layer of accessor methods
there's a *chance* you can keep the existing methods which do actual
work.
> Also, some of the concerns I voiced about that are by no means things
> "only a totally crazy guy like XXX" could ever come up with: There's
> an article on perl monks about that,
>
> http://www.perlmonks.org/?node_id=309952
That article would be better titled 'Why get() and set() accessor
methods should not usually be part of an object's public external
interface', and that is a sentiment I entirely agree with, particularly
for setters (or getters which return modifiable references). I am
talking about using them as part of the internal subclassing interface,
which is entirely different: the alternative is to force subclasses to
maintain the same internal representation, so this is actually
increasing encapsulation. (And no, I don't mean 'arrayref vs hashref', I
mean something more like the situation above, where what was previously
an attribute of the object itself becomes an attribute of an attribute.)
> with the usual string of 'just let me fiddle with it, sweatheart'
> 'persuasion replies' attached and a more cogently written
> text, although actually about Java, is available here:
>
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
I find the end of that article interesting: the author basically points
out that this high-minded OO design stuff only really applies when
designing a closed system, where you know in advance who all your users
will be. Perl culture is strongly biased towards writing and then
reusing generic components, rather than redoing the design and
implementation for each specific case, and in this situation what that
author calls 'unnecessary flexibility' is, in fact, a design
requirement. To my mind an important part of this is providing and
consistently using methods (such as accessors, but they are certainly
not the only case) which don't apparently do very much, but provide a
way for subclasses to make small changes and get usefully and
consistently different behaviour.
Ben
------------------------------
Date: Thu, 28 Mar 2013 14:22:09 -0700 (PDT)
From: David Filmer <usenet@davidfilmer.com>
Subject: Strange behavior of "use if" (a conditional "use" with the if module)
Message-Id: <4b7458cf-94e5-494c-a091-7cb812f76bf3@googlegroups.com>
I have a program with this line of code:
use if( $Config{'osname'} =~ /Win/ ), 'Win32::Process::Info';
Perl complains:
Too few arguments to `use if' (some code returning an empty list in list context?) at ...
However, if I change the regex operator to !~ then Perl is quite happy (the only change is replacing the equals with a bang).
Does anyone know why Perl is unhappy with =~ in my "use if" statement
thanks!
------------------------------
Date: Thu, 28 Mar 2013 22:48:05 +0100
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: Strange behavior of "use if" (a conditional "use" with the if module)
Message-Id: <39e9l859oor74idb5gi4o1mkbjqcmv80pc@hive.bjoern.hoehrmann.de>
* David Filmer wrote in comp.lang.perl.misc:
>I have a program with this line of code:
>
> use if( $Config{'osname'} =~ /Win/ ), 'Win32::Process::Info';
>
>Perl complains:
>
>Too few arguments to `use if' (some code returning an empty list in list context?) at ...
If your osname actually matches /Win/ then you probably forgot to load
Config.pm. Otherwise, the expression returns an empty list, so there are
no arguments passed, just like the error message says. Use something
like `scalar($Config{'osname'} =~ /Win/)` to force a scalar context.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
------------------------------
Date: Thu, 28 Mar 2013 22:23:16 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Strange behavior of "use if" (a conditional "use" with the if module)
Message-Id: <kfse2a-qq41.ln1@anubis.morrow.me.uk>
Quoth David Filmer <usenet@davidfilmer.com>:
> I have a program with this line of code:
>
> use if( $Config{'osname'} =~ /Win/ ), 'Win32::Process::Info';
>
> Perl complains:
>
> Too few arguments to `use if' (some code returning an empty list in list
> context?) at ...
>
> However, if I change the regex operator to !~ then Perl is quite happy
> (the only change is replacing the equals with a bang).
>
> Does anyone know why Perl is unhappy with =~ in my "use if" statement
Read the hint :). In list context an unsuccessful match returns the
empty list, so if.pm sees 'Win32::Process::Info' as the condition and no
module argument. Change it to
use if scalar($Config{osname} =~ /Win/), "Win32::Process::Info";
(Although, in fact, $Config{osname} and $^O are both always "MSWin32" on
Windows, even on Win64, so you could just use eq. [Well, strictly
speaking you could run both DOS perl and OS/2 perl on Win16 and Win95
(which would return "dos" and "os2" respectively), but there isn't any
good reason for anyone to be doing that any more.])
Ben
------------------------------
Date: Thu, 28 Mar 2013 18:19:09 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Strange behavior of "use if" (a conditional "use" with the if module)
Message-Id: <d0f3b231-3265-426e-a456-a9cd44c2018a@googlegroups.com>
On Thursday, March 28, 2013 2:22:09 PM UTC-7, David Filmer wrote:
> I have a program with this line of code:
>
>
>
> use if( $Config{'osname'} =~ /Win/ ), 'Win32::Process::Info';
>
>
>
> Perl complains:
>
>
>
> Too few arguments to `use if' (some code returning an empty list in list context?) at ...
>
>
>
> However, if I change the regex operator to !~ then Perl is quite happy (the only change is replacing the equals with a bang).
>
>
>
> Does anyone know why Perl is unhappy with =~ in my "use if" statement
>
>
>
With strict,warnings,(and more hints from diagnostics), you can hone in on what what 's going wrong:
If you forgot Config, there's a fatal warning from strict:
perl -Mstrict -wle ' use if( $Config{osname} =~ /Win/ ), "Win32::Process::Info"'
Global symbol "%Config" requires explicit package name at
line 1.
Even if you forget Config and strict both, you get hints from warnings:
perl -Mstrict -wle ' use if( $Config{osname} =~ /Win/ ), "Win32::Process::Info"'
Use of uninitialized value $Config{"osname"} in pattern
match (m//) at line 1.
Too few arguments to 'use if' (some code returning an empty list in list context?) ...
--
Charles DeRykus
------------------------------
Date: Wed, 27 Mar 2013 09:07:34 -0400
From: Michael Friendly <friendly@yorku.ca>
Subject: Text::BibTeX -- bibgrep-like script?
Message-Id: <kiuqui$sck$1@sunburst.ccs.yorku.ca>
I have a bunch of .bib files I use in writing (Ubuntu /Kile). When I
want to cite a paper, it would be quicker to have a command line utility
to grep for an author/title keyword to find the key for \cite{} than,
say to open JabRef or similar and run searches on my various .bib files,
which live in ~/texmf/bibtex/bib/.
Is there some script ready made or configurable somewhere to
use Text::BibTeX to search such a collection of files?
thanks
-Michael
PS
I did some Googling on this and found bibgrep,
http://sourceforge.net/projects/bibgrep/, but it is too old and quirky
to compile from source.
------------------------------
Date: Fri, 29 Mar 2013 15:49:13 +0200
From: Dr Eberhard Lisse <nospam@lisse.NA>
Subject: Re: Text::BibTeX -- bibgrep-like script?
Message-Id: <51559BD9.6020906@lisse.NA>
Can't you load them into SQL with jabRef and then look them up quickly?
el
On 2013-03-27 15:07 , Michael Friendly wrote:
> I have a bunch of .bib files I use in writing (Ubuntu /Kile). When I
> want to cite a paper, it would be quicker to have a command line utility
> to grep for an author/title keyword to find the key for \cite{} than,
> say to open JabRef or similar and run searches on my various .bib files,
> which live in ~/texmf/bibtex/bib/.
>
> Is there some script ready made or configurable somewhere to
> use Text::BibTeX to search such a collection of files?
>
> thanks
> -Michael
>
> PS
> I did some Googling on this and found bibgrep,
> http://sourceforge.net/projects/bibgrep/, but it is too old and quirky
> to compile from source.
>
--
if you want to reply, replace nospam with my initials
------------------------------
Date: Fri, 29 Mar 2013 13:58:51 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Text::BibTeX -- bibgrep-like script?
Message-Id: <87haju71es.fsf@sapphire.mobileactivedefense.com>
Dr Eberhard Lisse <nospam@lisse.NA> writes:
> Can't you load them into SQL with jabRef and then look them up
> quickly?
FYI/ JFTR: 'SQL' is a query language used by so-called 'relational database
management systems' (depending on whom you ask, it either means
'structured query language' or is an abbreviation of the original
[IBM] name sequel).
------------------------------
Date: Fri, 29 Mar 2013 11:41:10 -0400
From: Michael Friendly <friendly@yorku.ca>
Subject: Re: Text::BibTeX -- bibgrep-like script?
Message-Id: <kj4cmp$3cg$1@sunburst.ccs.yorku.ca>
On 3/29/2013 9:49 AM, Dr Eberhard Lisse wrote:
> Can't you load them into SQL with jabRef and then look them up quickly?
>
Thanks for the reply, but I was looking for a 'live' text-based
solution. I don't really know
how to load into SQL with jabRef, but in any case, that would entail
updating that
when the .bib files change.
FWIW, below is a perlish kludge that invokes Tom Christ's old tcgrep
script with some suitable
args in my very specific context. I was hoping to replace it with
something more
BibTeX-aware and general, perhaps based on Text::BibTeX, to be able to
search for strings in bibtex keys, authors, titles, ...
#!/usr/bin/perl
#
# bibgrep -- Prints entries in your bib file(s) that match search string.
#
# USAGE: bibgrep <string> [<files>]
#
my $home = $ENV{'HOME'};
my $tcgrep = "$home/bin/tcgrep";
# symbolic names for bib files
my (%BIBFILES) =
(
'graphics' => "$home/texmf/bibtex/bib/graphics.bib",
'statistics' => "$home/texmf/bibtex/bib/statistics.bib",
'timeref' => "$home/texmf/bibtex/bib/timeref.bib",
'Rpackages' => "$home/texmf/bibtex/bib/Rpackages.bib",
);
### Arguments
my $str = shift @ARGV;
my @files = @ARGV || values %BIBFILES;
### Main
die "USAGE: $0 <string> [<files>]\n" unless $str;
system("$tcgrep -pTia $str @files");
exit;
> el
>
> On 2013-03-27 15:07 , Michael Friendly wrote:
>> I have a bunch of .bib files I use in writing (Ubuntu /Kile). When I
>> want to cite a paper, it would be quicker to have a command line utility
>> to grep for an author/title keyword to find the key for \cite{} than,
>> say to open JabRef or similar and run searches on my various .bib files,
>> which live in ~/texmf/bibtex/bib/.
>>
>> Is there some script ready made or configurable somewhere to
>> use Text::BibTeX to search such a collection of files?
>>
>> thanks
>> -Michael
>>
>> PS
>> I did some Googling on this and found bibgrep,
>> http://sourceforge.net/projects/bibgrep/, but it is too old and quirky
>> to compile from source.
>>
>
>
------------------------------
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 3911
***************************************
