I’m not sure what I am missing here.
I’m trying to take a string “R O L” and remove the spaces from it.
I have
set theString to "R O L"
set ASTID to AppleScript's text item delimiters
set AppleScript's text item delimiters to " "
set theStringItems to every text item of theString
set newString to theStringItems as string
set AppleScript's text item delimiters to ASTID
return newString
theStringItems " {“R”, “O”, “L”}
newString = “R O L”
Why doesn’t newString = “ROL”?
Hi Scott,
set theString to "R O L"
set ASTID to AppleScript's text item delimiters
set AppleScript's text item delimiters to space -- or " "
set theStringItems to every text item of theString
set AppleScript's text item delimiters to ASTID -- set back to empty string
set newString to theStringItems as string
return newString
gl,
kel
I had actually corrected that as you were responding, apparently.
My results were with
set AppleScript's text item delimiters to " "
Ohhhh… you swapped the combination of the newString after the delimiters reset.
Got it. That was dumb.
Hi kel.
There’s no point in using a variable to store and restore the TIDs if you’re then just going to assume the value’s an empty string. 
You should explicitly set them to an empty string, do the coercion, and then reset them to the stored value.
Hi Nigel,
I thought of that afterwards. Either they were set to non-empty string or not. It contradicts itself.
Edited: I’m still trying to get over that Apple fixed the AppleScript text item delimiters so that it resets to {“”} on each run.
Edited: Scott, whtat Nigel is saying is that you should set it to empty string separate from resetting the text item delimiters. Like this:
set theString to "R O L"
set ASTID to AppleScript's text item delimiters
set AppleScript's text item delimiters to space -- or " "
set theStringItems to every text item of theString
set AppleScript's text item delimiters to "" -- set delimiters to empty string
set newString to theStringItems as string
set AppleScript's text item delimiters to ASTID
return newString
Thanks for clearing that up.
Hey Scott,
Nothing wrong with using TIDs for this job. They’re very fast. But here are some alternatives:
Using sed (stock OSX):
set theString to "R O L"
set newStr1 to do shell script "sed 's! !!g' <<< " & quoted form of theString
Using tr (stock OSX):
set theString to "R O L"
set newStr2 to do shell script "tr -d ' ' <<< " & quoted form of theString
Using the Satimage.osax:
set theString to "R O L"
set newStr3 to change " +" into "" in theString with regexp
Using ASObjC_Runner:
set theString to "R O L"
tell application "ASObjC Runner"
set newStr4 to look for " +" in theString replacing with ""
end tell
Using regular expressions you can account for more than one space or a mixture of spaces and tabs, etc.
Hello…
This sifts out tabs, spaces, and punctuation marks as well, leaving you with just characters.
set {tids, AppleScript's text item delimiters} to {AppleScript's text item delimiters, ""}
set theText to "R O L"
set {theWords, AppleScript's text item delimiters} to {every word of theText as text, tids}
Scott, you should know that using do shell scripts are a lot slower because of using Apple Events, TID’s are without using Apple Events. Just so you know.
Everybody seems to be focused a lot on sed lately but for such an simple task bash has already an solution. When using bash only commands and built in regex you won’t spawn an new process that needs to be launched. Like the non Apple Event solution is already better than using an Apple Event at all, I think this is an better solution when you insist to use an do shell script.
set theString to "R O L"
do shell script "str=" & quoted form of theString & ";echo ${str// /}"
Just to show you how you should do this in bash otherwise, I still prefer the TID solution in the first place.
Hello.
You have been logging the event log for a do shell script in the terminal, haven’t you?
-I think a do shell script should take something around 20 millisec to set up, as a performance overhead (forking, exec, setting up the pseudo tty). The viritual memory, and copy on write technique, makes it really cheap to spawn a subshell, nevertheless, you’ll have to do something, something that is a t least more than a line of input, to justify it in time and resources, if speed is the criteria.
The critera IMHO should be readability, and reuseability, but in practise we seem to land on speed, all the time. 
Not really, something I know from osax. They are extensions of AppleScript but they still need to send an Apple Event to the Apple Event Manager.
For the record: do shell script doesn’t use an pseudo terminal (TTY).
The criteria to me, my clients and end users are in practice is efficiency (usage), speed (responsiveness) and reliability. Clients and end users don’t care about readability or reusability (directly). They’re the people who pay me and clients are always right :). Of course the developer has to develop in his most comfortable environment which suits the job, so the software is written at it’s best. Clients pay programmers more money an hour than accountants and they only pay that to get a good solid piece of software in return.
I know we’re talking AppleScript and not C, PHP, Objective-C, C++ or any other popular programming language. AppleScript is used for half the time for own usage and hobby but IMO the guidelines and rules of programming remains the same, hobby or not. For many out here AppleScripter is part of an learning curve (to other programming languages) so you should take programming serious in here too.
Not everybody, me not!
Honestly I’m quite concerned about turning MacScripter into MacShellScripter for geeks and tinkerers.
For me the criteria is just effectivity
True, I have to admit that I catch myself off guard so now and then too using unnecessarily a do shell script.
The primary consideration on a help forum should be the help you’re giving to the original poster. This means answering the question actually asked (ie. is it “Give me a script”, or “How do I do this?”, or “Please help me to understand this”?) and trying to gauge from the post what sort of reply the OP’s likely to be able to understand or use. Is he/she apparently a non-expert having a go at learning AppleScript to use on their own computer? Or is it obviously a professional who’s grown up living and breathing some other language and is finding a necessary switch to AppleScript confusing or frustrating? Is there anything about the question which suggests it may the wrong question or that not all the relevant facts are being given? Etc. etc.
In most cases, “Try this:” followed by a brilliant but inpenetrable and uncommented piece of code clearly beyond the OP’s understanding is the wrong answer.
Similarly, a barrage of methods all different from the one to which the query pertains, some of them requiring the installation of third-party software, is also likely to make the OP wish they’d never asked.
Posting entire scripts which are only tangentally relevant to the query and filling the rest of the thread with update notifications is intolerable noise and a waste of everyone’s time and bandwidth.
In this thread, kel1’s reply in post #6 is a shining example of a right answer. He’s tackled the exact question asked and has been at pains to ensure that Scott understands both the answer and the later correction.
That said, of course, there’s no reason why the various merits of different approaches shouldn’t be discussed for completeness. These are often helpful to others reading the thread either now or in the future. But it should be clear to the OP that these are “matters arising” being discussed by other forum members and they shouldn’t compete for the OP’s favour unless all the replies given so far are unsatisfactory by the above criteria.
I am guilty of not commenting responses. We should make an effort to follow a policy of commenting all scripts which may be confusing for those starting out. All shell scripts, especially those which use regular expressions, should be thoroughly explained.
Hello.
I might not allways have done exactly like Nigel suggests, but I agree fully in that the primary concern should be to give the OP an answer he/she can relate to.
To those going after shell scripting, many times it seems like sed, Satimage.osax and others being more suited to the job than AppleScript, that is, you can produce a correct solution to a problem with those, than AppleScript, then IMHO it is just common sense to use it, unless the OP has specifically asked for the solution to be in AppleScript.
A couple of more things:
If the do shell script is to return output, then you have to do that through a pseudo terminal, maybe you can do it just be redirection, but it should be far more comfortable with a pseudo terminal. I am sure I read it somewhere that it was set up with a pseudo-terminal. And! I do take scripting seriously.
And I find no geekyness in different ways to do stuff here, it is more about knowing what you are dealing with, and different solutions to problems always come in handy. Sed’s algorithm for regexp, should for instance be approximately 7 times faster than the one that is used with cocoa. Now, writing stuff with cocoa, and core foundation for that matter, gives you a lot of speed, you dont have in AppleScript, so in order to produce something that is tolerable, with regards to speed, you’ll have to have something else do most of the work, and let Applescript be the part that glues it all together.
I think that’s one of the points Nigel is trying to make. For some it’s common sense but for those who has just read a few pages in his book about AppleScript, it’s totally not. We can post complex code but we should add comments or explain how it works. Our pre knowledge is based on thousands of posts we’ve read and written before, the OP doesn’t have this knowledge as well but we continue to write our posts based on that knowledge anyway. For those it’s like flying an fighter yet after your first theory flying lesson.
Now that could be interesting, couldn’t it? 
But I actually do try to qualify the reader, but that is hard, and it is far more easier to read a post and think the asker to be far more knowledgeable, that he/she turns out to be some posts down the thread.
I don’t understand how the do shell script, can give the output back, collect it, and make the programs behave correctly, if it doesn’t use a pty device (pseudo terminal).
I wonder what exactly you did mean by that.
To execute code and return values back isn’t done by an tty device that’s also been used by Terminal application. The tty’s responsibility is that you can send code with your keyboard, get prompted and see the results on your screen. But the actual code is ran by an shell which do shell script uses directly and not through an tty device. There is no keyboard input, no prompts and no display needed in an do shell script.
The paragraph above was personally the second paragraph was about sharing here on MacScripter. I meant that even if you use AppleScript for fun, some people here are learning AppleScript which means that the code we share should be taken seriously. Not that I’m implying that nobody doing their best, on the contrary, but just saying that we should keep continuing doing that.