Folder script ... print and delete added documents

Hi,

I had a folder script that printed any document added to a folder and when printed, then it deleted the document. That script help me to print from an OS 9 emulator (SheepShaver) through OS X.

For I don’t know the reason, the folder script does not work anymore. It could be Yosemite or my new iMac upgrade. Find out ? And Apple Script is far away in my mind … so I am not really sure what is going wrong.

I would like to have the script to print from any folder it is assigned to, instead of applying to only one folder. Can you help ? Here is the actual folder script:

property myPrinter : "HP_Officejet_8500" -- Le nom exact de l'imprimante est obtenu en faisant «lpstat -p» dans terminal.
property filesFolderName : "Nous/Documents/SheepShaver/Données/En impression" -- Déterminer le chemin du dossier contenant les fichiers à imprimer.
property fileStamp : ""
property theFilePath : ""
 
 
on adding folder items to thisFolder after receiving theseItems
          
          -- Définir le chemin du dossier contenant les fichiers à imprimer.
          set filesFolderPath to POSIX path of (path to users folder) & filesFolderName & "/"
          
          -- Pour chaque fichier dans le dossier ...
          repeat with i in theseItems
                   
                   -- ... définir les informations du fichier; ...
                   set {name:fileName, name extension:fileExt} to info for i
                   
                   -- ... définir l'estampe du fichier (date et l'heure), ...
                   --set fileStamp to do shell script "/bin/date +'('%d-%m-%y' '%HH%MM%S')'"
                   
                   -- ... définir le chemin du fichier, ...
                   set theFilePath to quoted form of (filesFolderPath & fileName)
                   
                   -- ... et enfin, l'imprimer sur l'imprimante choisie.
                   do shell script "usr/bin/lpr -P " & myPrinter & space & theFilePath
                   do shell script "/bin/sleep 10"
                   
                   -- ... détruire le fichier imprimé.
                   do shell script "/bin/rm " & theFilePath
                   get theFilePath
                   
          end repeat
          
end adding folder items to

Thanks in advance.

Robert Lespérance

Essayez avec cette version :

property myPrinter : "HP_Officejet_8500" -- Le nom exact de l'imprimante est obtenu en faisant «lpstat -p» dans terminal.
# Je désactive trois instructions inutiles
# property filesFolderName : "Nous/Documents/SheepShaver/Données/En impression" -- Déterminer le chemin du dossier contenant les fichiers à imprimer.
# property fileStamp : ""
# property theFilePath : ""


on adding folder items to thisFolder after receiving theseItems
	
	-- Définir le chemin du dossier contenant les fichiers à imprimer.
	# Si je comprends bien, les fichiers à imprimer sont déposés dans le dossier thisFolder auquel est attaché le dossier
	
	-- Pour chaque fichier dans le dossier ...
	repeat with i in theseItems
		# Ici, i est un alias au format Hfs+
		# Il n'y a aucune raison de perdre du temps à reconstruire ce chemin
		-- ... définir les informations du fichier; ...
		# Instruction inutile puisque vous n'utilisez pas la variable fileExt et que le nom du document : fileName ne nous sert à rien
		# set {name:fileName, name extension:fileExt} to info for i
		
		-- ... définir l'estampe du fichier (date et l'heure), ...
		--set fileStamp to do shell script "/bin/date +'('%d-%m-%y' '%HH%MM%S')'"
		
		-- ... définir le chemin du fichier, ...
		set theFilePath to quoted form of POSIX path of i
		
		-- ... et enfin, l'imprimer sur l'imprimante choisie.
		do shell script "usr/bin/lpr -P " & myPrinter & space & theFilePath
		do shell script "/bin/sleep 10"
		
		-- ... détruire le fichier imprimé.
		do shell script "/bin/rm " & theFilePath
		# get theFilePath # parfaitement inutile
		
	end repeat
	
end adding folder items to

Je rappelle que le script doit être stocké dans le dossier “/Library/Scripts/Folder Action Scripts/”
et que vous devez ensuite l’attacher au dossier recevant les fichiers à l’aide de l’application
/System/Library/CoreServices/Folder Actions Setup.app

Je n’ai pas vérifié que vos instructions do shell script sont correctes.

