This bit of code will process your output to the desired form:
-- cut the text before & after the desired bit
set text item delimiters to {"/* ", (" */" & return)}
set theClip to text items of theClip
set theClip2 to {}
-- fish out the desired bits from the list
repeat with i from 2 to count theClip by 2
set end of theClip2 to contents of item i of theClip
end repeat
-- concatenate
set text item delimiters to ""
set theClip2 to theClip2 as text-- there's your result
We don’t know how you get your output, so I can’t tell you how to get it into this code.
And sometimes strange things will show up; I tested with a paragraph from the DeRez manpage, and got ‘¬’ at the line endings.
Thank you so much for the code.
My problem now is that the DeRez shell command is not returning the proper string to be interpreted.
Is there any way, in Applescript to access the content of a text resource inside a file?
With installed SatImage OSAX it’s very easy to get the plain text out of a clipping file
set theClipping to choose file of type "clpt"
set destinationFile to (path to desktop as text) & "clipping.txt"
set fileDescriptor to open for access file destinationFile with write permission
try
-- The next two lines use the Satimage OSAX.
set rsrcNum to beginning of (list resources "utxt" from theClipping)
set txt to (load resource rsrcNum type "utxt" from theClipping)
write txt & return as «class utf8» to fileDescriptor
close access fileDescriptor
on error
try
close access file destinationFile
end try
end try
Since you’re using the Satimage.osax anyway, you might as well use it more.
set destinationFile to (path to desktop as text) & "myClippingText.txt"
tell application "Finder" to set finderSelectionList to selection as alias list
if length of finderSelectionList = 1 then
set theClipping to item 1 of finderSelectionList
-- The next two lines use the Satimage OSAX.
set clippingText to (load resource 256 type "utxt" from theClipping)
writetext clippingText & return to file destinationFile with append
end if
I’m using this Applescript inside an Automator Service and Folder Action, to automatically convert textClipping files to TextEdit files.
Since textClipping files store the text inside resources, if I copy then to a FAT16, FAT32 or NTSF pen, only the data fork of the files is copied. So, I get zero Kb files.
Also, the resource fork seems not to “survive” when carried through some types of networks.
So, since I use textClipping files so much, I need to make them compatible to whatever storage or networking method I may end up using.
This is working just fine, now
I’m using macOS Mojave and can’t seem to get this to work… can you please share how you did it? I"m basically trying to do the same exact thing you did… use the AppleScript inside Automator and Folder Action to automatically convert textClippings to Text Edit files.
use AppleScript version "2.5"
use framework "Foundation"
use scripting additions
set hfsFile to choose file "Choose a textclipping file" of type {"com.apple.finder.textclipping"}
set |⌘| to a reference to current application
set theData to |⌘|'s NSData's dataWithContentsOfURL:(hfsFile as «class furl») -- edited according to Shane's comment
set theDict to |⌘|'s NSPropertyListSerialization's propertyListWithData:theData options:0 format:(missing value) |error|:(missing value)
set theString to (theDict's valueForKeyPath:"UTI-Data.public.utf8-plain-text")
set hfsPath to POSIX path of (path to desktop) & "someText.txt"
(theString's writeToURL:(hfsPath as «class furl») atomically:true encoding:(|⌘|'s NSUTF8StringEncoding) |error|:(missing value))
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) jeudi 20 février 2020 15:38:19
I’m a bit surprised if that works – dataWithContentsOfFile: should take a POSIX path, not a URL. I can’t help but think your avoidance of POSI paths is introducing a bit of unnecessary complexity.
I executed the script before posting and it really worked.
After reading your message I searched for “dataWithContentsOf” and discovered “dataWithContentsOfURL” which I now use but it makes no practical difference to the script behavior.
StefanK already wrote that my avoidance of POSIX induce a bit of complexity but it’s a deliberate choice.
In fact, many times, “set theURL to hfsPath as «class furl»” is sufficient but in the posted script it wasn’t.
For those attached to them, here is the same script using POSIX paths.
use AppleScript version "2.5"
use framework "Foundation"
use scripting additions
set theFile to choose file "Choose a textclipping file" of type {"com.apple.finder.textclipping"} as text
set |⌘| to a reference to current application
set theData to |⌘|'s NSData's dataWithContentsOfFile:(POSIX path of theFile)
set theDict to |⌘|'s NSPropertyListSerialization's propertyListWithData:theData options:0 format:(missing value) |error|:(missing value)
set theString to (theDict's valueForKeyPath:"UTI-Data.public.utf8-plain-text")
set hfsPath to (path to desktop as text) & "someText.txt"
(theString's writeToFile:(POSIX path of hfsPath) atomically:true encoding:(|⌘|'s NSUTF8StringEncoding) |error|:(missing value))
I’m just wondering if I am specifying the encoding uselessly but,
(theString’s writeToFile:(POSIX path of hfsPath) atomically:true) is described as “Deprecated”.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 21 février 2020 10:48:21
Nowadays Apple highly recommends (in Swift all path manipulation APIs have been removed from the String struct) to use always the URL related API to interact with the file system
use AppleScript version "2.5"
use framework "Foundation"
use scripting additions
set filePath to POSIX path of (choose file "Choose a textclipping file" of type {"com.apple.finder.textclipping"})
set |⌘| to a reference to current application
set fileURL to |⌘|'s NSURL's fileURLWithPath:filePath
set theData to |⌘|'s NSData's dataWithContentsOfURL:fileURL
set theDict to |⌘|'s NSPropertyListSerialization's propertyListWithData:theData options:0 format:(missing value) |error|:(missing value)
set theString to (theDict's valueForKeyPath:"UTI-Data.public.utf8-plain-text")
set hfsPath to POSIX path of (path to desktop) & "someText.txt"
set destinationURL to |⌘|'s NSURL's fileURLWithPath:hfsPath
(theString's writeToURL:destinationURL atomically:true encoding:(|⌘|'s NSUTF8StringEncoding) |error|:(missing value))
In fact, I just discovered that “dataWithContentsOfURL” doesn’t require the use of:
set theURL to (|⌘|'s NSArray’s arrayWithObject:(theFile as «class furl»))'s firstObject() to defined the triggered URL.
set theData to |⌘|'s NSData’s dataWithContentsOfURL:(theFile as «class furl»)
behaves flawlessly.
So, I may work without using POSIX Paths and without using the ‘complicated’ instruction.
I edited my original message (#11) accordingly.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 21 février 2020 15:54:15
I know that Unix is based upon POSIX paths but I never liked them.
I used them when there was no alternative.
Now that I may work without them, I drop them exactly as I drop the Finder when I don’t manipulate Finder’s windows or Finder’s selection.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 21 février 2020 17:17:11
