Retrieving terminal output status?

Perhaps you can give me an example of how "set exitStatus to do shell script "command; echo $?" will ever have any result other than "0"?

Because my understanding is that everytime you call "do shell script" in AS, you get a fresh new & Unique shell to execute the command(s) that have no way of picking up where the last "do shell script" left off. Therefore I must be wrong in what I read because it would mean you could never get any result other than "0" with that command that I reffered to as useless. So please prove me wrong.

LeonieDF gave you an example, which you acknowledged.

The semicolon between the command the the "echo $?" allows more than one command to be executed in the same shell session. The shell saves the completion status of every command in the shell variable $?, the echo command it just sending the contents of $? to standard out (stdout), and the Applescript is putting the output from stdout into the exitStatus variable.

You could have a long serious commands separated by semicolons, vertical bar | pipe symbols, and they would all execute as part of the same shell session. You could even invoke a shell script that would be 1000's of lines long and it would be invoked in that shell session (along with subshells invoked by the initial shell session).

You are connect that each and every "do shell script" starts a new shell session. But you are wrong in that multiple commands issued in the same shell session start unrelated shells.

Am I hyjacking?

Yes in that you are taking control of this thread, but are unable to give any credit to anyone for information you find valuable. Then again, maybe you have not found anything valuable from any of the contributes answering your questions.

I came to this thread while looking for a method to read the terminal app output from within AS because "do shell script" cannot continue multiple commands from where the last "do shell script" left off. It does however make an easy single line shell that returns a clean result good for a one time only thing. Even for multiple commands on the same line, but not for functions that change depending on the output from the shell.

I have found the solution was to use terminal, and the problem was "do shell script" does not execute the same bash as terminal, nor can it continue where it left off.

But that was not necessarily what the original author, Hi], was asking for. The Hi] seemed to be satisfied with the answer given by John Maisey. Hi] gave John 10 points for his answer.

The last paragraph can be parsed 2 ways. a) the version of bash execute by the Terminal and by "do Shell Script" are different, and b) the Terminal is running a separate session from the session "Do Shell Script" invokes. a) would be wrong, in that it is the same bash program run by both, and b) would be correct in that the are running unrelated shell sessions.

You appear to want the ability to have co-processes where the process running the Applescript can interact with the process running the shell script. While this is possible, co-processes are more difficult to setup and control.

You approach was to have a Terminal session running one shell process and Applescript asking the Terminal session to read its display buffer.

My "hyjacking" was to correct the incorrect statements made by others so that other people who are trying to solve something and find this thread find the answer as well as know some of the information posted on this thread was dead wrong.

But you assume Hi] did not like his answer, and there is no evidence this is the case. You are trying to impose you view of this thread on Hi] and the users that posted answers that Hi] seemed to like.

If you have started your own thread, you could have defined the discussion by stating your needs, and not trying to alter Hi]'s request.

I am not looking for points, payment, kudos or political he-said-she-said.

Who said anything about you getting points. Then again, if Hi] wants to give you points, he is welcome, as he started the thread, and he is the one that gives out the points for this thread.

Any questions you asked (like how is it possible to get a non-zero status returned), you cannot give LeonieDF any credit for providing a solution. Only Hi] can do that. If you have started your own thread, you could have described your needs, and any useful information you received, you had the option to give that people giving those replies points (the only payment they get for donating their time and knowledge to this forum).

That is hijacking a thread.

Just correcting people that post pointless code such as the one you quoted me commenting on as being useless because it will always return "0" no matter what. Right?

Unfortunately you were not correcting the post.

BobHarris,

At this point you are nothing more than a hostile troll attempting to defend yourself because you are wrong.

Why are you pointing out that I acknowledged something I agreed is possible unless to build a long hostile debate to try to repair your sad ego?

You are connect that each and every "do shell script" starts a new shell session. But you are wrong in that multiple commands issued in the same shell session start unrelated shells.

I am correct? fine, I don't care, I can admit when I am wrong, how about you? Or are all your posts an effort to defend your ego?

I NEVER said that "multiple commands issued in the same shell session start unrelated shells".

Where did you even get that fabricated lie? That is a retorical question because I already know I never said that.

What I did say was that each seporate "do shell script" starts a seporate shell session unrelated to any other session before it. If you use multiple commands on the same line seporated with ; then of course they are in the same shell session. In fact you are mimicing what I already said, because I already said that while explaining the limitations of "do shell script"

Look I am not going to read or respond to the rest of your comment because you are a troll.

I am not "hyjacking".

I am not "taking control". If I took control of anything, I would have deleted and banned you for trolling, sir.

My giving a comment does not give me "power", but apparently you think it does which is why it is so important to you.

I am just correcting the facts with what does, and what does NOT work.

I could pick appart your responce and find more lies in it, but the conversation has degrated into you bickering and nobody cares and nobody will read this non technical babble or yours. The thread is dead now. You killed it. Nobody wants to read you fussing about how right you are and wrong I am. Get over it.

Not only is that THE solution... it is simple easy, and you mislead people by saying "there's no easy way to capture the output

Well, not only does your code not come close to the OPs original question (it doesn't - try it some time), but it's also a FAR cry from 'simple'.

Sure, some people might you consider your (flawed) 25-line script to be simple, but the nature of the question from the original post clearly implies the OP is a novice (no offense, hi]).

And if you think your (flawed) 25-line script is 'simple' compared to a one-liner:

set myresult to do shell script '/blah/blah -blah"

then you and I have different perceptions of the word 'simple'.

Camelot,

My code is off topic and not even close?

