Execute Command not Finding LaTex shell command

[nathan_ed1]

Hello,

We have a simple bash script I wrote to use with the execute command inside of Switch for doing some simple imposing work before sending the job off to a hot folder for our Fiery's. The Bash Script I'm betting I can get it working with more effort, but I'm hoping someone may have a solution or at least a clarification on why it is not working now.

The Shell Script runs as expected, and moves any test file along the flow (just not modified), but in the log for stderr, I have:

Code: Select all

stderr: /Users/ed1prepress2/Documents/Switch_Impose/PdfJam_Impose.bash: line 271: pdfjam: command not found

Which does explain why the file was not modified (You can't modify something without knowing the command!)

The command does execute fine if I give it arguments manually in the shell (Outside of Switch), so I know it isn't a simple coding error.

I suspect it has something to do with how the execute command function works, as the user guide indicated :

Switch will execute the command directly in the operating system while Command Prompt and Terminal use a shell. This results in some differences in behavior, the most important one being that you always have to provide the full path to the command line application in Switch, even when this is not necessary in Command Prompt or Terminal!

The "pdfjam" command is a set of shell scripts itself, so I'm wondering if this has to do with the aliases the shell handles automatically, while the execute command does not know where exactly it is located.

Any thoughts or suggestions would be appreciated.

Thanks,

Nathan

[nathan_ed1]

I'm posting a reply to the above, as I solved nearly all the issues I was referring to. I was correct in thinking that Switch had no idea where my reference scripts were, so I had to set the absolute directory of my executables in my bash script, and then set some more inside of the pdfjam.conf to make sure IT had the absolute paths it needed to function properly. I also realized I needed to call EVERY absolute path for all execs normally called by the shell, so that has solved every single issue I had with the script erroring.

I now understand what the manual meant by "some differences in behavior". The key that got me the rest of the way was testing inside of Mac's Automator program, as that has similar functional aspect to the execute command, since they both operate outside of the shell terminal. Browsing their forums led me to the right answer.

Unfortunately it still does not run properly. The debug reports it running with no issues, however it does not finish running, and the last message in this flow is the bash script executing. So either I have a bad configuration (likely) or I'm missing something. I will report back once it's fully solved

[freddyp]

You have to realize that the Switch Server process that is running in the background is NOT running in the same environment as the one that is used one the command line (either a command prompt window on Windows, or Terminal on Mac). One of the big differences is the PATH environment variable. This variable determines over what paths the operating systems searches for executables or applications and when the PATH variable does not include the folder where the application you are working with resides, then it will not be found. Using complete paths is the obvious thing to do, but this may not work in all circumstances as it could be that the application also relies on PATH internally.

The easiest method and also the one that guarantees most success is to change the PATH variable in your BAT file or shell script so it has the same value as the PATH variable of the command prompt or shell.

Note that other environment variables could play a role as well. What environment variables the tool relies on is something that should be part of the documentation, and if required then set these also in the BAT file/shell script.

[nathan_ed1]

You have to realize that the Switch Server process that is running in the background is NOT running in the same environment as the one that is used one the command line (either a command prompt window on Windows, or Terminal on Mac). One of the big differences is the PATH environment variable. This variable determines over what paths the operating systems searches for executables or applications and when the PATH variable does not include the folder where the application you are working with resides, then it will not be found. Using complete paths is the obvious thing to do, but this may not work in all circumstances as it could be that the application also relies on PATH internally.

The easiest method and also the one that guarantees most success is to change the PATH variable in your BAT file or shell script so it has the same value as the PATH variable of the command prompt or shell.

Note that other environment variables could play a role as well. What environment variables the tool relies on is something that should be part of the documentation, and if required then set these also in the BAT file/shell script.

This makes perfect sense after the fact! I did end up fixing my problems with the code and it does run now. Though I will probably need to implement the above PATH correction for any other scripts I write (which I should probably do anyways here).

I had to change some calls I was making to dirname, basename and mdls to pull from switch data instead (as you said PATH issue). Which is probably for the best with how switch uses %1, %2 and %3, I don't need to use the first 2. The bash file was written as a side project for me to re-teach myself bash at home, so lots of linux calls rather than referencing switch data.

I also discovered the reason for the hang was user error. I adjusted so the output was 'file at path' and re-wrote that portion accordingly, and it started to error rather than not process which was good progress. After that, I was able to see what it was erroring on and fix it. Now it completely runs with no issues at all.

Thanks for the reply. I probably would have gone ages without adding that single line to simplify everything