MACSCRPT Archives

June 2006

MACSCRPT@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joe Barwell <[log in to unmask]>
Reply To:
Macintosh Scripting Systems <[log in to unmask]>
Date:
Thu, 8 Jun 2006 22:49:12 +1300
Content-Type:
text/plain
Parts/Attachments:
text/plain (91 lines)
On Wed, 7 Jun 2006, Emmanuel <[log in to unmask]> wrote:

>At 10:10 PM +1300 6/7/06, Joe Barwell wrote:
>>Secondly, I find Satimage osax's behaviour unpredictable as regards
>>escaped characters. For example, "\\r" or "\\t" often seem to be
>>being treated as literals, instead of escaped special characters, but
>>I can't find a logical pattern as to where their use is
>>recognized/not.
>
>Maybe what is confusing you is that when used "with regexp" the osax 
>follows the Regular Expressions syntax, while when used without 
>regexp the osax follows AppleScript's rules only.
>
>Also, another thing which can yield confusion is that, *inside 
>quotes*, you can write \r and AppleScript understands return.

You may be right, Emmanuel, but my rather un-methodical investigations earlier today had seemed to suggest more that the difference between "\\r" and "\r" (both with regexp) was more in how the AS compiler rendered them, rather than differences in script outcome. Also, possibly more telling is that I may be misinterpreting results that do not meet my expectations as "irregularities", when in fact they may simply be the expected results of poor regex syntax on my part. Mea culpa.

>Now, Joe, maybe you would be able to provide us with a more specific 
>unwanted behavior.

I'm afraid I can't yet provide any firm evidence, partly due to complications of circumstance (I'm sending you this from my home 68k mac, on which I can do no tests of (recent) Satimage regex syntax, and I don't have an easy means of communicating with my workplace g4 running 10.3.9, where I can perform some tests.

Still, the following script snippet was tested using Satimage.osax 3.0.5. Remove comments from relevant lines as needed if you wish to test (i.e. I've left uncommented the two key lines that do now work):

set productPartsList to "PF137	IN	SD
PB201	PG	INTDIST
PB251	PG	ENLG
PB252	PG	TYFC	LINZSH	ENLG"

set productID to "PB252"

set partList to {}
try
	set partList to matchResult of (find text ("^" & productID & "\\t.*$") 
in productPartsList with regexp)
	-->"PB252	PG	TYFC	LINZSH	ENLG"

	--set partList to change (productID & "\\t") into "" in partList with rexexp
	-->"PB252	PG	TYFC	LINZSH	ENLG", i.e. now fails.
	-- above used to work with Smile 2.6.9, g3 macos 9.2 and g4 10.3.9.

	set partList to change (productID & tab) into "" in partList with rexexp
	-->"PG	TYFC	LINZSH	ENLG", i.e. works.


	--set partList to paragraphs of (change "	" into "\\r" in partList)
	-->{"PG\\rTYFC\\rLINZSH\\rENLG"}, i.e. fails.
	-- above used to work with Smile 2.6.9

	--set partList to paragraphs of (change "\\t" into "\\r" in partList)
	-->{"PG	TYFC	LINZSH	ENLG"}, also doesn't work.

	set partList to paragraphs of (change tab into return in partList)
	-->{"PG", "TYFC", "LINZSH", "ENLG"}, success!
	
	return partList
on error number 1
	set partList to {}
end try

In summary, then, there are parts of the above snippet that worked using Smile 2.6.9 & its version of Satimage osax, but which now produce different results using Smile & Satimage osax 3.0.5. Yes, it would appear I was mixing up the syntax earlier, using escaped characters in some places, and literals in others, a product of messing about with trial & error to find soemthign workable. Yes, in hindsight it looks like I didn't need the 'with regexp' param. for the first change command line, but that doesn't explain the difference in performance with different versions of Satimage osax, does it?

Why does:

change "	" [a tab character] into "\\r"

produce literal "\\r" strings instead of CRs? That, plus the failure of:

change "\\t" into "\\r"

seem to suggest double-escapes in an AS (rather than 'with regex') context are treated as literals, when I had thought they would simply prevent the AS compiler from changing the uncompiled:

change "\t" into "\r"

into the compiled:

change "	" into "
"

:-?

yes, alright, I've confused myself yet again. <sigh!> :-\

Cheers!

con-few-shuss

Selected from Ambrose Bierce's "Devil's Dictionary":
EAVESDROP, v.i. -- Secretly to overhear a catalogue of the crimes and vices of another or yourself.

ATOM RSS1 RSS2