Interesting because the OP did ask "terminal output status and store it into a variable once a command has been executed?" And I am the ONLY person to provide the method to get "Terminal output... into a variable"

Terminal is an application in the Utilities folder.

Shell is not something that "implies the original poster is a novice"

You are attacking the wrong reply of mine. It is not 25 lines, it is 1 line.

I just found that you can use "set shellOut to contents of window 1" inside your tell application "Terminal" script to get the data you seek!

aka

set shellOut to contents of window 1

Sure you have to put that inside

Tell application "Terminal"

do script "command;command;" in window 1

set shellOut to contents of window 1

end tell

That is one line not 25 and it is in Terminal, not AppleScript faux Shell.

Last I checked he asked for Terminal output, not AS shell output.

Next time you want to attack someone, get your information right.

You are just saying that because you are dead wrong.

As I said before you mislead people when you write

Camelot wrote:

then there's no easy way to capture the output since AppleScript has no knowledge of the shell process, or when it completes

No easy way? Try one line. set shellOut to contents of window 1

No knowledge of when it completes?

if thisTab is not busy then

Applescript has a wonderfull feature called the Dictionairy. Read it sometime and you will see it does know when the shell process completes.

Stop trying to pretend you arnt DEAD WRONG.

I found this because I wanted to google the same thing as the OP and you told me it was impossible.

Your wrong.

So I provided the answer and corrected you for posting lies.

Now you throw a hissy fit and say I am off topic because I told you AS knows when the shell is completed, as well as how to get the Terminal output in a single line.

That is the OPs question, and I provided it for everyone else that finds this via google.

I fear this discussion has degenerated beyond reasonable bounds, way past anything productive for the original poster and venturing into personal insult territory. You, sir, are wrong. I'm sorry you can't realize that. In the interests of trying to restore civility, though...

Interesting because the OP did ask "terminal output status and store it into a variable once a command has been executed?"

You're right, he did. Your code example (at least the one I was referencing and that you claimed would do so) did not do that. It just didn't.

And I am the ONLY person to provide the method to get "Terminal output... into a variable"

Granted, you did do that, but you didn't solve the OPs problem. He didn't want the contents of the Terminal window, he wanted the output of the command he's using. Your 'solution' still requires text parsing, and also breaks if there's more than one screen's worth of output from the command (for that you need to reference the window's 'history', not its 'content', with all the associated overhead that brings).

In my experience, in 99% of such cases, people use Terminal.app because it's easy and obvious, not realizing that AppleScript has its own, functional method of invoking shell-based tasks.

Indeed, the actual response that got a 'Solved' mark (about 20 minutes after the original post, I might add) did exactly that - used 'do shell script' rather than Terminal. On that basis alone the rest of the discussion could be regarded as moot.

You are attacking the wrong reply of mine. It is not 25 lines, it is 1 line.

I see now which answer you were referring to, so my apologies if I was referencing the wrong reply. I don't see the point of the 25-line script, though...?

Yes, you are correct that you can query the busy flag, and yes, you can get the content (or history) of a window, and yes, you can parse that data to get the output of a shell command, but that is still way more work than a single line in AppleScript. Show me a simple, functional, Terminal.app-based AppleScript that comes close to the ease of 'do shell script' and I'll reconsider my stance.

Applescript has a wonderfull feature called the Dictionairy

Actually, I think it's called the Dictionary.

Read it sometime and you will see it does know when the shell process completes.

Clearly you don't realize how versed I am in AppleScript.

Stop trying to pretend you arnt DEAD WRONG.

I'm not dead wrong. And I believe the contraction is spelled "aren't".

I found this because I wanted to google the same thing as the OP and you told me it was impossible.

I don't believe I used the term 'impossible' anywhere in my posts. hmm.. nope. Not there.

I did say that it is easier, in most cases, to use 'do shell script'. A position I've maintained for years.

I also said that scripting Terminal.app might get you there, but it's more complex in most cases. Another position I've held for years. In fact, now that you've prompted me to go through the entire thread to re-acquaint myself with what was (and was not said) it seems that you seem to have issue with anything that anyone (well, at lesst BobHarris and myself) have to say.

Your wrong

My wrong what? Oh, hang on, did you mean "You're wrong". My bad.

So I provided the answer and corrected you for posting lies.

At most, you provided a partial answer. And I did not lie. Do not accuse me of lying.

Now you throw a hissy fit

I don't think I'm the one having a fit here.

and say I am off topic because I told you AS knows when the shell is completed, as well as how to get the Terminal output in a single line.

I didn't say you were off topic, just that your answer didn't really address the OPs original question or issue.

Semantically, there is a difference between AppleScript 'knowing' something and AppleScript 'being able to go out and find something'. Subtle, maybe, but that's clearly not your concern.

In this instance, AppleScript 'knows' when the script flow continues, or when some external trigger notifies the script (such as 'do shell script' returning some value).

This is intrinsically different from AppleScript repeatedly polling Terminal.app "are you done yet? how about now? now? now...?'

Plus, as I've already stated, there is a difference between 'Terminal output' and the output of the command. They do not equate.

However, it if makes you feel better - you are absolutely, 100% correct that you can use AppleScript to grab the contents of a Terminal.app window. Congratulations. You still didn't solve the OP's question, though.

I'm done.

I'm just going to chime in here to note that no amount of argument is going to make Camelot's assessment any less correct. You've missed it Macster, sorry. That happens to all of us at one time or another. If you still don't see how you're wrong, I'll try explaining it to you from a different perspective (sometimes that helps), but you really ought to shift out of defense mode into wrap-your-head-around-it mode.