Par contre je suis sur que le chemin d’accès Unix theFilePath est correctement construit.

Yvan KOENIG (VALLAURIS, France) jeudi 19 février 2015 19:52:03

Bonjour Yvan,

Merci pour votre aide.

J’ai suivi vos recommandations et essayé votre script de dossier. Il fait la même chose que le mien. Après avoir déposé un fichier dans le dossier, l’Impression tarde et, après un peu de temps (± 1 minute), imprime une seule ligne de caractères illisibles dans le haut de la page. Le script ne se rend, de tout évidence, pas à l’instruction de mettre le fichier à la corbeille, puisque le fichier est toujours dans le dossier.

Je ne comprend vraiment pas … ce script fonctionnait depuis si longtemps et sans aucun problème. Est-ce possible de l’essayer en le joignant à un dossier et en y glissant un fichier ? Merci à l’avance.

Robert Lespérance

please, folks, this is still an english forum :wink:

Hello Stefan

From time to time - very rarely - I meet someone speaking French on the forum and in such case, I answer in French.
Doing that about once a year is not a crime and I will not guarantee that I will not do the same next year if I meet an other asker using French. I made efforts all the time to understand question and answer them in a language which is not mine.
Feel free to use Google translator (or an other one, I’m not related to Google).
When I was active as a potter, my shop was in France were most inhabitants speak French but as long as they were polite I never ranted against visitors speaking an other language.

Yvan KOENIG (VALLAURIS, France) jeudi 19 février 2015 21:00:52

Are you sure that the lpr command is aware of the structure of the documents which you ask it to treat.
You may check that the shell instructions are OK with this simple script :

set aPath to choose file
set theFilePath to quoted form of POSIX path of aPath

-- ... et enfin, l'imprimer sur l'imprimante choisie.
do shell script "usr/bin/lpr -P " & myPrinter & space & theFilePath
do shell script "/bin/sleep 10"

-- ... détruire le fichier imprimé.
# do shell script "/bin/rm " & theFilePath

With the choose file dialog you may select one of the files which you wish to print.
The variable aPath will contain an alias object pointing to the file.
The alias will be converted as an Unix path used by the shell instructions.

Yvan KOENIG (VALLAURIS, France) jeudi 19 février 2015 21:08:43

Your script works … and, when activated, the line to delete the file after being printed also works. The script is probably not the cause of this behavior.

Having searched around, there seem to be a problem in Yosemite with Folder Action scripts. I played around my self to realize that there really is a problem … Sometimes, when CTRL clicking on a folder to add a Folder action script, the service hangs … and in Activity Monitor, the Folder action Manager ? uses 100% of the processor. Then I have to Force quit the process to get back control.

