transfer filePro file from dos to unix
Dennis Malen
dmalen at malen.com
Sun Oct 26 17:57:19 PDT 2008
Wow! Thanks for the in depth response and great tutorial on my
problem. Should be saved for future use when this issue arises again.
I will try each your suggestions. I am sure one your suggestions will
work. Your have made it extremely clear and I am sure I will be able
to develop a resolution.
Thanks!
Dennis Malen
Sent from my iPod
On Oct 26, 2008, at 5:44 PM, "Brian K. White" <brian at aljex.com> wrote:
> ----- 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
>>
>>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
More information about the Filepro-list
mailing list