Does AppleScript’s do shell script log in history

EDIT: Workflow now works with one bug: running the workflow twice results in two copies of the control file being copied

Make a new Automator SERVICE. At the beginning, for "receives selected as input" choose "documents". Add the process "set value of variable" and make a new "destination path" variable (default variable name is "destination path"). Add the process "open finder items" to the beginning to open the control file. Add the process "run applescript" to the workflow the code is the following:

on run {input, parameters}

set LineNumber to (the line in which the path is specified in the control file)
tell application "TextEdit"
    set theVariable to paragraph LineNumber of document 1
    set thePath to POSIX path of theVariable
    set thePath to text 1 thru -2 of thePath
end tell

return thePath
end run

I don't know why this couldn't have been in the same block, but you need to add a separate AppleScript process. The code is as follows:

on run {input, parameters}

tell application "Finder"
    set theFolder to POSIX path of input & "/DEBIAN"
    try
        make new folder in folder input with properties {name:"DEBIAN"}
    end try
end tell

return theFolder
end run

Add the process "set value of variable" and make a new destination path variable (default name is "destination path 1").
Add the "get value of variable" process and get the value of the variable with the path of the input file ("destination path"). Click on "options" on this process and check "ignore this action's input".
After this, Automator has a process called "copy finder items" and this can be used to copy the input (the output of "get value of variable", which is the input file). This worked for me, hope it works for you as well. Good luck :)

The ultimate problem here is that Bash does not normally kill its non-builtin children.

If bash is waiting for a command to complete and receives a signal for which a
trap has been set, the trap will not be executed until the command completes.
When bash is waiting for an asynchronous command  via  the  wait  builtin, the
reception of a signal for which a trap has been set will cause the wait builtin
to return immediately with an exit status greater than 128, immediately after
which  the trap is executed.

When you hit <CTRL>+<C> you're killing the shell script, which behaves normally -- but the sleep lives on. Use ps to see.

When try to stop things externally, via kill, then Bash as above. After some time-out period (I'm guessing 20 seconds) launchd then issues a kill -9 which the script cannot trap.

The solution is to issue a wait after the sleep, to indicate to Bash that it can interrupt itself:

sleep 86400 & wait

This will allow the script to be interrupted, but the sleep will still survive. I'm sure there's a way to kill the children, but I didn't bother looking it up...