[32594] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 3866 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jan 22 03:09:29 2013

Date: Tue, 22 Jan 2013 00:09:14 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Tue, 22 Jan 2013     Volume: 11 Number: 3866

Today's topics:
    Re: Interpolating hash (Seymour J.)
    Re: Interpolating hash <ben@morrow.me.uk>
        perlio 'unix' layer file descriptor handling <rweikusat@mssgmbh.com>
    Re: plural and singular syntax in Perl5, PHP and Perl6 <hawk007@flight.us>
    Re: Redirecting socket connections in LWP::UserAgent or <ignoramus4362@NOSPAM.4362.invalid>
        Trouble with embedded whitespace in filenames using Fil <clint.olsen@gmail.com>
    Re: Trouble with embedded whitespace in filenames using <news@lawshouse.org>
    Re: Trouble with embedded whitespace in filenames using <clint.olsen@gmail.com>
    Re: Trouble with embedded whitespace in filenames using <rweikusat@mssgmbh.com>
    Re: Trouble with embedded whitespace in filenames using <clint.olsen@gmail.com>
    Re: Trouble with embedded whitespace in filenames using <ben@morrow.me.uk>
    Re: Trouble with embedded whitespace in filenames using <jurgenex@hotmail.com>
    Re: Trouble with embedded whitespace in filenames using <clint.olsen@gmail.com>
    Re: Trouble with embedded whitespace in filenames using <jurgenex@hotmail.com>
    Re: Trouble with embedded whitespace in filenames using <clint.olsen@gmail.com>
    Re: Trouble with embedded whitespace in filenames using <ben@morrow.me.uk>
    Re: Trouble with embedded whitespace in filenames using <ben@morrow.me.uk>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sun, 20 Jan 2013 11:28:35 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Interpolating hash
Message-Id: <50fc1b33$3$fuzhry+tra$mr2ice@news.patriot.net>

In <0gbms9-k2e1.ln1@anubis.morrow.me.uk>, on 01/17/2013
   at 10:44 PM, Ben Morrow <ben@morrow.me.uk> said:



>'Value' how? As a $"-separated list of undifferentiated keys and
>values,

Pretty much. Ideally I'd like the keys sorted, separated from the
values with '=>' and the values stringified.

