Well strictly speaking they’re not, although they can apparently be so coerced. They’re two thirds of the trio ‘yes’/‘no’/‘ask’: possible values for the ‘replacing’ parameter of certain commands.
I seem to recall that in the past, people would occasionally use booleans instead of ‘yes’ and ‘no’ and wonder why their scripts weren’t working. Nowadays, booleans can apparently be used instead of ‘yes’ and ‘no’, but not vice versa.
store script fred in file ((path to desktop as text) & "Fred.scpt") with replacing -- OK instead of 'replacing yes'.
if yes then beep -- Not OK.
Ahh I see, that is were the yes and no is coming from. But yes and no, is also the boolean values for true and false in Objective-C, I thought it was a connection there. Especially since they are uppercase, and the results of the defaults properties are too.
This works outside any dialogs and such, so I guess yes an no, are proper boolean values now.
set success to true
if success = yes then
A final obseveration, is that “0” is true when dealing with do shell script, that is, a command is exeuting properly, when it returns “0” as result. So one would have to invert the result from from a do shell script if one used a construct like
To say how it went, or as a result from one of the test commands.
If this is successfull you would have to coerce it like
set doShellRes to not (theRes as number as boolean)
I also guess it breaks if the error is higher than one, so you would actually have to put it inside a try error block anyway!
(The idea behind this was to code less, to leverage the automatic coercions, and avoid superfluos code.)
I am awfully sorry about that one! I should have used true in the test and not yes !
While I am at it, I’ll elaborate on the ; echo $? and just state that you can add it on the end of a do shell script command, then you effectively mask a non-zero return value, so there wouldn’t be any need to put the do shell script command within a try block. This obviously only works, when you require no output from the do shell script command.
Also keep in mind that it works for processes that can only return a 0 or an 1, there are many processes who returns other values on error. With the ; echo $? suffix you’re suppressing previous errors from command post the ‘;’. Better is that you’ll use bash expressions instead and echo an integer or boolean strings from bash.
I prefer a suffix like “&& echo true || echo false”. When you don’t redirect the stdout the last line of the output is the boolean value so you can choose this behavior to your likings. When I won’t need the stdout I redirect it to /dev/null
I prefer the same command. && echo true || echo false
construct. Another way to do it, for the sake of not getting any result, would be to put ; exit 0 as the last command.
One thing I am not sure if everybody is aware of, is that you can group commands in a subshell, to collate all its output into one stream, which may be handy when using the do shell script. like this:
set collOutput to (do shell script "( echo \"Start of output\"; echo \"middle of output\" ; echo \"end of output\")")
(In order to make a one liner, without having to create intermediary files.)
The last construct isn’t good for collating standard output in a do shell script,not even in the Terminal,(It seems when a pipe is the receiver, but you’ll see the effect if you redirect to a file. Then the subshell constructs sees to that all the output is redirected into that file.
do shell script "(export LANG=nl_NL.UTF-8); echo $LANG" -->""
It can’t be working like that because a subshell forks a new instance of bash into a new child process. When using process forking (instead of threading) you will inherit the same variables and values as the parent process, same way as the Apache web server works. The advantage of this behavior is that it’s much quicker on single processor machines than threading but eats more memory. I think the main reason is, same for server/client models, is that forking is more reliable than threading. So when can it go wrong? Well the subshell inherits all the variables from it’s parent process but not the other way around. Or even when you change the value of a variable in the child process it won’t be changed in the parent and visa versa (like in my example codes).
You’re example works the other way around. The parentheses, are very much used by shell scripters, to define some temporary variables that doesn’t inflict with the main script. For instance while loops are often placed between parentheses.
Another example that shows the limitations of export as well:
do shell script "(export LANG=nl_NL.UTF-8;date);date"
I think it’s very straightforward rather than funny when knowing how process forking works. Even if the variables have the same value (due to forking) they aren’t connected in any way with each other; they are two variables with the same value in different environments and no connection.
There are of course some tactics to copy variables into the subshell as in your code, but changing them still isn’t possible.