I found this link (http://www.macissues.com/2015/01/30/fix-folder-actions-dispatcher-using-high-cpu-in-yosemite/) regarding the possible problem.

If you are running Yosemite, could you try your script on your computer ?

I have no printer available.
So, I already tested the script without the shell instructions.

To do that, I used this script :

on adding folder items to thisFolder after receiving theseItems
	repeat with i in theseItems
		say (i as text)
		delay 0.5
		set theFilePath to quoted form of POSIX path of i
		tell me to say theFilePath
		delay 0.5
	end repeat
end adding folder items to

When I dropped files on the folder, the script “said” the HFS path of a file then “said” the Unix path of the same file and repeat the process for every dropped file.

So, it’s clear, at least for me, that the folder action does exactly what it is supposed to do.
Yes, I am running Yosemite 10.10.2.

If I wrote :

et que vous devez ensuite l’attacher au dossier recevant les fichiers à l’aide de l’application
/System/Library/CoreServices/Folder Actions Setup.app

Here, Folder Action Manager (named Distributeur des actions de dossier) doesn’t eat processor time.
Most of the time, happily, Activity Monitor states that it use 0%.
I wrote “happily” because I use folder action scripts many times, in fact a least for every screenshot taken because I use a folder action script to rename the png files and move them in a folder which is the same whichever volume I booted from.
This way, I retrieve the pictures when I boot from Mavericks, from Yosemite (public release) , or from a Yosemite (beta).
Maybe what you describe strikes only on English system.

Yvan KOENIG (VALLAURIS, France) vendredi 20 février 2015 17:33:50

Bonjour Yvan,

Thank you. I created a new … a brand new and empty user to try your folder script … and it works perfectly. So this is obviously not a script problem.

On my user, I see that the script tries to print, but not as usual or as desired. It lags, doesn’t print, prints and adds a page with garbage text … it prints awkwardly. So there seem to be an offender.

After thinking much about this and considering that everything have been working before for many years, something else has to be taken into consideration. Yosemite has been installed for a few weeks without problem, so probably this is not it either.

The only thing that comes to mind are 2 new cloud services that I recently installed: hubiC and Copy. Intuitively, these services could be the problem since they scan folder for changes in a similar way that the script does. I stopped these services and many other utility (Butler, BetterSnapTools,etc …) … restarted the computer, and the problem persists. There can be background engine still running and that could be messing around.

I don’t know where to go from here. If you have an idea, fell free to suggest. Could looking into Activity Monitor or Console be a way to see what is going around … but, for me, much of what is going around there, I don’t understand.

I thank you for your help.

Robert Lespérance
Québec, Canada

I can’t help about that.

I read some messages about Folder Action Manager annoying behavior but as I never got it, I assume that it’s due to a problem in the hosting system.
Alas I have no idea about what may be the wrongdoer.
Disabling the actions is not a solution. It just hide the symptoms.
What would be useful would be to identify the cause of these symptoms.

As I don’t use iCloud, searching in this direction may be a good track but no guaranty about that.

At least, we know that the problem is not in the shared parts of the system, only in an account.
Alas there may be numerous differences between two accounts on the same machine.

Yvan KOENIG (VALLAURIS, France) samedi 21 février 2015 19:06:56

Merci pour votre aide.

Bonjour Yvan,

The Folder Action Manager (FAM) problem is not over. It gets agitated for some reason … and after that it begins to loop in a way that increases the process’s memory usage until it crashes. The reason is still a mystery but I am now able to get the Folder Action Script (FAS) to work and see it execute before or without crashing.

I would still need a little bit of help with the script. I get a peculiar behavior that maybe you can understand.

My FAS is:

--  Script de dossier qui imprime les fichiers ajoutés au dossier auquel le script est assigné.
--  Le dossier cible est identifié par la variable «thisFolder».


property myPrinter : "HP_Officejet_8500" -- Le nom exact de l'imprimante est obtenu en faisant «lpstat -p» dans terminal.


on adding folder items to thisFolder after receiving theseItems
	
	
	-- Pour chaque fichier de ce dossier ...
	repeat with i in theseItems
		
		-- ... définir le chemin du fichier et ...
		set theFilePath to quoted form of POSIX path of i
		
		-- ... l'imprimer sur l'imprimante choisie.
		do shell script "usr/bin/lpr -P " & myPrinter & space & theFilePath
		do shell script "/bin/sleep 10"
		
		--  Une fois imprimé, mettre le fichier à la Corbeille.
		do shell script "/bin/rm " & theFilePath
		
		
	end repeat
	
end adding folder items to

I use that FAS to print from an application in a OS 9 emulator. The app prints to a PDF file that is added to a FAS enabled folder on the OS X side … then the file is supposed to be printed.

Here is the peculiar behavior I am experiencing. If I manually drop a file on the FAS enabled folder, the file prints and is deleted, as expected. If the file is added from the OS 9 application nothing happens.

Does that sound anything to you ?

Thanks in advance.

Robert Lespérance

My understanding is that the system is not warned of the addition when it is processed by the emulator.
Honestly I’m not really surprised.
What is preventing you to print from the emulated system ?
If I remember well, the folder actions were unavailable in the first incarnations of OS X but they were available in old beast.

I repeat that I guess that there is a component, probably not one delivered with the system by default, which fools the Folder Action Manager.

Yvan KOENIG (VALLAURIS, France) vendredi 6 mars 2015 22:01:32

Hi and escargot,

Please note that in Yosemite, Apple changed folder actions. If you look at launchd, it now uses something different. I don’t know exactly what they did. Needs some research.

gl,
kel

Have a look here: http://www.macscripter.net/viewtopic.php?id=43727 … and thanks for helping.