Running *nix commands in embedded script

[Mr_Noodle]

When you run it in Terminal, immediately after do

Code: Select all

  echo $?


And see what that shows ($? is the exit code of the last process). If it's non-zero then that script is erroneously returning a bad exit code.

[a_freyer]

The clean install made no difference, so...

I'd next add some debug logging to the executable to see which exit 1 is tripping via hazel.

Here's the debug log I get when I drop a .djvu file into Word2Papers:

https://www.dropbox.com/s/l0nv50nbc6yv544/hazelDebug.log

Yeah, that's not particularly helpful.

What I meant was to open the executable (which, if the script is the same as the one I found, is merely executable text), in TextEdit and add:

Code: Select all

echo $LINENO

Before each "exit 1" instruction.

[tone]

When you run it in Terminal, immediately after do

Code: Select all

  echo $?


And see what that shows ($? is the exit code of the last process). If it's non-zero then that script is erroneously returning a bad exit code.

It's 0.

[tone]

What I meant was to open the executable (which, if the script is the same as the one I found, is merely executable text), in TextEdit and add:

Code: Select all

echo $LINENO

Before each "exit 1" instruction.

Sorry if I'm being ignorant, but doing this doesn't add anything to Hazel's log. Is the error $LINENO logged somewhere else?

[a_freyer]

Probably not logged directly by Hazel then - the echo statements should show in the general console (All Messages). You're looking for single numbers 1,4, 17 (these are made up, I'm not sure what yours will be).

I assume we'll just see one number though - and that line will be the line where your script is exiting from. From there, backtrace the logic to see why it failed.

This is the method I'd use - I'm sorry if this code-diving is a bit intimidating... :-(

[a_freyer]

Forgot to mention that these messages will probably come from Hazel helper:

Code: Select all

7/23/12 2:09:23.483 PM [0x0-0x3df3df].com.noodlesoft.HazelHelper: 1


[tone]

I think this is the culprit:

Code: Select all

23/07/2012 16:37:56.515 [0x0-0x3f2af27].com.noodlesoft.HazelHelper: Error: /usr/local/Cellar/djvu2pdf/0.9.2/bin/djvu2pdf: ddjvu not found. Install djvulibre.


However, djvulibre is definitely installed - it's one of djvu2pdf's dependencies and I don't get this error when I run djvu2pdf in terminal.

[a_freyer]

I think this is the culprit:

Code: Select all

23/07/2012 16:37:56.515 [0x0-0x3f2af27].com.noodlesoft.HazelHelper: Error: /usr/local/Cellar/djvu2pdf/0.9.2/bin/djvu2pdf: ddjvu not found. Install djvulibre.


However, djvulibre is definitely installed - it's one of djvu2pdf's dependencies and I don't get this error when I run djvu2pdf in terminal.

I suggest prepending the path of ddjvu within the executable where it's called. Else, you could cd to the home directory before you call the djvu2pdf script. Else, you could cd to the directory where ddjvu is housed.

That error comes from this block (again, if you and I are finding the same version of this online):

Code: Select all

# MacOS and BSD compatibility
which seq >/dev/null 2>&1
if [ $? -eq 0 ]; then
    SEQ=seq
else
    SEQ=jot
fi

for i in "ddjvu djvulibre" "gs ghostscript"; do
    BINARY=$(echo $i | awk '{print $1'})
    PACKAGE=$(echo $i | awk '{print $2'})
    which $BINARY >/dev/null 2>&1
    check_print_error "$BINARY not found. Install $PACKAGE."
done

A search-replace of ddjvu for /path/to/ddjvu should solve this issue if you don't want to change working directories.

NOTE: it seems like this script is very path dependent.... sigh.

[a_freyer]

I expect you might have to do path prepending for gs as well.

[tone]

A search-replace of ddjvu for /path/to/ddjvu should solve this issue if you don't want to change working directories.

NOTE: it seems like this script is very path dependent.... sigh.

That solved the ddjvu problem...now it can't find ghostscript. I can see this going on for a while..... but thanks for your help and patience There must be an easier solution, though.

Out of curiosity, is the fact Hazel can't execute shell commands that Terminal has no trouble with a bug, a feature, or something else?

[tone]

I expect you might have to do path prepending for gs as well.

That worked! No more errors!!!! (I think - I'll get back to you if/when the PDF it generated - I just had to report the lack of errors!)

[tone]

Yes, the PDF was created in the same directory as the djvu file, which is perfect.

Thanks for all your help, Andrew. That must've really tested your patience

Although djvu2pdf could help things along by not being so path-dependent, as you say, I had the same problem with epub2pdf (which is why I ended up copying it to the watched folder).

[a_freyer]

Out of curiosity, is the fact Hazel can't execute shell commands that Terminal has no trouble with a bug, a feature, or something else?

It's a feature - Hazel spawns a shell in the monitor directory for convenience. I think it would be very confusing to spawn a shell always in the home directory because most folks who use terminal commands regularly are comfortable cd'ing to the working directory and staying there (as the author of your script certainly did :D ), so It makes most sense for Hazel to start your shell there.

On the other hand, it does make operating scripts like yours a big cumbersome - since the author of your script made its operation path-dependent.

[a_freyer]

Yes, the PDF was created in the same directory as the djvu file, which is perfect.

Thanks for all your help, Andrew. That must've really tested your patience :)

Although djvu2pdf could help things along by not being so path-dependent, as you say, I had the same problem with epub2pdf (which is why I ended up copying it to the watched folder).

Excellent to hear! :-) You and I replied at the same time, but for the sake of the forum, I'll summarize that moral of this story is:

If users are having trouble getting external scripts working in Hazel, be sure to check for path dependent instructions within the script itself.

Happy Hazeling!

[Mr_Noodle]

Yes, Hazel is executing scripts in a non-interactive shell. It doesn't have access to environment variables (including many paths) that you may be putting in the various rc and config files that different shells only load in interactive mode. You should either use full paths or re-create these environment variables yourself in the script.