Hello all. I tried searching for some answers on this but I can’t quite figure out the syntax on this one.
I created a script via AppleScript that will ask the user for his/her firstname.lastname and password and pass the credentials to mount_smbfs. It seems to work just fine as long as the user does not have special characters in the password (!@#$%^& etc.). I know I need to escape these out somehow, but I’m not quite sure of where to place the escape (I believe it’s \n or something?) in the script. My code is as follows:
set Dialog_1 to display dialog "Please enter your user name" default answer "firstname.lastname"
set the user_name to the text returned of Dialog_1
set pass_word to ""
set Dialog_2 to display dialog "Please enter your password" default answer "" with hidden answer
set pass_word to the text returned of Dialog_2
tell application "Finder"
-->Creates mount folder
try
do shell script "mkdir /Users/$USER/Desktop/$USER"
end try
-->Mounts the share with mount_smbfs
try
do shell script "mount_smbfs //" & user_name & ":" & pass_word & "@server/Users/$USER /Users/$USER/Desktop/$USER/"
delay 1.5
end try
end tell
Before thinking of escaping characters, you should really assure that the character sets are compatible, that is, the character set on your mac, and the character set on the smb server.
You should really try that first with some accounts with hand crafted passwords, to see that you can make it work manually! And then escape the [color=blue][/color] with [color=blue][/color] and " and escape " and ’ too with [color=blue][/color].
The best thing is to avoid those characters in password generation all together if you can!
If it is a translation thing with the charset, then do come back, as there are ways to make the shell use another charset!
Wrong, the character set used on the command line isn’t used inside the application per se. What is important is that the internal character set used on the socket/serializing are for server as client the same.
Also I wouldn’t do that, use quoted form which not only saves you a lot of work but is the best way of quoting fields. Don’t try to escape strings yourself, it’s only waiting for something bad to happen.
Does it work now?:
set Dialog_1 to display dialog "Please enter your user name" default answer "firstname.lastname"
set the user_name to quoted form of text returned of Dialog_1
set pass_word to ""
set Dialog_2 to display dialog "Please enter your password" default answer "" with hidden answer
set pass_word to quoted form of text returned of Dialog_2
do shell script "mkdir /Users/$USER/Desktop/$USER && mount_smbfs //" & user_name & ":" & pass_word & "@server/Users/$USER /Users/$USER/Desktop/$USER/"
Well. I believe Novell to still have have an SMB solution working by us, but what the heck, the trouble is to pin down that socket or server, and find out what kind of transformation is going on. Because if you got it, you probably won’t get rid of it!
That is totally correct, I even thought awhile that the string would be quoted automagically, but I tried it, and it wasn’t so.
Well there are some character encodings problems in the shell but escaping characters won’t help you. Then the TS mentioned that is about characters !@#$%^& etc. which are all ASCII characters (read: not ASCII extended). If you have CP1252, ISO-8859-1, MACROMAN or UTF-8 characters encoding, all these characters have the same byte values from 0 to 127. Well if you need to force a certain character encoding you can always use command substitution and get something like this
set Dialog_1 to display dialog "Please enter your user name" default answer "firstname.lastname"
set the user_name to "$(/bin/echo -n " & quoted form of text returned of Dialog_1 & " | iconv -t cp1252)"
set pass_word to ""
set Dialog_2 to display dialog "Please enter your password" default answer "" with hidden answer
set pass_word to "$(/bin/echo -n " & quoted form of text returned of Dialog_2 & " | iconv -t cp1252)"
do shell script "mkdir /Users/$USER/Desktop/$USER && mount_smbfs //" & user_name & ":" & pass_word & "@server/Users/$USER /Users/$USER/Desktop/$USER/"
It may also be that the special characters do indeed need escaping, and it may also be that special characters isn’t allowed, though it seemed that the OP, didn’t have a problem with logging on, when special characters was in the password otherwise.
I wonder if the login process goes well via finder, or otherwise fine, via a webpage or similar, when using a mac.
