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.
Hello.
I am a bit hair sore about the second comment. But if you put it that way. But still I want to say, that I produce stuff, when I have good ideas, (in my own mind), and I test it, as duly, as I think proper, when I write it. But, occasionally, it do happen that I haven’t thought of everything, when I post it. And if people then discover a bug, then they are welcome to say that, and I’ll fix it, but some staged/planned testing of everything, that is not going to happen, there is no room for that. The alternative is to not post here. I am careful to make stuff work under the conditions I see, as good as possible. But sometimes, I have to stop somewhere, with a quality I can live with (SafariSearchTabs). If someone then want something more, they are welcome to either fix it themselves, and share the result, or send me money!
As for the first one, you really create a pty device, by using some pty mechanism, you can read about in Advanced Unix Programming, the reason for doing so, is to give programs that run in shells, the impression that they still are having, at least an equivalent to a tty. It is like setting up a primitive server, so you can get at the input and output of the streams. (It works the same way as the program you use for recording input output of a shell in a terminal window.
Try ls /dev/pty/*
The article at Wikipedia aren’t that good in this case.
I have actually programmed a pseudo terminal, and to me, using a pseudo terminal is to emulate a terminal device through files. I’ll keep you informed if I upload the code to github.
:|I’m sorry about that. Please read it in context, I first implies that AppleScript is some kind of second hand language, the last sentence is correcting that point. The word ‘you’ could be better written down as ‘it’ because it means in general not to you me or anyone in specific.
I don’t really understand your answer about tty and do shell script but I also found something else out. Try the tty command in terminal and in do shell script. In do shell script it will return an error saying that there is no tty. Also to run an input output wrapper around an shell like tty or pty the shell needs to be invoked as interactive. Do shell script are shell that are non-interactive.
That is the whole idea behind the pty you fake the context of a terminal device for the utilities that are executed through a system-like call, there is still fork/exec in the bottom of it. But the utilites may think that they are executed the regular way, and you get the output like you had dup’ed a stream, (the utility thinks it justs sends it to stdout, the same with stdin, that is the way you send think in, no much different than a pipe() call, but different enough, so that the utilitiy thinks it is working from a terminal, which is sometimes necessary to make stuff just work.
I sent you the pty-link in the previous post, youo just don’t use pty for arranging a physical terminal, but I think the login process uses pty for doing just that, but then it hands it over to a real terminal.
This might seem like an unecessary step, but some programs, expects linebuffered input from /dev/tty, and other redirect output to /dev/tty, or write directly, you would use pty for setting it up, so you can intercept it, see the graph on the wikipedia page, that I linked in, in my previous post.
And this is the way I believe the do shell script works, and I’m still sure that I have read that somewhere.
You can also take a look at the source of this simple script command You’ll see that the paren’t process designates it self as master, and the subshell as the slave, that gets input it believes comes from stdin, and delivers, to what it thinks is stdout, without never really being in contact with a terminal.
I know what pty does and tty and the differences between them. I meant that I didn’t understand your reply against my post. Are we talking about terminal.app or do shell script? Because there is no pty nor tty used by do shell script it was confusing to me to which you relate. I assume it was an general post about pty and tty and not really in response to my answer to your question.
Hello.
What I meant that I believe, is that do shell script uses a pty construct, to “hijack” stdin and stdout, when it performs the system calls, in order to intercept stdin, stdout, and stderr. (So the executed shell-utilites behaves as they normally would do, with linebuffering (awk), and what else they need to perform properly.
The way a pty program works, fits beautifully by the way you can send a job to the background with stderr and stdin redirected to /dev/null when you use do shell script by the way. Because then the pty-layer will just return immediately, after having instigated the “job”.
I am not sure (totally) if there are pty’s involved when executing a do shell script, but I find it very natural if there were, as that would have been the easiest way to make the do shell script command work.
Nice blog.
Edit
I know, a terminal session is also called a pseudo terminal, but if you use the ps command, you’ll see /dev/tty, and you can use ttyname or just tty, to get the tty name.
The ptty’s I am talking about, doesn’t give a /dev/tty back, they won’t work with tty or pty name, but you should be able to find a /dev/pty somewhere.
Well, having written this, I fired up lsof to see, and I didn’t find any pty’s, I did however find either streams, or unix sockets. The streams might be more like System V streams (and there they work with pty’s ). So this question is really open. The technique for implementing a do shell script, should however be much the same way as you would install a pty as layer between shell commands, and the program invoking it, like telnet, rlogin, ssh, session and tpmux. (In principle).
Hi guys.
Would you mind taking this discussion somewhere else? It’s way off-topic for the thread.
Consider it done