-- http://macscripter.net/viewtopic.php?id=27629 Martin Michel
-- I am returning the currently used decimal separator
on getdecseparator()
set strnum to 0.1 as Unicode text
set decseparator to character 2 of strnum
return decseparator
end getdecseparator
So either you haven’t set your locale, or your awk doesn’t respect locale? (I get “0,133975” back from the shell script).
Hmm, or is it me? ( I have obviously to feed awk a number with a period as a decimal separator. I think I can’t remember having adjusted the locale of this shell. Tiger. I think I’ll try setting up the deimal separator there to, but for now I think a similiar shell script for figuring out the decimal separator for the shell to be appropriate.
(Spotlight takes a period as a decimal separator even though my decimal separator is a comma!)
I use Spotlight for calculations of sines, cosines, and what not.
Edit I went into the /usr/share/locale/no_NO.UTF-8/ and read the LC_NUMERICS
it looks like this:
,
.
3;3
I then went and had a gander into /usr/share/locale/en_US.UTF-8/LC_NUMERICS
it looks like this:
.
,
3;3
According to IBM! do the LC_NUMERIC have the contents of
I can hardly see that as anything that either awk, has to be configured another way, than by the LC_LOCALE system, or it just doesn’t respect it internally, but it does give correct output, so it respects it when it writes data out.
No, my two example coercions completely ignores locale settings and respects only AS notation (which is equally to US). So if your locale is Dutch (German have the same issues) or US you can always use that code; it’s universal. In other words when the decimal separator is a comma or period in your locale you cna use the code and don’t need to check it.
I have set my locale correctly, and AWK does respect locale either but the problem isn’t there. When I say “1234.5678” as number AS looks at my local settings and makes 12345678 integer which is correct for my locale. Because Dutch (like German) number notation is x.xxx.xxx,xx and in US it is the other way around; x,xxx,xxx.xx. So a number like 1.1 is equal to 11 because al periods in numbers can be ignored/removed as commas can be ignored/removed in US number notation.
EDIT: Nailed it. Do shell script doesn’t have a locale set after all. when I use
do shell script "export LANG=nl_NL.UTF-8; awk 'BEGIN{print 0.1*58}'"
it works correctly but I would like to have to work input the same way.
set angle to 60
set lumen to 0.11
set candle to 0.13
--From lumen to candle
do shell script "export LANG=$(defaults read -g AppleLocale).UTF-8;awk -v lumen=" & lumen & " -v pi=" & pi & " -v angle=" & angle & " 'BEGIN {print lumen/(2*pi*(1-cos(angle*pi/360)))}'"
--from candle to lumen
do shell script "export LANG=$(defaults read -g AppleLocale).UTF-8;awk -v pi=" & pi & " -v candle=" & candle & " -v angle=" & angle & " 'BEGIN {print 2*pi*candle*(1-cos(angle*pi/360))}'"
It’s very complicated but, hey, at least I can say it’s without extra plug-ins :P. Because I declare variables on as arguments the locale is respected as input as well as AWK’s output, so no coercions needed at all.
EDIT: Havent’s read your edit:
Correct, bash respects locale settings, AWK don’t. That’s why i declare AWK variables with the command line interpreter in the code above. My do shell script uses almost an complete empty shell which doesn’t contain locale settings while terminal uses a very heavy shell where a locale is defined.
I’m sorry for that! I have set up my Environment.plist, so that what I get when I test in the shell, is what happens when I perform a do shell script! I could of course remove that, as most people probably don’t use that, or export the settings for starters in a do shell script, when distributing, so that people will get the expected behaviour!
I have to use periods as decimal separator for variables in awk, even though I use my locale! So I think it is problematic to make awk behave differently in this.
I should have sent away the do shell script like this:
No apologies needed, It’s making people only confused why some commands will succeed in terminal and won’t in a do shell script and visa versa. I did it the other way around, in my terminal application, I have setting where I set locale variable is turned on when start up turned off (preferences->advanced). Well our goals are the same: to get both shells similar.
I’ve used a substitution command $(defaults read -g AppleLocale) in my example to make the do shell script using the same locale as AppleScript so everybody can use it.
I think my approach, in this case would be to send with export LC_NUMERIC, since that is faster, that way, I can force the shell by the user to use the same settings as me. (in this case)
In other cases, I’ll first try to read LC_ALL, and if that isn’t set, then use your approach!
If you worry about a LANG or LC_ALL that’s already been set you can still use my example but have to replace LANG for LC_NUMERIC, this way you’re certain the numbers will be handled correctly. If LC_Numeric is already been set it will be overwritten. This way you can spare yourself some checks:
do shell script “export LC_NUMERIC=$(defaults read -g AppleLocale).UTF-8;awk -v pi=” & pi & " ‘BEGIN {print 2*pi}’"
Actually no, what I want to do, is to write the code, using my decimal separator, then I force the user to use no_NO.UTF-8 for LC_NUMERIC, so my script work properly. (World Domination :D)
I want to add, that I haven’t tested the approach yet.
It might not succeed.
I must say that all of this, has made me much more conscious about using Osaxen, now it is just not speed, not only just about the convenience of having a commmand available, but also the convenience of having a command that you know will work as expected, when it is installed!
With shell tools, users my install from any source, so in reality, when it comes to tools like awk, that may come in several flavours, you have really never any guarantee that it will work, what so ever!
By default Mac OS X always used the same type of AWK. When someone installs another AWK it’s not overwritten or anything. The process name will be gawk, mamk, or jawk for instance. Because the BSD system itself uses AWK as well it’s not wise to remove AWK or overwrite AWK with another type of AWK because the result can be that the system won’t boot. Therefore, if you don’t know what you’re doing, leave it as it is!
The guarantee thing you talk about won’t apply. I don’t have to consider, no matter what programming language or way programming, someone who apparently doesn’t know what he’s doing and messed up his machine. Also I’m allowed to used variable names (like ln) but someone using SatImage can’t. OSAX gives also compatibility issues. I prefer to give an answer that can run on a clean installed Mac OS X system (this is how all my machines in my development department are). No offence, but looking at your comments your machine is far from default.
I understand your reaction but I keep in mind what the TS asked. He doesn’t want a third party OSAX or Application, I considered that in my answer and won’t mention it.
Well, it may not be your fault, but your code may still not work, on the users machine, there is one thing to do, and that is to hardcode the paths to known utilities by the way.
And it may not even be the users fault, maybe he installed something from macports, (hypothetically), or from homebrew (that by the way moves the source tree of opendesktop.org aside!!!), or what have you, that has some dependencies that gets built alongside your tool.
What I basically mean, is that as long as you install stuff from repositiories you are at risk. Maybe not with awk, but with a lot of other tools. it is like in the traffic; you may not be the only idiot on the road. (general “you”, or I for that matter! ) The main thing must be to fix the errors, and not place guilt, but it is of course ok to know who to blame!
I have to give you right in that, ln being a good example! But now that you are aware of it, you should cease using it as a variable name, as by now you know it may break your code! But I have to say that I don’t usually part out functions, but it would actually be a good idea, to have scripts that search through scripts, with the reserverd word of an osax, when using an osax is what is wanted.
Maybe the machines in your department are clean, but not your! My machine is of course configured in a way that I like it to be. That is one of the reasons for not using windows!
)