[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
Re: [MacPerl] Basic Question
At 11:16 -0500 09/07/2000, David Steffen wrote:
>I would not call this a basic question. (I also don't think you
>supplied enough information.)
But enough to start. More to follow...
>>I downloaded a script from a web site which processes a data file
>>to make a Palm file.
>
>From your message, I infer this was written to run under Windows.
>Is that correct? (The rest of my message assumes so.)
I'm not entirely sure, but I think it was written under Linux. I have
no reason to suspect it was (or was not) written under Windows.
>>I need to be able to pass two arguments (file names) to the script.
>>If I run the script from the menu it produces an error because it
>>did not have those arguments). How do I pass those arguments?
>
>This problem occurs because MacOS lacks a command line.
That I'd noticed. :) I was surprised that it was emulating Unix and
didn't have a pseudo-CLI.
>>I tried modifying the original script to work around the problem. I
>>found an example script which opened a choose file dialog. I tried
>>using that, and it appeared to work.
>
>...you already found; it looks like you have already solved this problem.
Right and I think that semi-solved the first problem, but allowed me
to progress to the second. I passed the question along because I
wanted to know if there were other methods (particularly without
re-writing a donated script).
>2) You save the file as a droplet. (From the File menu.) Then, the
>names (paths) of whatever files you drop onto the droplet are
>provided to MacPerl as if they had been given on the command line
>(e.g. they are in @ARGV). However, if you are specifying an input
>filename and an output filename, and the output file does not
>pre-exist, that doesn't work. What I do in such cases is to modify
>the script so that the name of the output file is automatically
>generated (e.g. by appending '.out' to the input file name).
That sounds useful. You are correct that one of the file names was an
output filename. I didn't know enough to manipulate the old name to
generate a new name and didn't want to hard-code a set name. So I had
the program open with a generic text box (also borrowed from included
sample code).
>>The Palm file, however, appeared to be incorrectly formatted. That
>>brings up another question. Can the difference in file systems make
>>it mandatory to change the original script to be compatible with
>>the Mac for making a Palm file?
>
>This is why I think this is not a basic question. This is not so
>much a Windows Perl/MacPerl issue, but Windows/MacOS and Palm issues.
>
>1) It may be that the particular file has utterly different formats
>under Windows and under MacOS, in which case the script would need a
>major rewrite (since it really is doing an entirely different job)
>and you would need to get documentation for the Mac file format to
>accomplish that.
Exactly my thought. The script imports data, digests it, and tries to
output it in a PDB format (a Palm database format). I don't think the
Mac/Windows matter in terms of creating the PDB as that format is
set. I think the problem is more how the program writes to the file
which may introduce errors. One thing I didn't mention earlier is
that when I used a hex viewer to view a PDB file I'd created, with an
original from the script's author, I discovered some differences
which could not be attributed to the input data.
>2) It may even be that the particular file represents a
>functionality that Palms don't have on a Mac, in which case there is
>nothing you can do.
That shouldn't make a difference since it's creating a data file
which should just install regardless of the host OS.
>3) However, it may only be that the filetype is wrong. Under
>windows, filetype and the name of the program that should be used to
>open that file are always linked and are specified by a filename
>extension; a Microsoft Excel file has the extension .xls, for
>example. On the Mac, filetype and creator are independent (so that
>two different text files can be opened by two different programs)
>and is specified independently of the name. A Microsoft Excel file
>on a Mac has a filetype of XLS8 and a creator of XCEL, for example.
I don't think this would impact my problem, but might be an
opportunity to improve the script. Right now the file it creates has
a file/creator code of "????/????", if I change it to the right ones
I'd be able to install it with a double-click. But this for a later
enhancement.
-------------------------------------------
At 11:58 -0500 09/07/2000, Jay Bedsole wrote:
>(3) Use a CLI emulator
> (a) MacPerl has one built-in, it's been a while
> since I used it, so I don't remember exactly
> how to get to it. It's in one of the menus
> and I think it's called "One liner".
> Unfortunately, I'm trapped on my PC today...
I couldn't get the one-liner to work. I tried typing the name of the
script, a space, and the name of the input file. It didn't seem to
understand, even when both were in the same directory.
> (b) The BBEdit and Alpha programmers editors
> provide a CLI interface to MacPerl.
I have BBEdit, I'll have to explore this option.
> (c) I wrote a CLI emulator in AppleScript that I'd
> be happy to send you a copy of, if you're
> interested...
Sure, send it along, I'm sure I can make use of it. I also liked the
other threat about using AppleScript to call, and pass parameters to,
MacPerl scripts. I'm sure I can find a way to use the strengths of
each of these tools together.
-------------------------------------------
At 23:32 +0200 09/07/2000, Bart Lateur wrote:
>But, I assume that you want maybe one input file, and one output file
>name? You can modify the script that the output file is automatically
>chosen, based upon the input filename. You can rename the file by hand.
This I would like to do, but I need to learn more about how
manipulate text first. You see, I just downloaded MacPerl and the
script. I went from zero knowledge to trying to customize the script
immediately.
>A difference between platforms is the line termination characters for
>text files. I suppose that can byte you. Note that "\n" on the Mac is a
>CR (Ascii code 13, "\015") and "\r" LF (Ascii code 10, "\012"), while on
>Unix it's just the reverse.
>
>On a PC, Unix is emulated, but with CRLF sequences being converted into
>"\n" = "\012" on input, and back on output. You need to use binmode() on
>the file handle to prevent that.
>
>It's not unlikely that this is what bites you. Modify the script so that
>your script generates the actual bytes you need in the file, and apply
>binmode on the filehandle. (This is a NOOP on MAc and Unix).
This could very well be the problem. Here's an excerpt of the portion
that writes the Palm database file.
<begin script segment>
for ($i=0; $i<=$#h; $i++) {
printf(DB "%c",$h[$i]);
}
for ($i=0; $i<520; $i++) { printf(DB "%c%c", $erg[$i]/256, $erg[$i]%256); }
for ($i=0; $i<520; $i++) { printf(DB "%c%c", $fix[$i]/256, $fix[$i]%256); }
for ($i=0; $i<20; $i++) {
printf(DB "%s", $mann[$i]);
for ($j=0; $j<18-length($mann[$i]); $j++) { printf(DB "\0"); }
}
for ($i=0; $i<52; $i++) {
printf(DB "%c%c%c%c", ($datum[$i]&0xff000000)>>24,
($datum[$i]&0xff0000)>>16, ($datum[$i]&0xff00)>>8, $datum[$i]&0xff);
}
close(DB);
<end script segment>
Before this segment is a portion that appears to be writing using
hex, but I may be misreading it. I've studied enough of C/C++ to
recognize some of what is being done above, but I'm not sure I know
what the '$' or '#' in front of a variable mean.
Thanks again,
--
-- Chip <http://chipg.com>
# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org