Re: "do shell" vs. Plain old AppleScript nomenclature
Re: "do shell" vs. Plain old AppleScript nomenclature
- Subject: Re: "do shell" vs. Plain old AppleScript nomenclature
- From: Graff <email@hidden>
- Date: Mon, 26 Jul 2004 14:46:34 -0400
You really don't need the complex if statements and the do shell
scripts. All of this can be done much more easily through straight
AppleScript. It will probably be just as fast and a lot easier to
understand. Here is a re-written version:
----
on NumPad(theNum)
--
-- takes in a number and returns a zero-spaced string
--
if (theNum < 10) then
return "0" & theNum
else
return "" & theNum
end if
end NumPad
on DateString(theDate)
--
-- takes in a date object and returns a string
-- of the format hh:mm AM
--
set theTime to time of theDate
-- following 2 lines not used
--set theMonth to month of theDate as integer
--set theDay to day of theDate
set theHour to theTime div hours
set theMinute to (theTime mod hours) div minutes
set amPM to "AM"
if (theHour >= 12) then
set amPM to "PM"
if (theHour > 12) then set theHour to theHour - 12
end if
return "" & NumPad(theHour) & ":" & NumPad(theMinute) & " " & amPM
end dateString
set theDate to current date
display dialog DateString(theDate) & return & DateString(theDate - 1 *
hours)
----
The first handler is there to easily pad out the strings so that a "9"
can be easily replaced with an "09". I put it in a handler because if
you use it more than once it will save you some typing and it will make
the script more readable.
The second handler takes in a date object and returns a string which
contains the time formatted as hh:mm AM
At the end I get the current date and then display it and the next time
zone (one an hour earlier). I don't need to directly calculate the
next time zone because all I need to do is subtract one hour from my
current time zone and then feed that into my DateString handler.
AppleScript handles all the little details such as did the new date
object cross from PM to AM or from today's date to yesterday's date.
- Ken
On Jul 24, 2004, at 11:02 AM, Darren Mahaffy wrote:
A hearty thanks!! to all who've responded! Some excellent suggestions.
What I've done is combine some of LuKreme's script with some of Ken's
re-do of my script.
The overall result is a shorter script and seems quite fast. Here's
the snippet (and of course, if it can be even better, then by all
means!)
--Get Time and Date and break into variables
set theDate to current date
set theTime to (time of theDate)
set theMonth to do shell script "date +%m"
set theDay to day of (current date)
set HourMin to do shell script "date +%I%M%p"
set theHour to text 1 through 2 of HourMin as string
set theMinute to text 3 through 4 of HourMin as string
set amPM to text 5 through 6 of HourMin as string
if first character of theHour is equal to "0" then
set theHour to character 2 of theHour
end if
if first character of theMonth is equal to "0" then
set theMonth to character 2 of theMonth
end if
display dialog "" & theHour & ":" & theMinute & " " & amPM
( I only use the display dialog for testing - I "set selection" in
BBEdit, normally)
=== truncated script ===
if theHour is "12" and amPM is "PM" then
set t to ("11" & ":" & theMinute & " " & "AM") as text
else
if theHour is "12" and amPM is "AM" then
set t to ("11" & ":" & theMinute & " " & "PM") as text
else
if theHour is "1" and amPM is "PM" then
set t to ("12" & ":" & theMinute & " " & amPM) as text
else
--NORMAL Time Stamp - Eastern Time-Zone to Central Time-Zone
set t to (theHour - 1 & ":" & theMinute & " " & amPM) as text
It was "shorter" to do shell script for the hour and minute, at least
in my estimation. If I'm incorrect in that assessment, please
indicate why.
Shorter is not all it is cracked up to be. First of all, you have very
little need for speed in this sort of script. Secondly, why sacrifice
readability and switching between scripting languages just to save a
few characters. I would say that you are better off keeping this in
AppleScript rather than switching between AppleScript and shell
scripting. Your script will be easier to understand and you won't run
into the slowdown that every invocation of a shell script brings about.
I get the month and all via shell script for breaking down date stamps
for weekends and holidays, i.e., "7/24". It was shorter than the
applescript way, as well, as I had to break down the month into
numeric variables to get "7/24".
Instead of this:
repeat with theMonth from 1 to 12
if month of (current date) = item theMonth of ,
{January, February, March, April, May, June, July, August,
September, October, November, December} then exit repeat
end repeat
copy item theMonth of {"1", "2", "3", "4", "5", "6", "7", " 8", "9",
"10", "11", "12"} to theMonth
I can use this:
set theMonth to do shell script "date +%m"
if first character of theMonth is equal to "0" then
set theMonth to character 2 of theMonth
end if
It seems that the less-verbose way would be more efficient, yes?
Not always. First of all if you are using AppleScript 1.9.2 or later
you can simply do:
----
set theDate to current date
set theMonth to (month of current date) as integer
----
If you don't want to rely on AppleScript 1.9.2 then you can do this
simple handler:
----
on MonthNumber(monthString)
set theMonths to {"January", "February", "March", "April", "May",
"June", "July", "August", "September", "October", "November",
"December"}
repeat with monthNum from 1 to 12
if (monthString = item monthNum of theMonths) then
return monthNum
end if
end repeat
return 0
end MonthNumber
----
It should be fairly fast and it is simple enough to work just fine.
For the second part of the (=== truncated script ===) where I have to
fix a couple of anomalies for EDT -> CDT time-stamping, I'm wondering
if there's a better way to do it? Is there a setting I can set to
automatically set theHour back an hour w/o having to break it down as
above? Obviously on the hours above it isn't just theHour than has to
be reset, the amPM does as well.
Another question - is it truly necessary to put "as text" at the end
of the "set t to (theHour blah blah) as text"? I notice some do and
some do not. Curious as to the why of it.
You put "as text" in order to coerce a variable from one type to text.
For example, if you have a number and you want it explicitly as text
then you would do:
set theString to theNumber as text
You can also do:
set theString to "" & theNumber
This coerces the variable theNumber to text. It does this because the
first part of the statement is a blank text string. AppleScript
automatically attempts to coerce all elements to the right of a
concatenation operation (&) to be the same object type as the object to
the left of the concatenation operation. If it can't do so then I
believe it tries to make them all into a list.
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.