Re: Assistance fixing a "format" call

When I first saw this format thing, I thought oh, how cool. After some experience with it, I have changed my mind! The old standby printf just works out better in practice, at least for me. My advice would be to get rid of that "format" stuff.

#!/usr/bin/perl -w
use strict;

while (<DATA>)
{
   my @tokens = split ' ', $_;
   
   printf "%-10s %-10s %-10s %-10s %-10s\n", @tokens;
}

=prints
TECH       SCANNER    WEBSERVER  TALKTOME   TRAINING  
TESTING    MOBILE     TECHADMIN  CIRCADMIN  MANAGERS  
=cut


__DATA__
TECH SCANNER WEBSERVER TALKTOME TRAINING
TESTING MOBILE TECHADMIN CIRCADMIN MANAGERS
[download]

Update: also with standard printf in Perl (or even C), you can dynamically generate the "format spec" - should that be necessary and its almost never necessary.

while (<DATA>)
{
   my @tokens = split ' ', $_;
   my $format = '%-10s ' x @tokens;
   printf "$format\n", @tokens;
}
[download]

It is important to realize that with "format spec width" like %-10s specifies the minimum width. If the string is longer than that it will still be printed although the columns for that line won't line up. This almost always what you want - one goofy looking line in a 200 line report. The trailing space after the %-10s ensures that there will at least one blank space between columns and that is almost always what is desired. Extremely rigid, fixed field, "card punch image" formats are very rare nowadays. Adjust the column widths so that they work "almost all of the time" - when the outlier line comes along, humans are very good at integrating and seeing past that single line.

If you absolutely insist upon using a "format" despite my recommendation to the contrary, put the definition outside of the while() loop.

Comment on Re: Assistance fixing a "format" call Select or Download Code

Replies are listed 'Best First'.
Re^2: Assistance fixing a "format" call by bobdabuilda (Beadle) on Apr 02, 2012 at 03:18 UTC
Hmmm thanks for that Marshall. I had had a look at `printf`, but by that point I'd already gone down the `format` path as it was the first recommendation I'd received - and it seemed to work fine for me first up. I should certainly be able to modify some `printf` calls to get the output I'm after. Just need it to look all purdy on-screen so the user can browse the data relatively easily to pick out the one they're after. Edit: modified my code while I was drafting up this response, and it does indeed do what I'm after, so thanks again for that. Having said that... I'd still love to know why it is that what I'm using at present isn't working as expected. I'm sure it must be something fundamental I'm doing wrong - but it would be nice to know for future reference (if not only for myself, but others that might be looking at doing similar) what it is. It's certainly been rather frustrating to try and work it out ;)	[reply] [d/l] [select]
Re^3: Assistance fixing a "format" call by Marshall (Canon) on Apr 02, 2012 at 03:23 UTC
well one possibility is that "write" writes to the currently selected filehandle. Try "write STDOUT;" But since you say that you are getting at least some kind of line, the leading spaces in the 2nd format statement may also be an issue - this is a finicky critter - one reason why I don't recommend it. The first answer on Monks is not always the "best answer" - and I would include myself in that general statement also!. In the future, I think you will wind up being much happier with printf(). Anyway, the difference that I see is this: (2nd format does not start in column 1). `format STDOUT = @<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<< +<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<< @row . not the same as: format STDOUT = @<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<< +<<<<<<< @rows .` [download] Update: After looking at the doc's, the "." - to end the format - has to be in column 1. It doesn't say that the format itself must start in column 1, but at the moment I am at a loss for any other ideas. The two statements appear to be so similar that that's the only thing I can think of at the moment. I did look at what it will do if "the data doesn't fit" and you get #'s in that field. This is almost always not what is desired. I wrote a recent post at printf exact field width of floating point number that talks about using sprintf() to decide how wide a field will actually be printed and how to use a different format spec in printf() if it "doesn't fit" within a fixed number of characters (in this case using %g instead of %f). This is extremely rare. (update: I liked BrowserUK's answer in that thread also, if you give %g "enough room to work", it will do a "good job"). All of which will be better than the "format" idea for numeric values. For strings, this whole idea of how to display the decimal number is mute. For strings, the issue is whether you are going to truncate the string or allow the columns for that line to "go astray" if the value doesn't "fit". In general printing "something" is better than printing "nothing or just #'s". But almost always, print the data to the precision needed and if some weird line doesn't line up, then so be it. Always add an explicit space between format specifications to ensure at least one blank space between values. In summary, this "format" idea was a good one, but it doesn't work out well in practice.	[reply] [d/l]