Has anyone else encountered this issue? I have a fairly simple script that does some file cleanups on both the local machine and on a corresponding server. To remove a given file on the server, I’ve set up another simple Expect shell script that my Applescript calls. The applescript runs the shell script using a path fragment as an argument. I’ve tested the shell script independently and it works as expected. However, when the shell script is invoked using do shell script, it behaves differently if the path fragment is longer (seems to be around 54 characters or so).
Here’s the Applescript:
set fileList to {"DirX-DirX-DirX", "DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX"}
set scriptHome to quoted form of "/Users/Shared/FileCleaner/"
set thisUser to "test"
repeat with thisFile in fileList
set thisCommand to (scriptHome & "delete_file.sh " & thisUser & "/" & (contents of thisFile))
set thisValue to paragraphs of (do shell script thisCommand)
end repeat
When I run this script this is the output from the shell script:
[b][i]Password:
Last login: Wed Aug 12 11:09:14 2009 from dhcp186.foo.ca
server01:~ root# sending: rm -vrf /Volumes/RAID_3_2/Users/test/DirX-DirX-DirX
rm -vrf /Volumes/RAID_3_2/Users/test/DirX-DirX-DirX
server01:~ root#
not found
exit
logout
Connection to server01.foo.ca closed.
Password:
Last login: Wed Aug 12 11:19:09 2009 from dhcp186.foo.ca
server01:~ root# sending: rm -vrf /Volumes/RAID_3_2/Users/test/DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX
rm -vrf /Volumes/RAID_3_2/Users/test/DirX-DirX-DirX-DirX-Dir
<olumes/RAID_3_2/Users/test/DirX-DirX-DirX-DirX-DirX -DirX-DirX-DirX-DirX-DirX
server01:~ root# timed_out:
Last login: Wed Aug 12 11:19:09 2009 from dhcp186.foo.ca
server01:~ root#[/i][/b]
The first time through, the log shows normal output: it sends the proper rm command and then returns “not found”. The second time around with the longer path fragment, the rm command breaks and then the expect command times out as the expected feedback isn’t found.
Now I’ll run that same shell script from the terminal using the same command as generated by Applescript, and it’ll work fine:
[b][i]Password:
Last login: Wed Aug 12 11:22:30 2009 from dhcp186.foo.ca
server01:~ root# sending: rm -vrf /Volumes/RAID_3_2/Users/test/DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX
rm -vrf /Volumes/RAID_3_2/Users/test/DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX
server01:~ root#
not found
exit
logout
Connection to server01.foo.ca closed.
[/i][/b]
The rm command remains intact as expected and everything is peachy. Can anybody help me figure out what’s up with do shell script that it’s breaking what should be a simple command?
You have this line…
set scriptHome to quoted form of “/Users/Shared/FileCleaner/”
And then later you have this line…
set thisCommand to (scriptHome & "delete_file.sh " & thisUser & “/” & (contents of thisFile))
So basically you are adding delete_file.sh to something that is already in quoted form. I would think that would cause a problem. I would try this instead:
set fileList to {"DirX-DirX-DirX", "DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX-DirX"}
set scriptHome to "/Users/Shared/FileCleaner/"
set scriptPath to scriptHome & "delete_file.sh"
set thisUser to "test"
repeat with thisFile in fileList
set thisCommand to quoted form of scriptPath & space & quoted form of (thisUser & "/" & (contents of thisFile))
set thisValue to paragraphs of (do shell script thisCommand)
end repeat
That should not be a problem. The shell will concatenate any adjacent “words”.
'some thing 'to\ think" about" produces the same value as ‘some thing to think about’, “something to think about”, or some\ this\ to\ think\ about.
In fact, appending unquoted text to quoted text is a common pattern for using wildcards in combination with quoted paths. “$SOME_VAR_WITH_A_PATH”/* would expand to the files in the dir whose pathname is in the shell variable SOME_VAR_WITH_A_PATH. The wild card part must not be quoted for the shell to expand it, while the variable part should be quoted so that (among other issues) any spaces in its value will not cause its value to be split into multiple “words”.
To me, it looks like the problem might be in ‘delete_file.sh’ or the Expect program, or at least in their interaction with the remote system. Based on the "sending: " info, it looks like the Expect program is getting the full pathname, but something is going wrong while/after it is sent to the remote system. Both the hiccup in the output, (where it seems to restart after replacing the first ten characters with a less-than sign), and the extra spaces after the 5 'DirX’s (which are apparently actually 25 spaces, followed by 25 Control-H characters (backspace)) are suspicious.
There are many differences between a do shell script shell and a Terminal shell (see TN2065), but so much of what is happening here depends on what ‘delete_file.sh’ and its Expect program do that I can not guess as to what the pertinent difference might be in this case.
Yes chrys, looks like you’re right about do shell script behaving quite differently than straight up terminal cmds–as I managed to sort out what was going on. As it turns out, do shell script silently inserts soft line breaks into long commands. It will still be interpreted the same as usual–unless you’re using a naive expect script that is looking for a particular format in the command and the response text buffer as I was. As such, I just needed to adjust my expect script so that it wouldn’t be so strict about finding the whole command on a single line, and then it worked fine.