script to center text
Edward John Sabol
like to be able to pipe a file or region into it and get out the same
text only centered in 80 columns.
It shouldn't be hard to do, but I don't know awk or perl very well. I
can do it in C, of course, but I want a script for ease of portability
and the smaller size. Speed needn't be an issue.
Thanks.
Tom Christiansen
:Could someone post a awk, perl, or sed script which can center text. I'd
This should do it for you:
perl -pe 'print " " x int((81 - length())/2)'
Beware tabs: convert them with expand, or do it yourself:
perl -pe '1 while s/\t+/" " x (length($&) * 8 - length($`) % 8)/e;
print " " x int((81 - length())/2)'
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
I want to be Robin to Bush's Batman. --Vice President Dan Quayle
Josef Moellers
The following is a bourne shell script that does it, followed by a Korn
shell script (caveat: both can't handle backslashes!):
-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-
#!/bin/sh
while read line
do len=`expr "$line" : '.*'`
prefix=`expr \( 80 - $len \) / 2`
while [ $prefix -ge 8 ]
do echo '\t\c'
prefix=`expr $prefix - 8`
done
while [ $prefix -ge 0 ]
do echo ' \c'
prefix=`expr $prefix - 1`
done
echo $line
done
-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-ksh-
#!/usr/bin/ksh
while read line
do len=`expr "$line" : '.*'`
let prefix=\(80-$len\)/2
while [ $prefix -ge 8 ]
do echo '\t\c'
let prefix=$prefix-8
done
while [ $prefix -ge 0 ]
do echo ' \c'
let prefix=$prefix-1
done
echo $line
done
-end-end-end-end-end-end-end-end-end-end-end-end-end-end-end-end-end-end-
--
| Josef Moellers | c/o Siemens Nixdorf Informationssysteme AG |
| USA: molle...@sni-usa.com | Abt. STO-XS 113 | Riemekestrasse |
| !USA: molle...@sni.de | Phone: (+49) 5251 835124 | D-4790 Paderborn |
Tom Christiansen
:In <AeRB8p600...@andrew.cmu.edu> es...@andrew.cmu.edu (Edward John Sabol) writes:
:>Could someone post a awk, perl, or sed script which can center text. I'd
:>like to be able to pipe a file or region into it and get out the same
:>text only centered in 80 columns.
:
:>It shouldn't be hard to do, but I don't know awk or perl very well. I
:>can do it in C, of course, but I want a script for ease of portability
:>and the smaller size. Speed needn't be an issue.
:
:The following is a bourne shell script that does it, followed by a Korn
:shell script (caveat: both can't handle backslashes!):
In my techojargon brand of English, "both can't" is not the same
as "neither can". This is "both can't":
if (!a || !b)
Meaning it's true if EITHER A OR B OR BOTH CANNOT.
whereas this is "neither can":
if (!(a && b))
Meaning is true only if neither A nor B can do something.
I realize that the poster is not a native speaker of English.
Perhaps these are equivalent in German. Perhaps I'm no longer
a native speaker of English. :-)
:-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-sh-
:#!/bin/sh
:while read line
:do len=`expr "$line" : '.*'`
: prefix=`expr \( 80 - $len \) / 2`
: while [ $prefix -ge 8 ]
: do echo '\t\c'
: prefix=`expr $prefix - 8`
: done
: while [ $prefix -ge 0 ]
: do echo ' \c'
: prefix=`expr $prefix - 1`
: done
: echo $line
:done
[ksh solution omitted]
I think we have another candidate for the annual Dead Parrot Society award;
you know, those lethargic programs that remind you of the Monty Python skit.
Yes, folks, the Efficiency Cops are back!
Consider, if you would, the following file:
$ wc /etc/motd
74 404 4119 /etc/motd
First off, here are some timings:
A modestly sized file, I might add.
$ time sh ctr.sh </etc/motd > /dev/null
non-numeric argument
test: argument expected
test: argument expected
16.377u 76.475s 0:55.71 50.0% 0+0k 0+19io 12275pf+0w
Well, maybe we're from the Correctness Cops, too. Let's look at
the first line of /etc/motd:
$ sed 1q /etc/motd
* Fri Aug 16 19:13:53 CDT 1991:
Let's just run the program on that line:
$ sed 1q /etc/motd | sh ctr.sh
\t\c
\t\c
\t\c
\c
ftpget ftplib.pl ftpls getdate n0 n1 n2 n3 n4 n5 n6 n7 n8 n9 statmon tree Fri Aug 16 19:13:53 CDT 1991:
Oh my. That's wrong twice. First of all, you can't rely on echo
doing backslash evalutation. (From my perpective, the SysV crew
screwed up for trying to make it such. They should have invented
another command, like print, to do that.) Second of all, some place
in there you're the shell take a swipe and globbing your raw data.
While both these problems can be solved by enough quoting and mucking with
the echo args enough, you still have the problem of it running much as a
dead parrot flies. Actually, I took a shot at fixing it, and kept
getting whinage like this,
non-numeric argument
test: argument expected
which just goes to show you that it's easier to port a shell
than a shell script. :-(
On the other hand, this solution
perl -pe 'print " " x int((80 - length())/2)'
not rely on echo behavior, isn't a process pig, and doesn't
run afoul of my /bin/test command. It also runs a tad faster:
$ time perl -pe 'print " " x int((80 - length())/2)' </etc/motd >/dev/null
0.030u 0.052s 0:00.05 50.0% 0+0k 0+5io 48pf+0w
where we'll define a tad as some 1,132 times faster on this dataset.
It also inflicts some 256 fewer page faults on the flogged system.
'Nuff said.
Please direct followups appropriately:
TOPIC NEWSGROUP
shell programming comp.unix.shell
(and maybe alt.sources.d)
"both can't" alt.usage.english
(and maybe alt.folklore.computers)
the evils of perl alt.religion.computers
(and maybe alt.flame)
--tom
--
Uma Krishnan
database to the workstation. The data is stored in the workstation
and indexed (using hash and btree). The user can them apply his/her
selection criteria (that includes soundex) to fetch a subset of the
data.
So what I need is an ability to parse the SQL like select criteriai
and fetch rows based on the select criteria, sort the data based on
user defined sort criteria and store the data and build indices
on the data (using hash and btree)
I would prefer this to be in C.
Could you pl. mail me directly - If there is an interest in the
net, then I will test it (if untested) and post it.
Thanks a million in advance
Uma Krishnan
Tom Christiansen
:In my techojargon brand of English, "both can't" is not the same
:as "neither can". This is "both can't":
:
: if (!a || !b)
:
:Meaning it's true if EITHER A OR B OR BOTH CANNOT.
:
:whereas this is "neither can":
:
: if (!(a && b))
That should have been
if (!a && !b)
:Meaning is true only if neither A nor B can do something.
:
:I realize that the poster is not a native speaker of English.
:Perhaps these are equivalent in German. Perhaps I'm no longer
:a native speaker of English. :-)
For clarity, since I think I may have screwed of my Boolean logic:
to me, "both cannot" doesn't disallow one from being able to,
and thus is different from "neither can", which guarantees that
neither A nor B is able to.
Both can't not a or not b
Neither can not a and not b
And no, I don't use English "or" as an inclusive or (a | b).
I realize it's an exclusive one in normal speech (a ^ b).
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
Verbosity leads to unclear, inarticulate things. -- Dan Quayle
Bill Duncan
Use "C" for the very reasons you note. Portability, because "C" is available
on more platforms (like MessyDOS for example), also because you should be
using the COLS environment value, not a hardwired constant like "80".
(Note, although perl, awk, and sed may be available on as almost as many
platforms, it may not be available on as many "systems". Besides, they
would normally require a "C" compiler to port them, which means that it's
already available.)
And smaller size goes without saying. Perl and awk are big interpreters,
whereas a program compiled in "C" would be very small for this job.
So do it in "C", it *is* the right tool for this job.
Tom Christiansen
Oh, I think not. If we go writing every single little text-munging tool
in C, we're certainly going to a lot of work for very little return.
Porting C programs is in general harder than porting Perl programs.
I will grant that in this case, you can write the C program sufficiently
portably that this shouldn't be an issue.
But for size and convenience, Perl clearly wins over C.
You really have to compare the size of the perl program with the size of
the C program. If you want to compare the size of the perl compiler and
interpreter, then do so with the C compiler and libraries. Otherwise
you're comparing apples with horsechestnuts.
A complete program has source, executable, and documentation. I can
guarantee you that the C program will be bigger than the Perl one. And
with Perl, you don't need to recompile and install a new a.out every time
you want to run your little text-munging program. It's easy for source,
executable, and man page to get out of sync with a C program, but with
Perl programs, it's all self-contained within one file. You can't
misplace the source or the man page, 'cause they're always right there.
I don't really care whether you use sed, awk, or perl here, although I
personally find this:
perl -pe 'print " " x int((80 - length())/2)'
to be easiest; sed would be a little trickier, although awk wouldn't
be too terribly bad.
But don't go hack out some C program every time you have such a simply
task, or bend over backwards trying to get the shell to do this faster
than a line per second. It's precisely this kind of thing that sed, awk,
and perl were invented for.
So do it in one of them. They *are* the right tool for this job.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
As far as we know, our computer has never had an undetected error.
-- Weisert
Bill Duncan
>Oh, I think not. If we go writing every single little text-munging tool
>in C, we're certainly going to a lot of work for very little return.
>Porting C programs is in general harder than porting Perl programs.
>I will grant that in this case, you can write the C program sufficiently
>portably that this shouldn't be an issue.
Precisely my point. I was not even remotely suggesting writing "every text-
munging tool in C. But this was such a trivial thing, that a half dozen lines
of "C" code should suffice. Far less than all the wind and energy we've
expended on this! ;-)
I am a strong believer in using the appropraite tools for any job. It IS my
job, as I'm a hired gun. I also strongly believe in the "philosophy" of
using existing tools where you can, and that "small is beautiful".
(Beauty not being defined today in terms of cycles or bytes saved, because
that has become less important. But small in terms of elegance and most of
all maintainability. I have found in my years of consulting, that anything
which has a case of the bloats, has a deeper problem in terms of maintenance.)
Therefore, I will use awk, sed, sh, m4, and whatever other tools I have
available which are appropriate to the task at hand. But I will resist
using sledge hammers like ADA, PL/1, and yes Perl; especially when all that
is called for is a jeweller's screwdriver.
I fear that I will probably start a "religious war" here, but I have to say
it anyway. My personal view is that Perl has the "feel" of a language
designed by committee, throwing everything but the kitchen sink in and then
some; and has the consistency and elegance of an elephant on drugs. And
I wish somebody would start a new sources newsgroup just for Perl, (and
get rid of it in the standard places).
>But for size and convenience, Perl clearly wins over C.
All I can say is fubar! It's the antithesis of whatever you might have
learned in "The Unix Programming Environment" by K & P. (You have read
it?) Granted it is a bit outdated now, but the philosophy shouldn't be.
Use awk for a quickies and prototyping if a 6 line "C" program bothers you.
>You really have to compare the size of the perl program with the size of
>the C program. If you want to compare the size of the perl compiler and
>interpreter, then do so with the C compiler and libraries. Otherwise
>you're comparing apples with horsechestnuts.
Horse-Feathers!! This is ridiculous! We were talking about a one line
Perl script, or awk, or maybe a half dozen lines of "C" weren't we?
If you wanna get "nutty" on me, then let's try factoring in the box of
disks I'd have to cart around with me to new client sites, because I'd
never know whether they had Perl. Let's try factoring in the "porting"
time I'd have to do just to get this humoungous tool going, so I could
*begin* to write that silly Perl one-liner.
No thank you very much. My "black bag" has alot of "C", sed, and awk
scripts, programs, and libraries which I've found or developed over the
years. And I can be "up and running" solving problems I'm being paid for
much faster than any Perlies. (Perlites?) I can count on the other tools
I need already being on the clients' machine.
>A complete program has source, executable, and documentation. I can
>guarantee you that the C program will be bigger than the Perl one. And
>with Perl, you don't need to recompile and install a new a.out every time
>you want to run your little text-munging program. It's easy for source,
>executable, and man page to get out of sync with a C program, but with
>Perl programs, it's all self-contained within one file. You can't
>misplace the source or the man page, 'cause they're always right there.
I still thought we were talking about a one-liner... Have you sworn off
"C" completely? You seem to be arguing for it. I wasn't ever suggesting
doing "everything" in "C", but you seem to be arguing that everyone should
use interpreters, all the time. Hmmm. You don't mention "which" programs,
so I think you leave yourself wide open to eat crow.. :-0
>I don't really care whether you use sed, awk, or perl here, although I
>personally find this:
>
> perl -pe 'print " " x int((80 - length())/2)'
>
>to be easiest; sed would be a little trickier, although awk wouldn't
>be too terribly bad.
>
>But don't go hack out some C program every time you have such a simply
>task, or bend over backwards trying to get the shell to do this faster
>than a line per second. It's precisely this kind of thing that sed, awk,
>and perl were invented for.
>
>So do it in one of them. They *are* the right tool for this job.
>
>--tom
>--
> Tom Christiansen tch...@convex.com convex!tchrist
>
> As far as we know, our computer has never had an undetected error.
> -- Weisert
Well, like I've said, use the appropriate tool. The trouble with many Perlites
is that they get myopic and feel everything should be done in their pet
language. I've been programming in "C" for over 10 years now on many different
platforms; and although it's still the language of choice for many things, you
need to weigh development and maintenance costs (just as you suggest), along
with how it will be used, how often etc.
On the last project I was on I wrote well over 1000 lines of awk code. After
weighing alternatives, it was the best choice. (It was *serious* text-munging,
but would only be used very rarely. It worked very well, and the equivalent in
"C" could easily have been 10x more code. In this case "C" would not have been
the right tool. If they were using it constantly, then maybe.)
Back to the poor chap who asked the question... I agree that awk would be easy
and sed would be more difficult. And if there was any "serious" text-munging
then I would certainly use awk. But the "C" code was so trivial, why not??
Just to show you that "C" isn't scary, I spent a few minutes to draft one up.
It's more than the half dozen lines which I'd estimated, but it does a check
for the COLS environment variable, and does error checking which yours didn't.
("Creaping Featurism", what can I say? ;-)
--------------8<------------------------------------
/* centre.c - centre a string to stdout
**
** - only works in Canada, US residents must use "center.c" ;-)
** - uses COLS variable if set
*/
#include <stdio.h>
#define COLS 80
main(ac,av)
int ac;
char *av[];
{
int cols = atoi(getenv("COLS"));
if (ac < 2) exit(1);
if (!cols) cols=COLS; /* default */
cols = (cols - strlen(av[1])) / 2;
if (cols > 1)
while (cols--) putchar(' ');
puts(av[1]);
return 0;
}
--------------8<------------------------------------
Bill Duncan (bdu...@ve3ied.UUCP -or- robohack!ve3ied!bduncan)
Graham Stoney
>gre...@research.canon.oz.au (Graham Stoney) writes:
>>
>>Bill, perhaps you have a different definition of "size" to most of us?.
>>
>Yes. He may be thinking about resource usage by the process not by how
>many lines of source make up the program. How big is the Perl interpreter?
This was already covered earlier in the thread; It was Tom who brought up the
topic of size, and he was quite clearly referring to program size:
Tom Christiansen <tch...@convex.COM> writes:
>But for size and convenience, Perl clearly wins over C.
>You really have to compare the size of the perl program with the size of
>the C program.
You may think otherwise if you wish, but the Perl program will still have a
smaller size than the C program.
Graham
--
Graham Stoney | "a Perl script is correct if it's halfway
Flip Dibner fan club, "Hi Flip!" | readable and gets the job done before your
Ph: +61 2 805-2909 Fax: -2929 | boss fires you." L. Wall & R. Schwartz
Graham Stoney
>In article <1992Aug5.1...@news.eng.convex.com> tch...@convex.COM (Tom Christiansen) writes:
>>But for size and convenience, Perl clearly wins over C.
>All I can say is fubar!
Bill, perhaps you have a different definition of "size" to most of us?.
Tom presents his perl 1 liner:
>> perl -pe 'print " " x int((80 - length())/2)'
And you go on with your 27 line C solution; admittedly it does check
COLS, but the perl equivalent is still 1 line.
> Let's try factoring in the "porting"
>time I'd have to do just to get this humoungous tool going, so I could
>*begin* to write that silly Perl one-liner.
Your point about convenience is valid if perl isn't already installed
on the system in question, but this is becoming less of an issue
all the time. As for "porting" perl; well, that's pretty comical to
anyone that's ever actually installed it.
>Well, like I've said, use the appropriate tool. The trouble with many Perlites
>is that they get myopic and feel everything should be done in their pet
>language.
Which is equally myopic as yourself; you're just at the other end of the
spectrum, believing that Perl is _never_ the appropriate tool. That's no
better; just different. The optimum is somewhere in between.
Regards,
Tom Grydeland
|>
|> Tom Christiansen <tch...@convex.COM> writes:
|> >But for size and convenience, Perl clearly wins over C.
|> >You really have to compare the size of the perl program with the size of
|> >the C program.
|> You may think otherwise if you wish, but the Perl program will still have a
|> smaller size than the C program.
I think another issue here is user-friendliness:
The perl one-liner will traverse all files given as arguments
and print them centered on stdout.
The C program will take the one string given as argument (i.e. if more
than one word, you'll have to quote the string yourself) and center it.
Any file i/o is left as an exercise to the reader.
As for the COLS variable, It'll take a few more characters to include that
in the perl one-liner,
perl -pe 'print " " x int(($ENV{'COLS'} - length())/2)'
Which will still be my preferred tool for this problem (in fact, I've
already used a variant of it in a script I'm working on (Thanks, Tom!))
|> Graham Stoney | "a Perl script is correct if it's halfway
--
//Tom Grydeland(to...@stud.cs.uit.no)._._._._._._._._._._._._._._._._._._._._._
|A._| . . ._| | |_._._. . ._|_._._._._. ._|_. ._ _._. ._| | . ._|_. | . ._._. |
| ._|_| |_. | | | | ._._|_. |_._. . |_. | | | ._._| |_._._._| | ._. ._| . . |_|
|_._._._._|_._._._._._._|_._._._._|_._._._._._._._._._._._._|_._._|_|_._|_|_.B|
Bill Duncan
Unfortunately, it seems my feed has been eating parts of this thread, as I've
missed some of these comments.
My "idea of size" is *also* weighed against the time to develop/write/maintain
a piece of code. If you are going to write a one liner and then forget it,
then by all means, use whatever means at your disposal and that you feel
comfortable with.
But as I've said in my earlier posting: don't forget that we *are* talking
about centering a single line of text, which is relatively trivial in almost
any language. (Well, there are exceptions.. ;-)
What I am getting at, is some of the fundamental design philosophy as
embodied in several books by people who were closely tied with the design
of Unix itself. Keep the tools simple, do one thing well, and design with
re-usability in mind.
Using a several hundred kilobyte program to centre a single line of text,
seems like a bit of an overkill to me. And it sounds like it comes from
people who grew up in the "me-too" generation, with complete disregard as
to what their actions might do to other users on the system. (If they
need this big a sledge hammer to centre a line of text, what will they
need when they come across a "real-problem"?)
My simple program (which as someone pointed out, grew to over 20 lines),
probably took less energy to write, (and fewer lines), than many of
the responses defending Perl for this. My program compiles to 6K.
(Yes, that was Six Kilobytes.) I know that re-using this simple utility
will never be a drain on any system, and would feel a bit more comfortable
including this in any shell scripts I might do.
I also use any of the standard tools which can be found on most Unix systems
whenever "they" are appropriate. If I was going to do something like this
once, and then never again need it, then I might use something like Perl
if I was in a hurry. (I might even write it as a shell function.)
If I had a few extra minutes to think about it though, I might want to re-use
it and write the 20 odd lines which I did. It might come in handy again
sometime.
Regards,
Bill Duncan (bdu...@ve3ied.UUCP -or- ..robohack!ve3ied!bduncan)
Bill Duncan
light...
I'm not sure what the magic incantations might be, because I've used it very
little, and many years ago at that.
But most APL'ers always find "writing the shortest program possible" a virtue &
challenge; and I would bet a weeks wages that a true blue APL'er could
write a "fractional line" program to beat the pants off the Perl script!
They were always quick to point out that they can write practically anything
in fewer lines of code than *ANY* other language.
I'm intentionally drawing some parallels here, because history has a strange
way of repeating itself. Would you actually *want* to use APL to centre
a line of text even if it is smaller than Perl?? If you answer no as I suspect
most of you will, consider carefully the *reasons why* you are saying no.
Think about it. If it did the job better than Perl, why would you consider it
an inapropriate choice for this task? Are they not the same reasons I have
been suggesting about Perl?
I think we've all centred just about enough text on this one. ;-)
Regards,
Bill Duncan (bdu...@ve3ied.UUCP -or- robohack!ve3ied!bduncan)
Larry Wall
: I'm intentionally drawing some parallels here, because history has a strange
: way of repeating itself. Would you actually *want* to use APL to centre
: a line of text even if it is smaller than Perl?? If you answer no as I
: suspect most of you will, consider carefully the *reasons why* you are
: saying no.
:
: Think about it. If it did the job better than Perl, why would you consider it
: an inapropriate choice for this task? Are they not the same reasons I have
: been suggesting about Perl?
If you can find me a version of APL that gives me efficient access to
traditional Unix operations, with traditional orthography, and doesn't
treat text as funny lists of numbers, and interfaces easily with the
rest of Unix, and lets me optimize not just for abstruse brevity, but
also (when the fit takes me) for readability, or portability, or
maintainability, or speed, or memory usage, or most especially,
programmer efficiency, then I'll be glad to use APL.
Until then, I would say the analogy limps somewhat.
When you go to help out a friend at his house, you take some of your
tools with you. Fine. My toolbox is fairly well organized and
self-contained. I just carry it in the door, and plop it down in the
room with the leaky faucet, and never have to go back out to my car.
Yes, it was heavy to carry in, but that's a well considered sacrifice.
You, on the other hand, drive up with a pickup truck full of loose odds
and ends. Then you go in, search your friend's garage for the right
tool, don't find it, or worse, find it, waste time trying to use it
until it breaks, go out and rummage about for the right tool, maybe go
down to the hardware store to buy it if you don't have it, come back,
notice how much wetter the carpet is since the last time you saw it...
Unix is like a toll road on which you have to stop every 50 feet to
pay another nickel. But hey! You only feel 5 cents poorer each time.
Larry Wall
lw...@netlabs.com