I am creating ASCII file from Oracle procedure into Unix box.
I undertstand there is NO CRLF as I am writing it into one complete string .. but need to know what is best way to format the file with 80bytes per line only before handing over to another program.
Actually, there is nothing to do. In addition to not using cr/lf characters, the creating program simply must ensure that line two starts with byte eighty-one and so on.
is there any otherway to break into 80 byte per line with putting a line break...
As fold does not fit in the current schema .
here is the document which says
breaking the lines to have a maximum of width column positions
(or bytes, if the -b option is specified). The fold command breaks
lines by inserting a newline character so that each output line is the
maximum width possible that does not exceed the specified number of
column positions (or bytes). A line cannot be broken in the middle of
a character. If no files are specified or if a file name of - is
specified, the standard input is used.
actully that is another application requires my ascii file with
1.80byte pers line
2.with NO CRLF (as IEEE says :CRLF refers to a carriage-return character ('\r', octal 15, ASCII CR) followed by a line-feed character ('\n')
and I guess fold will create a line-feed charchater
I think you are simply missing the point about having multiple 80 character lines and somehow making these individual lines without some kind of line break. Let's try this.
Process your file with 80 character lines using fold
Pad each line once folded
Use tr or sed to strip the line breaks out of the file
Example creating 20 character records:
{
typeset IFS=$(echo '\012\001')
print "This is a line test
This is another line test" | fold -w 20 | while read LINE
do
typeset -L20 NEW_LINE="$LINE"
print "$NEW_LINE"
done | tr -d '\012' | od -x
}
Thanks, tmarikle. And don't trip over the terminology. Unix has a definition that a line is a sequence of ascii characters followed by a newline character. By that definition, what is requested is impossible. But the unix definition is not the only possible definition of "line". I would have used "record" but when someone else uses "line" I just go with the flow. In C it is very easy to read 80 bytes at a time:
iret = read(fd, buffer, 80);
is all it takes. The 80 bytes you get from the first read represent the first record or first line. Then you issue the system call a second time to get another 80 bytes. It is not really hard to keep the first 80 bytes from getting mixed up with the second 80 bytes.
OK, tmarikle has provided a solution, but I have a few questions.
The output through 'od' looks fine. But the OP wants to write to a file. If you write this output to a file, you get a single line with no newline char at the end (this will happen no matter how big the file is). If you run the 'wc -l' command on that file, you are going to get the output as 0 (because the wc command will look for the \n char to count the number of lines).
Then as Perderabo has said, the read(2) or fread(3), fgets(3) calls will allow you to read the file in a C program. But how do you do this in a shell script?
I expanded the input to tmarikle's script by adding a couple more lines.
# cat test.sh
#!/usr/bin/ksh
typeset IFS=$(echo '\012\001')
print "This is a line test
This is another line test
And this is yet another
And another!!! What's going on?" | fold -w 20 | while read LINE
do
typeset -L20 NEW_LINE="$LINE"
print "$NEW_LINE"
done | tr -d '\012'
# ./test.sh > test.sh.output
# ls -l test.sh.output
-rw-r--r-- 1 root other 140 Jul 25 10:21 test.sh.output
# wc -l test.sh.output
0 test.sh.output
ssunsp3:/aditya/sh# while read line; do
> echo $line
> done < test.sh.output
#
The file created by the above process, and the file created by this:
#!/usr/bin/ksh
typeset IFS=$(echo '\012\001')
print "This is a line test
This is another line test
And this is yet another
And another!!! What's going on?" | tr -d '\012'
are almost the same. There is no padding for the second file.
So the OP could simply create a file by stripping all newline characters from the file. The application/program that reads the file is going to have to do this 80 bytes at a time, that's all.
In ksh, "print -n" will suppress the newline. Combine that with the \ sequence for using octal values and ksh can write any binary data using only built-in commands. But to read binary data, the way I know is to parse the output from od.
I have a ksh script in which I replace a string with another string that should contain a CRLF. I have added \\n in the REPLACE variable. It looks something like this. If I do not add \\n the replace works correct.
sed -e s/"$FIND"/"REPLACE"/g infile.xml > outfile.xml
I have searched the forums for a solution. There were lots of them but I couldn't get one of them working. Is this the right direction to or should it be scripted else.