transfer filePro file from dos to unix
Brian K. White
brian at aljex.com
Sun Oct 26 14:44:58 PDT 2008
----- Original Message -----
From: "Dennis Malen" <dmalen at malen.com>
To: "Brian K. White" <brian at aljex.com>; <filepro-list at lists.celestial.com>
Sent: Friday, October 24, 2008 6:10 PM
Subject: Re: transfer filePro file from dos to unix
>I have used Ken Brody's approach with the use of FTP. I used both the ascii
> and binary facility. I changed the ownership to filePro and moved it to the
> appropriate unix directory. Then I went into the program and it acknowledged
> a screen.9 and gave me the following error message:
>
> *** A filePro Error Has Occurred ***
>
> Error reading screen
>
> On File: /appl/filepro/test/screen.9
>
> Invalid screen format.?
>
> Both machines were little endians.
>
> Please note that the transfer of the prc file worked fine when I saved it in
> ascii and brought it over to the unix box.
>
> Any thoughts?
Well like I said, There is only a small number of possibilities,
and they can simply be tested for directly in a few minutes.
Either it got corrupted by having CR's removed,
Or it's invalid because cr's were NOT removed,
Or screens are one of those components that simply requires xfer.
Some components require xfer and simply can't be moved between
platforms any other way. "xfer" means:
* You need two different xfer programs, one for each platform.
* On platform A you run xfer to take a filepro file and export
it to an xfer file.
* Then you copy that file to platform B without changing a single
byte (ie: ftp using binary mode).
* Then on platform B you run xfer to extract the xfer file back to
a filepro file.
I just tested.
I created a new file "lib" in a windows fp, and
created a new screen 1 in it. On unix I already had a "lib"
file, with no screen 1.
It's important to note that:
* The file name "lib" is the same exact all-lower-case spelling
on both systems. As well as the screen name which is simply "1"
* Both systems use the same family of cpu.
(so, same endianness)
When I ftp the file lib/screen.1 using ascii mode, and then run
setperms on unix, or manually chown & chmod the screen.1 file,
and then try to load the screen in define-screens, I get a checksum
warning and then the screen opens but has a mix of recognizeable
content and junk in it.
When I do all the same with the only difference being to ftp in
binary mode, I get the same result with the exception that the
junk is different looking junk.
In both cases the junk seemed to be associated with the box
I had drawn in the screen. The fields looked correct and in
their correct place.
So, screens require xfer.
xfer works on whole filepro files, which would be
inconvenient, actually unsafe, if you are developing
for a file that has data in it and all you want to do
is modify a screen.
One answer is to set up a seperate fp tree on both systems
that has few or no filepro files in it. When you want to move just
a screen without screwing up anything else, at the OS level copy
the screen into the seperate filepro directory and run xfer in that
environment to export the file with the screen in it.
Then on the other platform do the same, run xfer in the side
environment to import the file, then use OS-level tools (ie: cp)
to copy just the screen into your real target fp tree.
In this case where you are just using the windows side to
develop, if you don't need data, or don't need as much data,
you can just work directly in the import/export fp tree
on the windows side to skip a few steps.
So for example,
On windows:
Make a filepro tree c:\x\filepro, and make a x.bat file that
sets up the environment to work out of that dir.
create a file with the same exact name as the one you will be
working on o unix. say, invoices. draw a screen. run:
cd \x
xfer -lf invoices.xfr -t invoices
Run that in the same cmd prompt that ran x.bat!
Binary ftp c:\x\invoices.xfr to /x/invoices.xfr on unix.
On unix, have a similar fp tree that is not the one
with your data in it. say, /x/filepro or /x/appl/filepro.
and a start-script that sets up PFDATA/PFDIR etc to use
that dir. A unix version of x.bat. In that envirnment run
xfer to import "invoices" into /x/filepro/invoices:
cd /x
xfer -lf invoices.xfr -r
Now you can use "cp" to move just the screen into your real
system without the rest of the invoices file.
cp -a /x/filepro/invoices/screen.1 /u/appl/filepro/invoices/screen.1
Permissions on the final screen file should be good if you did this
exactly (assuming the unix system was linux and/or that it's cp command
has an "-a" option which means to preserve things like permissions
and ownership.) Otherwise, just run setperms in the final target system
after copying.
Since the file is named "invoices" in both /x/filepro and in /u/appl/filepro,
you won't have a checksum error.
Personally, I have done, but almost never do all that.
Going back & forth between windows and unix is just
not convenient no matter how you slice it.
So, I don't do that.
I just develop directly in unix and use Laura's color
picker define-screens wrapper in the case of screens.
If I'm stuck on a plane or somewhere else without net
access to the target system, that is why I always have
a linux partition.
Then there is no special transfer problem. You don't need
xfer, or a seperate fp tree to import/export xfer files.
Just ftp the screen file directly either way.
Going back & forth between linux/freebsd/sco/other
is no problem as long as the cpu's are the same type.
SCO only runs on x86, and everything but old macs are also
x86, so a linux partition on a normal laptop lets you
do native fp development for sco, and x86 versions of
linux, freebsd, freebsd, solaris, and anything else that
has an x86 version. However, most solaris installs aren't
x86. most linux, freebsd, and all sco are.
These days you can even run a linux system completely on
a bootable usb stick without touching your hard drive.
--
Brian K. White brian at aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
>
> Dennis Malen
> 516.479.5912
> ----- Original Message -----
> From: "Brian K. White" <brian at aljex.com>
> To: <filepro-list at lists.celestial.com>
> Sent: Thursday, October 23, 2008 4:38 PM
> Subject: Re: transfer filePro file from dos to unix
>
>
>>
>> ----- Original Message -----
>> From: "Dennis Malen" <dmalen at malen.com>
>> To: <john at valar.com>
>> Cc: <filepro-list at lists.celestial.com>
>> Sent: Thursday, October 23, 2008 11:14 AM
>> Subject: Re: transfer filePro file from dos to unix
>>
>>
>>> John,
>>>
>>> When I FTP I use TinyTerm to FTP in binary or ascii.
>>>
>>> Perhaps I am making a mistake by using the following procedure:
>>>
>>> The filePro file is created on my laptop. I then copy that file to a cd
>>> or a
>>> usb port (I used the usb port). I then upload the filePro file on my
>>> windows
>>> computer in my office. I then FTP the filePro file over to the UNIX box
>>> (I
>>> have tried both binary and ascii). I then go through the procedures that
>>> Ken
>>> outlined for the screen and report.
>>>
>>> Do you see anything wrong that could corrupt the transfer?
>>
>> The different parts of filepro files need different handling.
>>
>> prc files need to have the correct line-endings for the platform they are
>> on.
>> This means on unix, only LF's
>> On windows CRLF's
>> There are several ways to get that result, but focus on the result, not
>> the method.
>> Saying "use acii mode ftp" is one method, and may or may not actually
>> produce
>> the result, depending on other factors. So it's more robust to just be
>> aware of the necessary end result, so that when you try to load a file on
>> whichever platform, if it looks like junk, you just fix it by whatever
>> means is handy. If you're on unix and the file cas CR's in it (^M's), look
>> for utilities like, dos2unix, dostounix, dtou, dtox, or google up a sed or
>> awk example. If you're on windows and the file lacks CR's, then I don't
>> know what's the simplest fix. I'd proably generate a windows friendly file
>> right on unix and ftp that in binary mode, since win & unix use different
>> filenames for the same prc file. ("unix2dos <prc.foo >foo.prc" then copy
>> foo.prc via ftp)
>>
>> Other files like screens and output formats I _think_ need to transferred
>> in binary mode.
>> They don't have line endings, they are fixed format files. I _think_. Me,
>> I'd simply try it each way on a sample menu, screen, etc and see. It takes
>> way way less time to just test it both ways and see than it does to post a
>> question here and read 3 wrong and 2 right answers and try to guess who to
>> trust and why you can'tmake it work until Ken finally utters the gospel on
>> that particular matter, probably for the 12th time this year and every
>> previous year (he has nothing better to do of course).
>>
>> key, data, index*, (and now blob), unquestionably always transfer in
>> binary mode ONLY.
>>
>> Add to all the above, if the endianness of the two platforms differs then
>> you also need swapcpu, but I think in this case you do not.
>>
>> I'm not sure which if any components absolutely require xfer in order to
>> generate correct checksums along the way.
>> Perhaps any component that has checksums in it. menu? screen? out? map?
>> Again simple trial & error is the fastest and most reliable way to find
>> out in my opinion.
>> It only takes 2 tries per file type to ascertain either 1) needs ascii
>> crlf/lf translation, 2) needs binary mode, ie, preserve the data exactly &
>> perfectly, or 3) neither 1 nor 2 worked, and so it needs xfer.
>>
>> --
>> Brian K. White brian at aljex.com http://www.myspace.com/KEYofR
>> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
>> filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.549 / Virus Database: 270.8.3/1744 - Release Date: 10/24/2008 6:08 PM
>
>
More information about the Filepro-list
mailing list