develooper Front page | perl.perl5.porters | Postings from January 2012

Re: pack and ASCII

Thread Previous | Thread Next
Jesse Luehrs
January 13, 2012 13:05
Re: pack and ASCII
Message ID:
On Fri, Jan 13, 2012 at 02:14:35PM -0500, Eric Brine wrote:
> On Fri, Jan 13, 2012 at 8:30 AM, John P. Linderman (jpl) <
>> wrote:
> > **
> > Some of the "magic" is gone if it is necessary to explicitly encode before
> > packing and decode after unpacking.  It's too late to have "A20" do what I
> > meant, but we can make it relatively painless if there is a "pack pragma"
> > (or something similar) that turns on that behavior without having to
> > (otherwise) modify programs.  "That behavior", just to be clear, means
> > interpreting the number following "A" (or "a") as the number of octets that
> > will be stored, with "pack" utf-encoding the data prior to padding, and
> > "unpack" utf-decoding the octets after stripping off the padding.  (What to
> > do if it is necessary to truncate the encoded octets needs thought.
> > Truncate at the previous character boundary and pad?  Warn?)
> >
> That could possibly be done using a pattern modifier (e.g. C<< pack("A!20",
> $text) >>) instead of a pragma.
> It might be useful for pack to modify the argument such that it holds any
> text that didn't fit.
> > Although it is now irrelevant, I'm having trouble thinking of where the
> > current behavior is useful.  Why would one want to pad to a specified
> > character (not octet) length?  -- jpl
> >
> C<< pack "a20", $bytes >> is useful for creating C structs and fixed-length
> records.
> C<< pack "A20", $text >> is useful for formatting text for display, such as
> C<ls>'s default multi-column display,

Why would you not just use sprintf("%-20s", $text) here? Making pack
more difficult to use in order to reproduce already existing behavior
doesn't seem to be incredibly helpful.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About