[32295] in Perl-Users-Digest
Perl-Users Digest, Issue: 3562 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 9 09:09:25 2011
Date: Fri, 9 Dec 2011 06:09:08 -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 Fri, 9 Dec 2011 Volume: 11 Number: 3562
Today's topics:
CGI and temFileName -- uploading files <cartercc@gmail.com>
CGI table tidy layout possible? <justin.1111@purestblue.com>
Re: CGI table tidy layout possible? <justin.1111@purestblue.com>
Re: IO::Socket::INET hostname restrictions? <ben@morrow.me.uk>
Re: Problem configuring OS/2 for installing CPAN packag <dave.r.yeo@gmail.com>
Re: Problem configuring OS/2 for installing CPAN packag <dave.r.yeo@gmail.com>
Re: Problem configuring OS/2 for installing CPAN packag <ben@morrow.me.uk>
Re: Problem configuring OS/2 for installing CPAN packag <dave.r.yeo@gmail.com>
Re: simple xml - change tag name <RedGrittyBrick@spamweary.invalid>
Re: simple xml - change tag name <news@lawshouse.org>
Re: simple xml - change tag name <willem@toad.stack.nl>
Re: ways to check for octets outside of the safe ASCII <ben@morrow.me.uk>
Re: ways to check for octets outside of the safe ASCII <ben@morrow.me.uk>
Re: ways to check for octets outside of the safe ASCII <rweikusat@mssgmbh.com>
Re: ways to check for octets outside of the safe ASCII <ben@morrow.me.uk>
Re: ways to check for octets outside of the safe ASCII <jurgenex@hotmail.com>
Re: ways to check for octets outside of the safe ASCII <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 8 Dec 2011 12:12:46 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: CGI and temFileName -- uploading files
Message-Id: <232af951-d0c3-431a-8afc-2d017dce6919@d17g2000yql.googlegroups.com>
I have an internal app working on Windows with Apache that munges data
files and generates reports. It runs inside our firewall, and only
four people have access. We had a number of these kinds of apps to do
and limited time, so I took the easy way out (always dangerous, hence
this post) and used the CGI method tmpFileName() to grab the upload
file(s), open them, and write the data to memory. The upload files are
deleted when the script exits, which is fine as we don't need to save
them on the server.
The apps don't have any security at all other than restriction to four
users internal to our local network, and they are in the offices down
the hall so they are certainly within shouting distance if not
grabbing distance. I am aware that Bad Things can happen with file
uploads but am not concerned in general because we are not attached to
the outside world (no external access to the network).
Here's the question: is there anything extremely dangerous in doing
things this way, in view of the fact that we control the server, the
data, the users, and the interface?
When I say 'this way' what I mean is that our data file(s) are
uploaded via an HTML file form upload widget, I capture the OS name
with tmpFileName, use that as a file handle to open and read the
contents of the file, close the file, and write the reports to the
local file system BEFORE THE CGI SCRIPT EXITS! I don't want to save a
local copy of the input files on the server, and it was easier to do
it this way rather than writing to a local file, then munging the
local file before deleting it.
Thanks, CC.
------------------------------
Date: Fri, 9 Dec 2011 10:58:03 +0000
From: Justin C <justin.1111@purestblue.com>
Subject: CGI table tidy layout possible?
Message-Id: <r669r8-ek4.ln1@zem.masonsmusic.co.uk>
Can CGI print tidy html? The below code seems correct as per CGI
documentation but the output is a mess. If there's anything not
displayed right and I have to rummage through the HTML to figure out
what it is, it's not very easy because of the awfully formatted HTML.
Here's my code, my live data is sixty lines so you can imagine how that
HTML looks.
#!/usr/bin/perl
use warnings;
use strict;
use CGI qw/:standard *table/;
my $names;
while (<DATA>) {
chomp;
my ($name, $code) = split /\|/;
$names->{$name} = $code;
}
print header, start_html(), start_table(),
map {
Tr([
td([$_, $names->{$_}])
])
} sort keys %$names;
print end_table();
__DATA__
Paul McCartney|2342
John Lennon|2134
George Harrison|4432
Ringo Starr|9876
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 9 Dec 2011 11:11:42 +0000
From: Justin C <justin.1111@purestblue.com>
Subject: Re: CGI table tidy layout possible?
Message-Id: <e079r8-mr4.ln1@zem.masonsmusic.co.uk>
On 2011-12-09, Justin C <justin.1111@purestblue.com> wrote:
> Can CGI print tidy html?
Very sorry to have wasted peoples' time. I've found the solution, I
wasn't searching on the correct words. Quoting CGI.pm:
"To get pretty-printed output, please use CGI::Pretty..."
Justin.
--
Justin C, by the sea.
------------------------------
Date: Thu, 8 Dec 2011 21:58:58 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Socket::INET hostname restrictions?
Message-Id: <2io7r8-1si.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <1ua5r8-ac2.ln1@anubis.morrow.me.uk>, on 12/07/2011
> at 11:54 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >apply the patch,
>
> What's the command, and are there any environment variables I should
> set?
Save that message (the whole message or just the patch portion, it
doesn't matter) to a file. Untar IO-1.25.tar.gz, change directory to
IO-1.25, and run
patch -p1 < saved-patch-file
perl Makefile.PL
make test
perl -Mblib -MIO::Socket::INET -e"IO::Socket::INET->new(
PeerAddr => 'whois.nic.mn', PeerPort => 43,
Timeout => 5) or die $@"
You need whatever environment variables set you need to run perl and
gcc, but nothing else. 'make test' should return quite a lot of output
followed by
All tests successful.
Files=17, Tests=180, <some more details>
Result: PASS
The last command should be all on one line, and should return
IO::Socket::INET: connect: Connection refused at -e line 1.
rather than the
IO::Socket::INET: connect: Invalid argument at -e line 1.
you get if you omit the '-Mblib'.
Ben
------------------------------
Date: Thu, 08 Dec 2011 09:25:24 -0800
From: Dave Yeo <dave.r.yeo@gmail.com>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <4ee0f306$0$26186$c3e8da3$c14f6927@news.astraweb.com>
Shmuel (Seymour J.) Metz wrote:
> In<4ee0daa1$0$9670$c3e8da3$1cbc7475@news.astraweb.com>, on 12/08/2011
> at 07:40 AM, Dave Yeo<dave.r.yeo@gmail.com> said:
>
>> IIRC the only one needed is libc063.dll (or libc064.dll if you've
>> updated) which just needs to be in LIBPATH but see below.
>
> That comes with my system.
>
>> but it seems to refer to gcc335.cmd
>
> I'll try that.
>
There might also be, in \usr\local452 gcc452.cmd (adjust for different
versions of GCC). Double check the script for correct drive letters etc
Dave
------------------------------
Date: Thu, 08 Dec 2011 16:09:05 -0800
From: Dave Yeo <dave.r.yeo@gmail.com>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <4ee151a5$0$19683$c3e8da3$c8b7d2e6@news.astraweb.com>
Shmuel (Seymour J.) Metz wrote:
> In<4ee0e196$1$fuzhry+tra$mr2ice@news.patriot.net>, on 12/08/2011
> at 11:11 AM, Shmuel (Seymour J.) Metz
> <spamtrap@library.lspace.org.invalid> said:
>
>> I'll try that.
>
> I get further with
>
> SET PERLLOC=Q:\PROGRAMS\PERL
> u:\gcc335.cmd
> cdd H:\vendors\cpan\netdns
> perl Makefile.PL
> U:\extras\bin\make
>
> However, the generated make file has 8 blanks where make expects tabs
>
> [h:\]SET PERLLOC=Q:\PROGRAMS\PERL
>
> [h:\]u:\gcc335.cmd
>
> [h:\]cdd H:\vendors\cpan\netdns
>
> [h:\vendors\cpan\netdns]perl Makefile.PL
>
>
> The libraries needed to support IPv6 transport have not been found.
> You will need recent versions of the IO::Socket::INET6 and Socket6
> libraries (from CPAN).
>
> Testing if you have a C compiler and the needed header files....
> You have a working compiler.
>
> You appear to be directly connected to the Internet. I have some
> tests
> that try to query live nameservers.
>
> Do you want to enable these tests? [y] y
> Checking if your kit is complete...
> Looks good
> Warning: prerequisite Digest::HMAC_MD5 1 not found.
> Warning: prerequisite Net::IP 1.2 not found.
> Have /perl5/lib/5.10.0/os2/Config.pm expected
> Q:/PROGRAMS/PERL/lib/5.10.0/os2/Config.pm
> Your perl and your Config.pm seem to have different ideas about the
> architecture they are running on.
> Perl thinks: [os2]
> Config says: [os2]
> This may or may not cause problems. Please check your installation of
> perl
> if you have problems building this extension.
> Note (probably harmless): No library found for -lsocket
> Writing Makefile for Net::DNS
>
> [h:\vendors\cpan\netdns]U:\extras\bin\make
> Makefile:1301: *** missing separator (did you mean TAB instead of 8
> spaces?). Stop.
>
> If I cange ' ' to '08'x in line 1301, I get the same message
> for line 436. If I make the same change to that line, I get
> Makefile:436: *** missing separator. Stop.
>
Looks like a bug in Pauls perl. BTW, the missing -lsocket is harmless.
EMX needed -lsocket but the newer GCC's don't. It is still a sign of
something wrong with your setup as there is usually a libsocket.a and
libsocket.lib in \usr\lib. Note also that OS/2 can handle libraries both
with and without the lib prefix.
Dave
------------------------------
Date: Fri, 9 Dec 2011 00:37:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <qr18r8-r2l.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>
> [h:\vendors\cpan\netdns]U:\extras\bin\make
> Makefile:1301: *** missing separator (did you mean TAB instead of 8
> spaces?). Stop.
What does the Makefile look like for a few lines each side of line 1301?
If I run Net-DNS' Makefile.PL here, l1301 is in the middle of the
pm_to_blib section, which doesn't seem a likely place for a single
instance of tabs instead of spaces.
Also, are you using MakeMaker version 6.42, which came with 5.10.0, or
some more recent version?
perl -MExtUtils::MakeMaker -E"say ExtUtils::MakeMaker->VERSION"
will tell you.
> If I cange ' ' to '08'x in line 1301, I get the same message
> for line 436. If I make the same change to that line, I get
> Makefile:436: *** missing separator. Stop.
Ditto: what does the Makefile have around line 436?
Sounds like MakeMaker is generating a Makefile for the wrong flavour of
make, to me. Is u:\extras\bin\make the make Paul used to build perl?
(Are there any makes for OS/2 which aren't gmake?)
Ben
------------------------------
Date: Thu, 08 Dec 2011 18:12:17 -0800
From: Dave Yeo <dave.r.yeo@gmail.com>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <4ee16e82$0$2257$c3e8da3$38634283@news.astraweb.com>
Ben Morrow wrote:
> (Are there any makes for OS/2 which aren't gmake?)
Not that are named make, and pretty well everyone is using 3.81
Dave
------------------------------
Date: Fri, 09 Dec 2011 12:10:44 +0000
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: simple xml - change tag name
Message-Id: <4ee1fab4$0$2966$fa0fcedb@news.zen.co.uk>
On 06/12/2011 14:42, Ben Morrow wrote:
>
> Quoth Henry Law<news@lawshouse.org>:
>> On 06/12/11 11:24, Krzysztof Poc wrote:
>>
>> One significant point about XML is that its textual format doesn't
>> matter, at least not in every respect. For example:
>>
>> <sometag foo="bar" bar="blatz">
>> <anothertag/>
>> </sometag>
>>
>> is in XML terms exactly equivalent to
>>
>> <sometag bar="blatz" foo="bar"><anothertag></anothertag></sometag>
>
> No it isn't. Whitespace within an element is part of the character data
> for that element (after newline normalisation).
>
Henry was wrong about that†, but his general point is valid.
<dog:foo xmlns:dog='http://example.com/1'
xmlns:cat='http://example.com/2'>
<dog:bar>
<cat:mint>12 9</cat:mint>
</dog:bar>
<dog:baz></dog:baz>
</dog:foo>
Is canonically equivalent to
<foo xmlns="http://example.com/1">
<bar>
<horse:mint xmlns:horse="http://example.com/2">12 9</horse:mint>
</bar>
<baz />
</foo>
E&OE
So people writing XML, probably need to understand the rather
complicated rules in XML for deciding whether two XML documents are the
same.
†I don't really understand what is the benefit of preserving white-space
in elements that are *not* leaf elements. But that's the way XML is.
--
RGB
------------------------------
Date: Fri, 09 Dec 2011 12:48:04 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: simple xml - change tag name
Message-Id: <nY2dnSCKSo8Znn_TnZ2dnUVZ8uadnZ2d@giganews.com>
On 09/12/11 12:10, RedGrittyBrick wrote:
>
> Henry was wrong about that†, but his general point is valid.
>
Indeed I was wrong but this post explained the thinking that was in my
mind, which isn't wrong: that textual equivalence is not _usually_
necessary for XML documents to be judged "the same" by the program that
is processing them, and is therefore not often something that authors of
XML tools strive for.
--
Henry Law Manchester, England
------------------------------
Date: Fri, 9 Dec 2011 13:25:16 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: simple xml - change tag name
Message-Id: <slrnje431s.1qh8.willem@toad.stack.nl>
RedGrittyBrick wrote:
) So people writing XML, probably need to understand the rather
) complicated rules in XML for deciding whether two XML documents are the
) same.
)
)
) ???I don't really understand what is the benefit of preserving white-space
) in elements that are *not* leaf elements. But that's the way XML is.
That's because XML is a markup language, not a data language.
It just got overhyped and is now being used for all sorts of things it was
never designed for. Which, in itself, is the basis for plenty of rants.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 8 Dec 2011 22:05:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <3uo7r8-1si.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ivan Shmakov <oneingray@gmail.com> writes:
> > I wonder, what's the (time-)efficient way to an octet string,
> > for "ASCII safety"?
> >
> > The string is a POSIX filename, and POSIX is known to allow for
> > arbitrary octet sequences (except those with ASCII NUL codes)
> > for filenames. The tool I'm developing would store such
> > filenames in an encoding-agnostic way (i. e., as BLOB's), unless
> > it's certain that those are "safe ASCII."
> >
> > The check I've used in [1] is like:
> >
> > ## count the "unsafe" octets (outside of the [32, 126] range)
> > my $unsafe
> > = grep { $_ < 32 || $_ > 126 } (unpack ("C*", $filename));
> >
> > but I'm curious if there's a way better than unpacking the octet
> > sequence into a vector (Perl list)?
>
> Assuming that ASCII is taken for granted, an obvious other idea would
> be
>
> $filename =~ /[\x0-\x20\x7f-\xff]/
$filename !~ /[^[:ascii:]]/
is clearer, and works properly against Unicode strings.
> This will probably also need a 'use bytes'.
'use bytes' is always wrong. It seemed like a reasonable idea when it
was invented, but in fact it always causes more problems that it solves.
In particular, it allows internal implementation details to leak out
that really shouldn't. (I suspect, but I don't have a concrete example,
that it's possible to crash perl using 'bytes'.)
5.14 has some new regex flags, /aul, and some new pragmata, for handling
situations where 'bytes' seems to be the right answer safely.
Ben
------------------------------
Date: Thu, 8 Dec 2011 22:21:14 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <qrp7r8-qjj.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>
> BTW, does POSIX limit file names to ASCII, or are, e.g., ISO-8859-1
> accented letters, allowed?
As far as POSIX is concerned filenames are just sequences of bytes. The
only bytes which are special are '\0', which is forbidden, and '/',
which is the directory separator. All other bytes are uninterpreted, so
you can use ISO8859-1 or UTF-8 or any other ASCII-compatible encoding
you like. (You obviously can't use things like UTF-16, because they
contain embedded nuls, or EBCDIC, because it puts / in the wrong place.)
The traditional Unix approach to the problem, where it hasn't been
ignored completely (the likes of ls, for instance, tend to just throw
the bytes in the filename at the terminal without thinking), is to use
the user's locale settings to determine the character set in use. Since
this is obviously a nightmare on a multi-user system, there is a move
(at least among the free Unixes, I don't know about the others) towards
standardising on always using UTF-8 for filenames regardless of the
user's locale.
Perl currently makes no attempt to help you with any of this. The bytes
you pass to perl's open() get passed to the OS's open(2) unmodified, so
if you're constructing non-ASCII filenames you need to know what
conventions are in use on your system and encode the strings yourself.
There have been conversations on p5p from time to time about possibly
being more helpful, but the problem is sufficiently intractable that
they haven't yet got anywhere (AFAIK).
So, in other words, your typical Unix mess :).
Ben
------------------------------
Date: Thu, 08 Dec 2011 22:41:50 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <874nxavg7l.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ivan Shmakov <oneingray@gmail.com> writes:
>> > I wonder, what's the (time-)efficient way to an octet string,
>> > for "ASCII safety"?
>> >
>> > The string is a POSIX filename, and POSIX is known to allow for
>> > arbitrary octet sequences (except those with ASCII NUL codes)
>> > for filenames. The tool I'm developing would store such
>> > filenames in an encoding-agnostic way (i. e., as BLOB's), unless
>> > it's certain that those are "safe ASCII."
>> >
>> > The check I've used in [1] is like:
>> >
>> > ## count the "unsafe" octets (outside of the [32, 126] range)
>> > my $unsafe
>> > = grep { $_ < 32 || $_ > 126 } (unpack ("C*", $filename));
>> >
>> > but I'm curious if there's a way better than unpacking the octet
>> > sequence into a vector (Perl list)?
>>
>> Assuming that ASCII is taken for granted, an obvious other idea would
>> be
>>
>> $filename =~ /[\x0-\x20\x7f-\xff]/
>
> $filename !~ /[^[:ascii:]]/
>
> is clearer, and works properly against Unicode strings.
Additionally, it doesn't work (in the sense that it would solve the
problem). This includes that it is not supposed to 'work properly
against unicode strings' aka 'let non-printable octets slip through if
they happen to be part of utf8 multibyte characters'.
[rw@error]~ $perl -e 'print " " =~ /[[:ascii:]]/, "\n"'
1
[rw@error]~ $perl -e 'print "\x1" =~ /[[:ascii:]]/, "\n"'
1
[rw@error]~ $perl -e 'print "\x7f" =~ /[[:ascii:]]/, "\n"'
1
A simpler way to test wheter a string contains 'non-printable octets'
would be
$filename =~ /[^[:print:]]/
except -- unfortunately space and htab (0x20 and 9) are printable (I
don't quite understand why space is considered to be a 'safe'
character while \t is not, hence I assumed that ' ' was also supposed
to be excluded).
>> This will probably also need a 'use bytes'.
>
> 'use bytes' is always wrong.
A statement of the form 'xxx is always wrong' is always wrong when
referring to some kind of existing feature. The 'use bytes'
documentation states
When "use bytes" is in effect [...] each string is treated as
a series of bytes
Since the OP was looking for 'ASCII safety of an octet string',
treating a string as 'series of bytes' seems to be exactly what is
necessary for that. So, what's the problem with that (and, just out of
curiosity who believes this documented Perl feature should not be used
for what technical reasons which are applicable to actual problems?).
I admit that I'm so far rather convinced that 'not using use bytes' is
'always wrong' for the problems I have to deal with (which usually
invovle strings of bytes and not 'characters' as arbitrarily defined,
redefined and undefined by some US committee).
------------------------------
Date: Thu, 8 Dec 2011 23:33:26 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <63u7r8-ajk.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > $filename !~ /[^[:ascii:]]/
> >
> > is clearer, and works properly against Unicode strings.
>
> Additionally, it doesn't work (in the sense that it would solve the
> problem).
<snip>
> A simpler way to test wheter a string contains 'non-printable octets'
> would be
>
> $filename =~ /[^[:print:]]/
You're right.
> except -- unfortunately space and htab (0x20 and 9) are printable (I
> don't quite understand why space is considered to be a 'safe'
> character while \t is not, hence I assumed that ' ' was also supposed
> to be excluded).
Space is an ordinary single-width character like any other, it just
happens not to have any ink in its glyph. Tab is a control character
that (typically) produces a context-dependant amount of whitespace.
For example, an app that wanted to know whether it was safe to assume 1
column per byte would treat space like 'A', but not tab.
> >> This will probably also need a 'use bytes'.
> >
> > 'use bytes' is always wrong.
>
> A statement of the form 'xxx is always wrong' is always wrong when
> referring to some kind of existing feature. The 'use bytes'
> documentation states
>
> When "use bytes" is in effect [...] each string is treated as
> a series of bytes
Yes, I know that. The general opinion among those who actually know how
these things work (which doesn't include me) is that both the design and
the implementation are buggy, and the pragma needs to be deprecated and
then removed. I'm not making these things up, I'm simply relaying the
opinion of those perl developers who are actively working on perl's
Unicode implementation.
> Since the OP was looking for 'ASCII safety of an octet string',
> treating a string as 'series of bytes' seems to be exactly what is
> necessary for that. So, what's the problem with that (and, just out of
> curiosity who believes this documented Perl feature should not be used
> for what technical reasons which are applicable to actual problems?).
Go find the relevant p5p threads if you want examples. There are quite a
few of them, as I recall...
> I admit that I'm so far rather convinced that 'not using use bytes' is
> 'always wrong' for the problems I have to deal with (which usually
> invovle strings of bytes and not 'characters' as arbitrarily defined,
> redefined and undefined by some US committee).
I was inclined to think the same thing, until I learned that it's not
that simple and, while 'use bytes' seems like an attractive idea, it
doesn't appear to be possible to make it work properly. Again, this is
not my assertion, and I don't pretend to fully understand the details,
but those who do say it's fundamentally broken and I see no reason to
doubt them.
Insofar as regexes are concerned, 5.14's /a is an acceptable substitute.
If and when 5.14 becomes something one can rely on, I will probably add
use re "/aa";
to my
use warnings;
use strict;
use autodie;
start-a-perl-file mantra.
Ben
------------------------------
Date: Thu, 08 Dec 2011 17:42:55 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <8kp2e7939urcdjqslm5ig1onnh13uispqc@4ax.com>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <874nxbt8tf.fsf@sapphire.mobileactivedefense.com>, on 12/08/2011
> at 02:52 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>
>>Assuming that ASCII is taken for granted, an obvious other idea would
>>be
>
>> $filename =~ /[\x0-\x20\x7f-\xff]/
>
>Space is valid in file names.
>
> $filename =~ /[\x0-\x1f\x7f-\xff]/
>
>BTW, does POSIX limit file names to ASCII, or are, e.g., ISO-8859-1
>accented letters, allowed?
AFAIK (and I may be wrong) POSIX supports any Unicode file name.
Therefore the OPs approach to look at isolated octets is a sure way to
ask for trouble.
jue
------------------------------
Date: Fri, 9 Dec 2011 02:35:58 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ways to check for octets outside of the safe ASCII range?
Message-Id: <ep88r8-1mm.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> >In <874nxbt8tf.fsf@sapphire.mobileactivedefense.com>, on 12/08/2011
> > at 02:52 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
> >
> >>Assuming that ASCII is taken for granted, an obvious other idea would
> >>be
> >
> >> $filename =~ /[\x0-\x20\x7f-\xff]/
> >
> >Space is valid in file names.
> >
> > $filename =~ /[\x0-\x1f\x7f-\xff]/
> >
> >BTW, does POSIX limit file names to ASCII, or are, e.g., ISO-8859-1
> >accented letters, allowed?
>
> AFAIK (and I may be wrong) POSIX supports any Unicode file name.
> Therefore the OPs approach to look at isolated octets is a sure way to
> ask for trouble.
This is not the case: see my response xthread. AFA*I*K POSIX makes no
reference to Unicode whatever. (Indeed, POSIX.1 was first published in
1988, whereas the first part of the first Unicode standard wasn't
published until 1991 (though there was a draft of ISO 10646 in 1990).)
More importantly (at least for this group), attempting to use a string
with characters > 255 as a filename in Perl is asking for trouble, at
least with current versions.
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 3562
***************************************