>I would consider either of those alternatives cleaner than that
>hack. Of course, "..." . %foo . "..." will give you the scalar value
>of the hash, which is a not-particularly-useful string; you need
>something more like "..." . join($", %foo) . "...", or to use a
>module like Data::Dump which pretty-prints.

Something like this?

 use Data::Dumper;
 message "\nDumper(%contactH):\n", Dumper %contactH, "\n\n";

if I'm willing to accept the additional dependency, otherwise
something like this?

 message "\n\%contactH: ",
         join("\n\t",
              map( {"$_ => " . join($",$contactH{$_})},
                   sort keys %contactH)),
         "\n\n";

Or perhaps set an intermediate variable with the map() output?

Thanks.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Mon, 21 Jan 2013 05:15:16 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Interpolating hash
Message-Id: <4gvus9-6k4.ln1@anubis.morrow.me.uk>


Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <0gbms9-k2e1.ln1@anubis.morrow.me.uk>, on 01/17/2013
>    at 10:44 PM, Ben Morrow <ben@morrow.me.uk> said:
> 
> >'Value' how? As a $"-separated list of undifferentiated keys and
> >values,
> 
> Pretty much. Ideally I'd like the keys sorted, separated from the
> values with '=>' and the values stringified.
> 
> >I would consider either of those alternatives cleaner than that
> >hack. Of course, "..." . %foo . "..." will give you the scalar value
> >of the hash, which is a not-particularly-useful string; you need
> >something more like "..." . join($", %foo) . "...", or to use a
> >module like Data::Dump which pretty-prints.
> 
> Something like this?
> 
>  use Data::Dumper;
>  message "\nDumper(%contactH):\n", Dumper %contactH, "\n\n";

You want to pass a ref to Dumper, otherwise you'll just get a dump of a
list:

    message "\nDumper(\\%contactH):\n", Dumper \%contactH, "\n\n";

> if I'm willing to accept the additional dependency, otherwise
> something like this?
> 
>  message "\n\%contactH: ",

You don't need to escape that %. As we just established, hashes don't
interpolate into strings...

>          join("\n\t",
>               map( {"$_ => " . join($",$contactH{$_})},
>                    sort keys %contactH)),
>          "\n\n";
> 
> Or perhaps set an intermediate variable with the map() output?

Yes, any of those three options. Incidentally,

    ~% corelist Data::Dumper

    Data::Dumper was first released with perl 5.005

so it's not exactly a 'dependency'...

I prefer Data::Dump to Data::Dumper, because it prints the value as an
expression rather than a variable assignment, goes to a little more
trouble to make the result compact and easy to read, and has useful
facilities for hiding irrelevant structure, but that would be a
dependency.

Ben



------------------------------

Date: Sun, 20 Jan 2013 19:16:56 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: perlio 'unix' layer file descriptor handling
Message-Id: <87vcar1x7b.fsf@sapphire.mobileactivedefense.com>

Something (AFAIK) undocumented which bit me recently[*]: The perlio
'unix' layer maintains reference counts for all file descriptors used
by 'Perl STREAMS' (yes, I mean STREAMS) and in particular, a close
call performed on such a stream will only result in the file
descriptor being closed when the reference count drops to zero because
of that. This implies that 'nasty things' will happen when perl gets
access to file descriptors managed by independent code and that

open($fh, '<&=', $fd);

should only be used of the file descriptor will henceforth be 'owned'
by perl.

[*] The particular problem situation was that a perl stream was
creating using such an open call and the descriptor returned by the
DBD::Pg 'getfd' implementation specific interface. This was done so
that the asynchronous interface of libpq could be used together with
'a file descriptor based I/O multiplexing loop'. The (heavily
customized) database driver used here would invoke PQFinish on the
'internal' connection object when an attempt to establish a connection
asynchronously failed, closing the file descriptor as side
effect. Since this didn't destroy the 'perl stream' it remained in the
unix layer file descriptor table with a reference count of one. In
certain situations, the code would create a pipe using POSIX::pipe and
turn the write end of that into a perl stream with another 'fdopen'
open before the 'perl database streams' was destroyed. This pipe call
would return the descriptor number formerly used by the database
connection and the perl-internal reference count would thus become 2
after the 'pipe writing' stream was opened. This pipe stream was used
to write 'some commands' to an auxiliary program which would wait
until an EOF on its standard input before performing any actual
work. Because of the botched reference count, the 'close' call on the
pipe stream would not close the file descriptor and the end-result
would be the helper process waiting for the EOF and perl waiting (via
wait) for the helper process to terminate.


------------------------------

Date: Mon, 21 Jan 2013 21:36:56 -0800 (PST)
From: Andrew <hawk007@flight.us>
Subject: Re: plural and singular syntax in Perl5, PHP and Perl6
Message-Id: <dd764bf2-f808-49c2-b7e1-6d8e7eac96b2@googlegroups.com>

On Tuesday, January 15, 2013 5:38:37 PM UTC-5, Mladen Gogala wrote:
> On Sun, 13 Jan 2013 20:44:45 -0800, David Harmon wrote:
>=20
>=20
>=20
> > They will say something like a simple variable has a $ in front and an
>=20
> > array has @.  Then comes $foos[$i];  foos is an array, so where is its =
@
>=20
> > sign?  It's often a long wait for a clear answer to that.
>=20

That is precisely the syntactic/semantic "algorithm" (if you will) of "%" a=
nd "@" !

The sigil "%" is used to refer to associative array container as a whole, b=
ut a  "$" prepended to the same variable name instead, with curly braces as=
 subscript, is one, singular reference (to a singular or plural value)

The sigil "@" (without its subscript, square bracket [....]) is, similarly,=
 used to refer the entire array, but with the "$" instead of "@" one gets a=
 reference to a singular (scalar) value of that array.
  =20
Thus, both the associative array and the list, in Perl5, are each a syntact=
ical/semantic SET.  A set of (two) symbols, working together: [ "%" and "$"=
 ], and [ "@" and "$" ].  So, "%" shouldn't be seen as fixed and permanent,=
 but one working in conjunction with "$", which syntactically replaces it w=
henever a singularity it contains is referred to.=20

With the associative array, you actually have A SET of (all) THREE sigils w=
orking together semantically/syntactically ( [ "%", "$", and "@" ] ):=20

%pets=3Dqw(John dog Jane cat Bobby gerbil Laura monkey Mike cobra Betty fal=
con Sally dog Sheila rabbit Chuck dog Jeremy horse);

print join(', ', @pets{qw(Bobby Betty Jane)}), "\n";

or...

@slackers=3Dqw(Mike Bobby Laura Sheila);

print join(', ', @pets{@slackers}), "\n";

or, using plural subscripting for both hash and array, one nested in the ot=
her:

print "The pets of the first and last slackers: ",  join(', ', @pets{@slack=
ers[0,$#slackers]}), "\n";

It seems to me that the above is brilliant language design, which allows fo=
r efficient (economical), beautiful code.

And my examples are just the surface of all that's possible, in terms of th=
e  coding power this interplay between the (distinct) plural and singular s=
yntax grants. (Again: when you get to multi-dimensional arrays, multi-dimen=
sional hashes and multi-dimensional array/hash hybrids, this sigil interpla=
y in Perl5 is INVALUABLE, and probably unrivaled by any other language out =
there! (correct me if I'm wrong))

Also, again, conceptually, the notion of "singular" versus "plural" is FUND=
AMENTAL to human psychology and reason.  It is healthy and profitable to me=
ticulously address and sort out logic related to it.  This Perl syntax FORC=
ES one to fully wrap one's mind around what's going on, conceptually... whi=
ch is a good thing, in the end.


------------------------------

Date: Sun, 20 Jan 2013 11:42:16 -0600
From: Ignoramus4362 <ignoramus4362@NOSPAM.4362.invalid>
Subject: Re: Redirecting socket connections in LWP::UserAgent or WWW::Mechanize
Message-Id: <Jv-dnW9bjJvlsWHNnZ2dnUVZ_s6dnZ2d@giganews.com>

OK, I figured it out.

1. Open a SOCKS proxy tunnel with ssh -D
2. Instruct LWP::UserAgent to use localhost:port for socks proxying
3. Disable the buggy INET6.pm in perl modules under /usr. This 
   last one is upsetting, of course. 

i

On 2013-01-20, Ignoramus4362 <ignoramus4362@NOSPAM.4362.invalid> wrote:
> I use WWW::Mechanize to automate a certain web task.
>
> I connect to a HTTPS website https://web.site/url
>
> However, I want to connect from another IP address, other than what
> the computer is. 
>
> Since I have a lot of servers, I could easily set up SSH port
> forwardings so that a connection to localhost:9876 would be redirected
> as a connection to web.site port 443, through a remote server that I
> own.
>
> My question is how to instruct LWP::UserAgent or WWW::Mechanize to
> route connections through localhost:9876, and not to web.site port
> 443. 
>
> In the end, the end result will be the same, I will connect to
> web.site port 443, but through a tunnel to a completely different
> server.
>
> What I am not sure is how to tell LWP::UserAgent to do so.
>
> The proxy settings seem to do something a little different. 
>
> I am using linux, by the way.
>
> i


------------------------------

Date: Mon, 21 Jan 2013 12:21:57 -0800 (PST)
From: Clint O <clint.olsen@gmail.com>
Subject: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <ca2d0fe4-110d-465b-94d7-846de6832df2@googlegroups.com>

The following program I wrote I'm using to find duplicate files. The problem is that I have files with whitespace or potentially other special characters:

#!/opt/local/bin/perl

use Digest::MD5;
use File::Find;
use Data::Dumper;

use strict;
use warnings;

my %results = ();

sub do_file;

my @files = @ARGV;

exit 1 if !@files;

find(sub { do_file(\%results) }, @files );

for (keys %results) {
    my @f = @{$results{$_}};

    if (scalar @f > 1) {
        print "$f[0] => $f[1]\n";
    }
}

sub do_file {
    my ($hash) = @_;
    return if -d $_;

    open(my $fh, $_) or die "Can't open '$File::Find::name': $!";
    binmode $fh;

    my $digest;

    $digest = Digest::MD5->new->addfile($fh)->hexdigest;
    close $fh;

    push @{$hash->{$digest}}, $File::Find::name;
}

0;

If I create a test directory:

$ mkdir test_dir
$ cd test_dir
$ touch " my file"
$ ./dupcheck testdir
Can't open 'testdir/ my file': No such file or directory at ./dupcheck line 32.

I can't be the first one who has run into this problem, and I'm sure there's a reasonable explanation for how to cope with this, but I haven't been able to find anything via the searching etc. on the web.

Thanks,

-Clint


------------------------------

Date: Mon, 21 Jan 2013 21:15:19 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <VLWdnaYWdPl1MmDNnZ2dnUVZ8nidnZ2d@giganews.com>

On 21/01/13 20:21, Clint O wrote:
> The following program I wrote I'm using to find duplicate files. The problem is that I have files with whitespace or potentially other special characters:


> $ mkdir test_dir
> $ cd test_dir
> $ touch " my file"
> $ ./dupcheck testdir
> Can't open 'testdir/ my file': No such file or directory at ./dupcheck line 32.

You created

   "test_dir/my file"
        ^

and you're trying to open

   "testdir/ my file".
            ^

It's not there, so the program complains.

-- 

Henry Law            Manchester, England


------------------------------

Date: Mon, 21 Jan 2013 13:22:14 -0800 (PST)
From: Clint O <clint.olsen@gmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <983b89d8-bf6c-4b11-9658-2545b345ffa3@googlegroups.com>

On Monday, January 21, 2013 1:15:19 PM UTC-8, Henry Law wrote:
> 
> > Can't open 'testdir/ my file': No such file or directory at ./dupcheck line 32.
> 
> 
> 
> You created
> 
> 
> 
>    "test_dir/my file"
> 
>         ^
> 
> 
> 
> and you're trying to open
> 
> 
> 
>    "testdir/ my file".
> 
>             ^
> 
> 
> 
> It's not there, so the program complains.

Well, that "test_dir" is clearly a typo. This program would have never generated this output with a non-existent directory:

$ ./dupcheck /asfasfasdfasdf
Can't stat /asfasfasdfasdf: No such file or directory
 at ./dupcheck line 18

Anyway, my issue still stands. I cannot open a local file with embedded whitespace.

Thanks,

-Clint


------------------------------

Date: Mon, 21 Jan 2013 21:24:28 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <87mww2mdpv.fsf@sapphire.mobileactivedefense.com>

Clint O <clint.olsen@gmail.com> writes:

[...]

> The following program I wrote I'm using to find duplicate files. The
> problem is that I have files with whitespace or potentially other
> special characters:

[...]

>     open(my $fh, $_) or die "Can't open '$File::Find::name': $!";

Since you didn't specify an explicit open mode, perl parses $_ in
order to look for one and it skips leading whitespace, cf

	The filename passed to 2-argument (or 1-argument) form of
	open() will have leading and trailing whitespace deleted, and
	the normal redirection characters honored.
        [perldoc -f open]

Using open($fh, '<', $_) instead works.

BTW: Assuming you're running this as root, someone who doesn't like
you could create a file named |rm -rf `printf "\x2f"` and you probably
wouldn't like the result of trying to open that.

NB: DO NOT TRY THIS. Except if I made an error, this will execute rm
-rf / with the privileges of the invoker.

More harmless: td/|ls `printf "..\x2f"`. This will list the contents
of the directory above td.


------------------------------

Date: Mon, 21 Jan 2013 13:39:39 -0800 (PST)
From: Clint O <clint.olsen@gmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <e70be2d8-55bb-43d0-8da5-de998f498eb8@googlegroups.com>

On Monday, January 21, 2013 1:24:28 PM UTC-8, Rainer Weikusat wrote:
> Since you didn't specify an explicit open mode, perl parses $_ in
>=20
> order to look for one and it skips leading whitespace, cf
>=20
>=20
>=20
> 	The filename passed to 2-argument (or 1-argument) form of
>=20
> 	open() will have leading and trailing whitespace deleted, and
>=20
> 	the normal redirection characters honored.
>=20
>         [perldoc -f open]
>=20
>=20
>=20
> Using open($fh, '<', $_) instead works.
>=20
>=20
>=20
> BTW: Assuming you're running this as root, someone who doesn't like
>=20
> you could create a file named |rm -rf `printf "\x2f"` and you probably
>=20
> wouldn't like the result of trying to open that.
>=20
>=20
>=20
> NB: DO NOT TRY THIS. Except if I made an error, this will execute rm
>=20
> -rf / with the privileges of the invoker.
>=20
>=20
>=20
> More harmless: td/|ls `printf "..\x2f"`. This will list the contents
>=20
> of the directory above td.

Ok, thanks for the tip and the heads-up. I am running the program as root o=
n a NAS, and the files are created by my family, but just as a good FYI, ar=
e there ways I can protect myself against malicious code? Running as root e=
nsures I can read all the files w/o question. I've used Safe before, but I'=
m not sure whether it's necessary or appropriate for this application.

Thanks,

-Clint


------------------------------

Date: Mon, 21 Jan 2013 21:45:41 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <5hp0t9-tdk.ln1@anubis.morrow.me.uk>


Quoth Clint O <clint.olsen@gmail.com>:
> The following program I wrote I'm using to find duplicate files. The
> problem is that I have files with whitespace or potentially other
> special characters:
> 
>     open(my $fh, $_) or die "Can't open '$File::Find::name': $!";

Use 3-arg open:

    open(my $fh, "<", $_) or die ...;

You might also want to consider using autodie, which will do that 'or
die' for you.

>     binmode $fh;

This is not necessary on Unix systems.

> I can't be the first one who has run into this problem, and I'm sure
> there's a reasonable explanation for how to cope with this, but I
> haven't been able to find anything via the searching etc. on the web.

perldoc -q file or -q open returns the question 'How can I open a file
with a leading ">" or trailing blanks?', with this answer. perlopentut
contains an extensive discussion of the issue, though since that
document predates 3-arg open it isn't mentioned there. perldoc -f open
documents all the open syntaxes (obviously), and recommends 3-arg open.

Ben


------------------------------

Date: Mon, 21 Jan 2013 14:21:26 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <rnfrf8psb0fjvdvj87stfoahal7k01ljbe@4ax.com>

Clint O <clint.olsen@gmail.com> wrote:
>On Monday, January 21, 2013 1:15:19 PM UTC-8, Henry Law wrote:
>> 
>> > Can't open 'testdir/ my file': No such file or directory at ./dupcheck line 32.
>> 
>> You created
>>    "test_dir/my file"
>>         ^
>> and you're trying to open
>>    "testdir/ my file".
>>             ^
>> 
>> It's not there, so the program complains.
>
>Well, that "test_dir" is clearly a typo. 

So, you should be thankful that Clint found that typo and pointed it out
to, right?

>Anyway, my issue still stands. I cannot open a local file with embedded whitespace.

Well, nobody claimed that there is only on issue in your program.

jue


------------------------------

Date: Mon, 21 Jan 2013 14:32:19 -0800 (PST)
From: Clint O <clint.olsen@gmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <fed272ff-67bb-474c-887b-2cdbdbeec564@googlegroups.com>

On Monday, January 21, 2013 2:21:26 PM UTC-8, J=FCrgen Exner wrote:
> Clint O wrote:
>=20
> >On Monday, January 21, 2013 1:15:19 PM UTC-8, Henry Law wrote:
>=20
> >>=20
>=20
> >> > Can't open 'testdir/ my file': No such file or directory at ./dupche=
ck line 32.
>=20
> >>=20
>=20
> >> You created
>=20
> >>    "test_dir/my file"
>=20
> >>         ^
>=20
> >> and you're trying to open
>=20
> >>    "testdir/ my file".
>=20
> >>             ^
>=20
> >>=20
>=20
> >> It's not there, so the program complains.
>=20
> >
>=20
> >Well, that "test_dir" is clearly a typo.=20
>=20
>=20
>=20
> So, you should be thankful that Clint found that typo and pointed it out
>=20
> to, right?
>=20
>=20
>=20
> >Anyway, my issue still stands. I cannot open a local file with embedded =
whitespace.
>=20
>=20
>=20
> Well, nobody claimed that there is only on issue in your program.

Well, if you're going to critique my program and bother to post a reply, at=
 least make it relevant. People request that you post entire scripts so tha=
t the problem can be seen by others. I did due diligence by posting the scr=
ipt and made a mistake in the testcase.

-Clint


------------------------------

Date: Mon, 21 Jan 2013 15:08:35 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <qcirf8dbuj1tlbnl5o4aenrh9ljvsaku85@4ax.com>

Clint O <clint.olsen@gmail.com> wrote:
[Fullquote to prove my point]
>On Monday, January 21, 2013 2:21:26 PM UTC-8, Jürgen Exner wrote:
>> Clint O wrote:
>> 
>> >On Monday, January 21, 2013 1:15:19 PM UTC-8, Henry Law wrote:
>> 
>> >> 
>> 
>> >> > Can't open 'testdir/ my file': No such file or directory at ./dupcheck line 32.
>> 
>> >> 
>> 
>> >> You created
>> 
>> >>    "test_dir/my file"
>> 
>> >>         ^
>> 
>> >> and you're trying to open
>> 
>> >>    "testdir/ my file".
>> 
>> >>             ^
>> 
>> >> 
>> 
>> >> It's not there, so the program complains.
>> 
>> >
>> 
>> >Well, that "test_dir" is clearly a typo. 
>> 
>> 
>> 
>> So, you should be thankful that Clint found that typo and pointed it out
>> 
>> to, right?
>> 
>> 
>> 
>> >Anyway, my issue still stands. I cannot open a local file with embedded whitespace.
>> 
>> 
>> 
>> Well, nobody claimed that there is only on issue in your program.
>
>Well, if you're going to critique my program and bother to post a reply, at least make it relevant. People request that you post entire scripts so that the problem can be seen by others. I did due diligence by posting the script and made a mistake in the testcase.

Ok, because you explicitely asked for it: 
- is there a specific reason why you are adding an empty line after
every line you quote? That doesn't improve readability one bit and makes
quoting your post rather tedious.
- Is there a specific reason why your lines are longer than the usual
70-75 characters?

jue


------------------------------

Date: Mon, 21 Jan 2013 15:45:16 -0800 (PST)
From: Clint O <clint.olsen@gmail.com>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <95958366-5b53-4c38-ba9b-c0db6a205fc9@googlegroups.com>

On Monday, January 21, 2013 3:08:35 PM UTC-8, J=FCrgen Exner wrote:
> Ok, because you explicitely asked for it:=20
>=20
> - is there a specific reason why you are adding an empty line after
>=20
> every line you quote? That doesn't improve readability one bit and makes
>=20
> quoting your post rather tedious.
>=20
> - Is there a specific reason why your lines are longer than the usual
>=20
> 70-75 characters?

I'm guessing these might be artifacts of Google Groups web interface. That'=
s what I'm using to read the group. It's hard(er) to control the formatting=
 of my responses. Coming from a hard-nosed slrn background, I agree that it=
 is annoying, and if I can figure it out I will fix it.

Thanks,

-Clint


------------------------------

Date: Tue, 22 Jan 2013 06:26:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <q0o1t9-t0s.ln1@anubis.morrow.me.uk>


Quoth Clint O <clint.olsen@gmail.com>:
> On Monday, January 21, 2013 3:08:35 PM UTC-8, Jürgen Exner wrote:
> > Ok, because you explicitely asked for it: 
> > 
> > - is there a specific reason why you are adding an empty line after
> > 
> > every line you quote? That doesn't improve readability one bit and makes
> > 
> > quoting your post rather tedious.
> > 
> > - Is there a specific reason why your lines are longer than the usual
> > 
> > 70-75 characters?
> 
> I'm guessing these might be artifacts of Google Groups web interface.
> That's what I'm using to read the group. It's hard(er) to control the
> formatting of my responses. Coming from a hard-nosed slrn background, I
> agree that it is annoying, and if I can figure it out I will fix it.

That's easy. Step one: find a real news client. Step two: find a real
news server.

Google Groups is unusable as a posting interface to Usenet.

Ben



------------------------------

Date: Tue, 22 Jan 2013 06:36:58 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Trouble with embedded whitespace in filenames using File::Find
Message-Id: <alo1t9-t0s.ln1@anubis.morrow.me.uk>


Quoth Clint O <clint.olsen@gmail.com>:
> On Monday, January 21, 2013 1:24:28 PM UTC-8, Rainer Weikusat wrote:
> > 
> > BTW: Assuming you're running this as root, someone who doesn't like
> > 
> > you could create a file named |rm -rf `printf "\x2f"` and you probably
> > 
> > wouldn't like the result of trying to open that.
> 
> Ok, thanks for the tip and the heads-up. I am running the program as
> root on a NAS, and the files are created by my family, but just as a
> good FYI, are there ways I can protect myself against malicious code?
> Running as root ensures I can read all the files w/o question. 

Not running as root would be a good start. Other than that, all you can
do is avoid being stupid: that is, don't pass untrusted data to
functions that might interpret it as code to be executed.

open "<", $file is always 'safe' in the sense that it will never do
anything other than open a file for reading. (How safe that is depends
on what you're going to do with the data inside, and whether there's any
chance the file might be a device node of some sort.)

If you must do this as root, I would seriously consider using find(1),
xargs(1) and md5(1) instead, assuming your find and xargs support the
-print0 and -0 arguments. You're much less likely to make a serious
mistake using preexisting utilities than trying to write your own.

> I've used
> Safe before, but I'm not sure whether it's necessary or appropriate for
> this application.

No. Safe is only useful when you are executing untrusted Perl code,
which you should certainly not be doing as root under any circumstances,
with or without Safe.

Ben



------------------------------

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 3866
***************************************


home help back first fref pref prev next nref lref last post