I am stuggling trying to use bc to convert a big number to base 36. I want to change the names on my digital camera files from the current: 20050515173205999 to something shorter and easier to read like: 73u2u1m2n.
I have seen some base conversion routines for applescript but they all require integer math and my number is way too big. Besides I think think that the Unix bc command will be much faster.
I am trying a script like this:
set theNum to text returned of (display dialog "Enter a number:" default answer "")
set theNum to theNum
set s to ("bc --quiet" & return & "obase=36" & return & theNum & return & "quit" & return)
set temp to (do shell script s)
display dialog temp
I modified this from a script on p 363 of Applescript: The Definitive Guide by Neuburg
set theNum to text returned of (display dialog "Enter a number:" default answer "")
set t to path to temporary items
set posixT to POSIX path of t
set f to open for access file ((t as string) & "bctemp4") with write permission
write "obase=36
" to f
write theNum & "
" to f
write "quit
" to f
close access f
set s to "bc --quiet" & " " & quoted form of (posixT & "bctemp4")
display dialog (do shell script s)
neither script is working both getting a “” returned from the do shell script command. At least I can say my script works as well as the textbook version 
Help anyone?
Thomas
Doesn’t seem to get your answer when you just do it in bc via the terminal, either.
Did you recognize that the code breaks down like this: 2005/05/15 17:32:O5 999, i.e. the date in sort order. Seems to be saying that you took the picture on the 15th of May, 2005 at 5:32:05 PM. Don’t know what the 999 is telling you. Wouldn’t it be easier to just parse the number as a string, rearrange it in your preferred date format, and add the last three digits?
You are exactly right about how the date breaks down. BTW the last three digits are just to allow for duplicate images with the same date-time when resolved to the second. A thousand images per second is pretty crazy but I can imagine situations where there might be more that 100 images per second.
The reason for converfing to base-36 is to make the file names easier to read in the finder and file-open dialogs. Now when I try to open a file in Photoshop the last 6 digits are converted to … because the file name is so long. The date string is 14 digits if one uses an extra two digits for distinguishing duplicate times then you have 16 digits, which is pretty hard to read without adding some group separators. If you split the 16 digits into four goups of 4 then it takes three underscores or dashes to divide the groups and you have a 19-character file name.
I find ‘5hfbbkd5yhq’ much easier to read than 20050515173205999 and it displays much better in file listings than 2005_0515_1732_0599_9. It takes 11 base-36 characters whether I use two digits at the end for counting or three so I picked 3. The 11-digit base-36 name can encode 1000 images per second for a 13,000 year span.
B.T.W. the output from the bc function looks like: 05 17 15 11 11 18 13 05 35 17 27. In that representation of base-36 notation each two digit group equals one character in the name ‘5hfbbkd5yhq’.
This will also do the trick:
set n to do shell script "echo '36 o 10 i 20050515173205999 p' | dc"
baseFake10to36(n) --> 5hfbbid5zhs
to baseFake10to36(num)
script a
property c : "0123456789abcdefghijklmnopqrstuvwxyz"
property n : words of num
property o : {}
end script
repeat with i from 1 to count a's n
set a's o's end to item ((a's n's item i) + 1) of a's c
end repeat
"" & a's o
end baseFake10to36
Also, if you don’t mind change your method, you could change the name into its checksum value. Eg:
set n to "20050515173205999"
do shell script "printf \"%08X\" `echo -n " & n & " | cksum -o3 | awk '{ print $1 }'`" --> "58845171"
This should generate a unique string for every unique provided name-number, but it will mangle the real number and you can’t get back the original string converting again base36 to base10.
And here is the reverse function 
base36to10("playingwithnumbers") --> "7332349595171867972709703048"
to base36to10(str)
script a
property c : "0123456789abcdefghijklmnopqrstuvwxyz"
property n : str's items
property o : {}
end script
set k to count str
repeat with i from 1 to k
set a's o's end to "(" & ((offset of a's n's item i in a's c) - 1) & " * (36**" & (k - i) & "))"
end repeat
set AppleScript's text item delimiters to " + "
set op to a's o as text
set AppleScript's text item delimiters to {""}
do shell script "echo -n " & quoted form of ("print " & op) & " | python -"
end base36to10
BTW, seems that it doesn’t return “20050515173205999” using “5hfbbid5zhs” as input, but “20050515173206000”. I’ve seem the same behaviours in some online calculators… Nigel around?
Thanks JJ;
Now I’m 90% of the way home. Actually I need to go from base 10 to base 36 – the other direction from your example. If you happen to have that conversion laying around I would be grateful, otherwise I can puzzile it out from your example later today (tonight).
The missing piece for me was finding out about Python. I scanned the web Unix man pages for a couple of hours to see how to do the base-10 to base-36 conversion but didn’t see any examples using Python. Now I’ve got something new in my (tiny) box of Unix tools.
I realize that the decimal and base 36 strings that I had given didn’t match. I had a bunch of test conversions on my desktop from an online calculator and got the pairs scrambled.
THE REALLY SURPRISING PART IS:
After playing around with base-36 filenames for a day I made 10 folders and manually renamed them from base-10 numbers to base-36 strings. They don’t sort correctly in the Finder(10.3.9)! Apparently Apple has jiggled the sort order in a way that I never noticed so that folders will sort numerically like this:
Folder 1
Folder 2
Folder 10
Folder 20
Folder 100
instead of alphabetically like this which is more common for computer OSs:
Folder 1
Folder 10
Folder 100
Folder 2
Folder 20
I guess that Apple didn’t figure that users would be smart enough to use leading zero padding to get sorting order correct so they fixed if for us proactively. Anyway they have broken my plan to use base-36 for naming my files for the time being.
I have read online that Tiger allows the user to specify sorting patterns. I will check that out later this week and see if that may save the day.
Dear JJ;
Siento que no visto su mesage primero. Este manera cambiar base-10 a base-36 sirve muy bien; tambien me interesa su idea usar cksum. La problema con este is que los nombres que regresa este “funcion” no se arreglen bien.
Gracias por todo su ayuda,
Tomas
Yep. If your problem is sorting items in the Finder after changing their names, I don’t think cksum nor base36 will help you → unless you find something interesting in the pattern-sorting thing…
Anyway, the great news is that your spanish is much better than my english 