ADD CR/LF TO FILE
Dale Stover
I am looking for a unix utility that will copy a file blocked at 2048
with no end-of-record delimitor to a file that has records of 2048 plus a
cr&lf.
ANY IDEAS?
Thanks
Dale Stover
Jean-Pierre Radley
| HI!
| I am looking for a unix utility that will copy a file blocked at 2048
| with no end-of-record delimitor to a file that has records of 2048 plus a
| cr&lf.
dd can be made to add newlines. Then xtod will add carriage returns.
--
JP
Ken Wolff
JP,
dd will only do this converting from ebcdic to ascii with a cbs, is that
correct? I know I've had to convert ascii files to ebcdic and then back to
ascii to accomplish this.....or am I missing something?
--------------------------------------------------------------
Ken Wolff
Phone: 616-957-4949 Ext: 1111
FAX: 616-957-1614
--------------------------------------------------------------
Jean-Pierre Radley
| At 07:34 PM 10/12/01 +0000, Jean-Pierre Radley wrote:
| >Dale Stover propounded (on Fri, Oct 12, 2001 at 01:55:53PM -0500):
| >| HI!
| >| I am looking for a unix utility that will copy a file blocked at 2048
| >| with no end-of-record delimitor to a file that has records of 2048 plus a
| >| cr&lf.
| >
| >dd can be made to add newlines. Then xtod will add carriage returns.
|
| correct? I know I've had to convert ascii files to ebcdic and then back to
| ascii to accomplish this.....or am I missing something?
It may involve several conversions; I know I've done it, but I can't
can't recall anymore.
--
JP
Jim Mohr
"Dale Stover" <da...@stpsoft.com> wrote in message
news:3bc73cbf$0$27639$724e...@reader2.ash.ops.us.uu.net...
Bob Meyers
"Jim Mohr" <jrm...@snet.net> wrote in message
news:meLx7.3134$Y8.23...@newssvr28.news.prodigy.com...
> "Dale Stover" <da...@stpsoft.com> wrote in message
> news:3bc73cbf$0$27639$724e...@reader2.ash.ops.us.uu.net...
> > HI!
> > I am looking for a unix utility that will copy a file blocked at
2048
> > with no end-of-record delimitor to a file that has records of 2048 plus
a
> > cr&lf.
>
> Install Perl and stuff like this becomes 1 and two liners.
>
don't no where I got it (some SCO product) but for many years I have had a
little filter set called "addcr" and "rmcr". I always copy it to any new
server I do. It is just like cat but adds/removes a CR to NL. If you don't
find a solution, email me and I'll send it along.
Jean-Pierre Radley
Well, your little program is not what he needs, because the file he
has to work with has NO NEWLINES in the first place, so I suspect your
addcr/rmcr would not do what he wants, which is to add a NL/CR after
every 2048 bytes in the input.
Your addcr/rmcr, though, is all done by my one single file called cr+-:
: cr+-
# adds CRs if not present, strips them if present
# note: if you just cat this file, you miss its essence
# if you cat -v this file, you see the _real_ ^Ms in it
sed '
s-^M--g
t
s+$+^M+
t
'
--
JP
Bob Meyers
"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2001101220...@jpradley.jpr.com...
attention to the subject line. Ok, a C filter then :)
Jim Mohr
Perl is hands down a Necessity if you deal with text manipulation
#! /usr/local/bin/perl
open( STDIN );
while( read( STDIN, $_, 2048 ))
{
print "$_\r\n";
}
"Jim Mohr" <jrm...@snet.net> wrote in message
news:meLx7.3134$Y8.23...@newssvr28.news.prodigy.com...
Serge Bromow
news:meLx7.3134$Y8.23...@newssvr28.news.prodigy.com...
> Install Perl and stuff like this becomes 1 and two liners.
Perl Shmerl!
main(argc, argv)
int argc;
char **argv;
{
int in,
out,
len;
char buf[2048];
if( argc != 3 ) {
printf("progname infile outfile\n");
exit(1);
}
if( (in = open(argv[1],0)) == -1 ) {
exit(1);
}
if( (out = creat(argv[2], 0664)) == -1 ) {
exit(1);
}
while( (len = read(in, buf, 2048)) > 0 ) {
write(out, buf, len);
write(out,"\r\n", 2);
}
close(in);
close(out);
exit(0);
}
Just Kidding. Lots of different ways
some more familiar than others.
Cheers
Serge
--
Posted from port-39.ottawa4.achilles.net [209.151.2.138]
via Mailgate.ORG Server - http://www.Mailgate.ORG
Jim Mohr
No Contest! If we had a problem that required text manipulation, I'd leave
ya in the dust! When the details of implementation become more complicated
than the problem you are trying to solve... it is time to explore other
alternatives... agreed??
;)
"Serge Bromow" <se...@omensys.com> wrote in message
news:75ed528ec3b93d9b0a3...@mygate.mailgate.org...
Tony Lawrence
>
> Now which is easier to read/intuitive? Your C program or my Perl script?
I think that's why he added "Just Kidding" at the end of his post.
But.. if you don't know Perl (and I think everyone should:
http://pcunix.com/Unixart/loveperl.html ), writing the C program can be
quicker than spending the time to learn something new. And again, for
someone intimate with C but not with Perl, the C program is completely
understandable and the Perl, although short, is not.
We approach jobs with the tools we have. I think everyone should add
Perl to their toolbox, yes. But then I think everyone should have at
least a smattering of C too :-)
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Jim Mohr
(Yech!) -> Perl
there is NO GOING BACK, I LIVE by:
When the details of implementation become more complicated
than the problem you are trying to solve... it is time to explore other
alternatives...
There was a time when I thought 'C' was the cat's meow... ah, young and
foolish
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:3BC81FB2...@pcunix.com...
Tony Lawrence
>
> From a Unix guy who progressed from Assembler-> MacroAssembler -> C -> C++
> (Yech!) -> Perl
> there is NO GOING BACK, I LIVE by:
> When the details of implementation become more complicated
> than the problem you are trying to solve... it is time to explore other
> alternatives...
>
> There was a time when I thought 'C' was the cat's meow... ah, young and
> foolish
Well, C *is* the cat's meow. It's just that Perl is a better cat for a
lot of the common things we do every day that we need cat-like tools for
:-)
Serge Bromow
Dear Jim,
You must have missed the "Just Kidding" part of my message.
Now on to more serious matters. YOU TOP POSTED! What on earth were
you thinkng? Were you drunk when you posted or are you simply insensitive
to bottom poster.
> Now which is easier to read/intuitive? Your C program or my Perl script?
> No Contest! If we had a problem that required text manipulation, I'd leave
> ya in the dust! When the details of implementation become more complicated
> than the problem you are trying to solve... it is time to explore other
> alternatives... agreed??
> ;)
>
> >
> > > Install Perl and stuff like this becomes 1 and two liners.
> > >
Here is your one liner C equivalent;
main()
{
int l;
char buf[2048];
while( (l=read(0, buf, 2048)) > 0 ) { write(1, buf, l); write(1,"\r\n",2); }
}
> Your C program or my Perl script?
> No Contest!
You have gathered by now that I am C kinda guy. I do use
PERL although my strength is in C. I have also writen a number
of small C programs like the one bove for my PERL buddy's so
they could call them from PERL. This is typicaly done for reasons
of efficiency. If you plan on processing a few gig of data,
the C version will run much faster.
Your Perl script or my C program?
No Contest!
Yours in humor,
Serge
--
Posted from port-40.ottawa2.achilles.net [209.151.2.47]
Bill Vermillion
>> Now which is easier to read/intuitive? Your C program or my Perl script?
>I think that's why he added "Just Kidding" at the end of his post.
>But.. if you don't know Perl (and I think everyone should:
>http://pcunix.com/Unixart/loveperl.html ), writing the C program can be
>quicker than spending the time to learn something new.
I guess that's why COBOL is still around.
))))
))))
:::: ))))
:::: ))))
---- ))))
---- ))))
:::: ))))
:::: ))))
))))
))))
Bill
--
Bill Vermillion - bv @ wjv . com
Brian K. White
> Now which is easier to read/intuitive? Your C program or my Perl script?
> No Contest! If we had a problem that required text manipulation, I'd
leave
> ya in the dust! When the details of implementation become more
complicated
> than the problem you are trying to solve... it is time to explore other
> alternatives... agreed??
relax preacher, I guess you've never seen this old joke before...
http://www.gnu.org/fun/jokes/helloworld.html
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Brian K. White
> >
> > Now which is easier to read/intuitive? Your C program or my Perl
script?
>
> I think that's why he added "Just Kidding" at the end of his post.
>
> But.. if you don't know Perl (and I think everyone should:
> http://pcunix.com/Unixart/loveperl.html ), writing the C program can be
> quicker than spending the time to learn something new. And again, for
> someone intimate with C but not with Perl, the C program is completely
> understandable and the Perl, although short, is not.
>
> We approach jobs with the tools we have. I think everyone should add
> Perl to their toolbox, yes. But then I think everyone should have at
> least a smattering of C too :-)
hehe and in that vein I'd use ksh, awk, qb2c, or ...filePro! (actually,
although I can think of at least three approaches using filePro off the top
of my head, I wouldn't really do that, unless it was a recurring task and I
wanted the data imported into filePro.
perl zealots always seem to disregard the value in knowing how to do
something using only the basic tools installed on every system. I actually
use cu for both terminal access and file transfer all the time. Sure,
usually it's just to transfer a kermit or zmodem binary and thereafter use
that instead but the necessity for the old tool is still there today.
If you are comfortable with the least common denominator, you can always get
your job done and you never sit there going "wahhh! this box doesn't have
bash and perl and xxxx so I'm helpless..."
Jim Mohr
>> the C version will run much faster.
No argument here. In my early years, I would take the assembler stage
output from the C
compiler and hand optimize the register usage (mostly for lower level driver
hooks).
It is all relative.
This example was abitarily simple, but the use of regular expressions (
minus all the silly backslashes )
and assocative arrays, parallel the way humans solve many 'text language'
related problems. With a little practice, it can be pretty self documenting
(kindof... Not the REs though!). There is NOTHING that perl can do, that
can not be implemented more efficently in 'C' (however ugly and unreadable
it may become). That IS NOT to say that I haven't come across some pretty
ugly perl in my day. Perl sacrfices efficency, for ability to quickly
implement a solution. If efficency is critical, maybe 'C' is the choice.
My point is for many simple little jobs that come up daily, perl can provide
one of the easiest/quickest means to an end. Its FREE; you don't have
separate source and executables to worry about, and with a little care
(sometimes alot) you can move it over to Non-Unix based platforms with a
fair degree of success. If you find yourself thrown into an NT environment
(without the luxery of MKS utilities), perl may be one of your ONLY friends.
>> Now on to more serious matters. YOU TOP POSTED! What on earth were
>> you thinkng? Were you drunk when you posted or are you simply insensitive
>> to bottom poster.
Your insensitive, and sometimes drunk, friend in humor,
Jim
I just put a bullet in this dog's head!
enyoy the weekend
Now somebody tell me why sorting date fields on 3.2v4.2:
sort -t\| +1.4 -2 +1 -1.5 <<-%
85000|mmddyy|...
.
.
.
%
Doesn't work AT ALL on 3.2v5.0[45]
( but sort -t\| +1.4 -2 +1 -2 does! BTW it is the -1.5 that screws things
up, but Why!!! )
Bob Meyers
"Dale Stover" <da...@stpsoft.com> wrote in message
news:3bc73cbf$0$27639$724e...@reader2.ash.ops.us.uu.net...
Yes, I have an idea, based on all the expertise given in the many replies.
You and I show both dust off our perl packages and learn it! As for your
current issue, just make sure you have perl, cut the program out of Jim
Mohr's post, and run it!
( If it don't work, come back here and flame the author :)
Robert Carnegie
Class clown here. On OpenServer 5 you can use the "split" utility
to chop the file into a large number of files of 2,048 bytes. Then
you can use "cat" to put the pieces back together, inserting CR+LF
manually between pieces.
This is probably the quickest way to exhaust the ~65,000 inode
allowance of your filesystem ;-)
Of course you could split the file on, say, 204,800 byte boundaries
and then split and process each 100-record piece separately.
It's silly, but it works.
"split" on systems older than OpenServer doesn't split on bytes - ?
If I've asked for a workaround for _that_ here (it feels familiar),
it was for a project that was killed and that I've forgotten.