Export ASCII -x

[Scott Walker]

-----Original Message-----
From:
filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celestial.com
[mailto:filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celestial.
com] On Behalf Of Brian K. White
Sent: Friday, November 19, 2010 7:03 PM
To: filepro-list at lists.celestial.com
Subject: Re: Export ASCII -x

On 11/19/2010 5:06 PM, Nancy Palmquist wrote:
> Well I appreciate the testing you both did.  But if you read the fp
> docs, it clearly indicates that it will provide a NEW LINE to an export
> with -x.
>
> So I should not have to put the r=\n or do anything special to get the
> file format I wanted.

I would see newlines as an unwanted injection into a -X export.
Fixed length data files do not have newlines. They do not have record 
delimiters for the same reason they do not have field delimiters. 
Records are extracted by counting bytes only, the same as the fields.

If you want fixed length fields, but for some reason also want an extra 
byte or two in between every record, that is an unusual format and it's 
correct that you should have to go out of your way to add those bytes 
either by r= or by tacking on a field at the end.

If -X would automatically add a newline, then you'd need some way to 
tell it not to do that, because otherwise it would be impossible to 
output real fixed-length data. That would not be useful. Just as a 
filepro key, data, and index files do not contain newlines or anything 
else between records.

Probably adding r= with no argument would work to override that 
backwards behavior if it existed but I consider it backwards to have to 
do that when you already asked for fixed length via -X, that implies 
r=<nothing> already by definition.

If the manual says newlines will be addded to -X by default, I think the 
manual is simply wrong is all. It has other details either wrong or left 
out or without sufficiently defining terms to make the explanation 
meaningful. This would be no great shock. In this case, it's reasonable 
for export to append a platform-dependant newline by default for other 
formats besides -X. The help files in my installation do not say 
anything about appending newlines to any format btw. A perfect example 
of the missing details, since I think it does add them to at least some 
formats by default.

-- 
Bkw





I agree with Brian.  A fixed length file should not have new lines.  It
should just be the data and blank space.  If I say I want a fixed length
file I have to specify how big each field will be and the field will always
be exactly that length.  If I add up the size of each field, I know exactly
where each record ends and the new one begins.

I think fixed length fields are the easiest to work with...no need to worry
about stuff like " or ,

I just find that getting someone to give you something in a fixed length
field file is a bit tough.
They don't seem to know how to do anything other than comman delimited.

Regards,

Scott



> I posted my processing and it just did the EXPORT line, then posted one
> string to one field in the EXPORT.
>
> Then it did a WRITE.  Very simple.
>
> I wanted it to properly add the NEW LINE it indicated was part of its
> output.  But it added nothing.
>
> When I tried to help by adding it to the string, it added an additional
> 0d.  So it looked like it was double spaced.
>
> If I was writing or reading a string of fixed length, lets say 100
> characters and I wanted the New Line to be appended as documented, that
> was my complaint.  It took many experiments to get the right combination
> of CR LF to get a proper NEW line on each record.  I did not want to
> mess with a field delimiter, since it was not required.
>
> But this was very interesting, don't you think?
>
> Nancy
>
> On 11/19/2010 1:38 PM, Bruce Easton wrote:
>> On 11/19/10 12:48 PM, Brian K. White wrote:
>>> On 11/19/2010 10:58 AM, Bruce Easton wrote:
>>>> OK - that's all fine and dandy, *BUT*, after re-reading what Nancy had
>>>> written below,
>>>> I now wonder if there is a difference between my fp 5.0.14 and whatever
>>>> version she is using or maybe it could be *nix vs. windows for the
>>>> results I got for putting r=\n after the -X (which didn't work in that
>>>> order for me whereas it seems to have worked for her on her line 330
>>>> shown below).
>>> I would have thought, and this agrees with what you just pointed out the
>>> manual says, that "-X", without any "r=", should result in NO record
>>> delimiter, no LF or CR, just like a filepro key file.
>>>
>> Yes - it definitely does.  But in the part of my reply (to myself) that
>> you cut above, I had tested:
>>
>> r=\n -X
>>
>> verses
>>
>> -X  r=\n
>>
>> where, in the latter case, for me on Linux fp5.0.14, the r=\n was
>> ignored, whereas Nancy's code shown with that same order worked for her.
>>
>> Bruce
>>
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>
>

_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes
http://mailman.celestial.com/mailman/listinfo/filepro-list