I have got a small script that updates EXIF information and JPG-image to rotate pictures I have taken in portrait mode (which normally show up in Thunar or whatever as rotated 90 degrees anti-clockwise). For the technically inclined: first the orientation gets updated using jpexexiforient; then the image gets aligned with its orientation using jhead. I have subsequently defined this script as a Thunar custom action. The script works when taking a bunch of pic's in my home directory and all is well (whether I do one or a dozen doesn't matter).
However (and this is where the plot thickens), if I run same custom-action on same bunch of pictures in another directory outside my home tree then the operation fails. Copying the files back to my home, and the action works. Running the script that the custom action calls works as well on the selected files. Debugging of the script has shown that arguments get processed correctly (I use %F to ensure full path & filename get passed to the script).
The only difference between this directory and anything in my home is the access -- mode is 755 or 644 (dir/file); file-ownership is held by me and group-ownership is held by a group of which I am member. I do not see how that can have a bearing (as both files are owned by me with RW access and I have got RW access to the directory in which they are placed), but that is the only thing I can come up with. Anybody who can point me in right direction?
Probably your script is located at your home folder, right?
Now when thunar browses another directory, that directory becomes current and it tries to locate your script
there and naturally fails.
a) move your script to /usr/local/bin
b) create a ~/bin directory and add that to the PATH environment variable in your .bashrc (if your login manager does not process it, /etc/defaults might be of help -- it is possible that thunar inherits a different environment from its parent process than what you get when you open any terminal)
Thanks for response but that doesn't work -- I had the script indeed my home folder but the custom action has the full path coded, i.e. /home/pindakoe/bin... Also I see that the script gets called (irrespective of location), it doesn't seem to have the right access to modify the images, whereas I can if I run same script on same images in same directories. My suspicion was that the custom-action is somehow not run under my UID but I can only find reasons why this is not teh case.
I'd still concentrate at the environmental settings just to make sure.
Perhaps you can adapt your script so that it dumps:
to a text file.
Then, compare both outputs with diff or meld.
There is another thread in here that deals with thunars default umask, probably the problem is related?
Finally, posting the script here might attract the attention of a real bash guru...
Good tips (was wondering how to figure out as which user a script ran as I suspected this to be the cause. Ran the following 4 scenario's:
script in ~/bin; run on file in my home and in anotehr directory to which I have RW-access
script in /usr/local/bin; run on file in my home and in same other directory as before, i.e. one to which I have RW access
Result is that I can in both cases change the pictures in my own home (or rather a subdirectory of my home), but not in the other directory. Output of $(id), $(export), $(umask) does not reveal any differences (unless for PWD if I ran it on different directory). The script is simplicity itself:
while [ -n "$1" ]; do jpegexiforient -5 $1 jhead -autorot $1 shift done
Debugging statements confirm that it handles one or more arguments correctly (Thunar calls the script with %F). In short: Custom action passes file and path details of the selected files correctly to the script; the script runs under my UID, with similar environment as I do when calling the script from bash.
Does this help?
while [ -n "$1" ]; do jpegexiforient -5 "$1" jhead -autorot "$1" shift done
You mightn't have spaces under your home folder, but who knows what's in your 'elsewhere'.
Doing a killall Thunar && thunar and watching the error output of jpegexiforient could be of help, methinks.