Page 1 of 1

Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 10:21 am
by thatkeith
I want to make a shell call in an app – driving exiftool, which is bundled into the app. I have this working fine in the Mac version, but I'm having trouble getting it to play ball in Windows. It doesn't help that I don't have easy access to a PC for testing – I know, I know, forgive me please! :)

Given that the LC-generated .exe sits next to the "Dependencies/Win/exiftool.exe" directory structure (as set up in the standalone generation process), and I also need to use a file path acquired through 'answer file' (which of course uses regular slashes rather than back slashes as the path delimiter), how should I go about creating the paths that I use in the shell call? Or, to put it another way, could someone tell me what dumb mistake I am making in the following lines?

Code: Select all

put quote & "Dependencies\Win\exiftool.exe" & quote into exifToolPath
replace "/" with "\" in field "path"
put exifToolPath && field "command" && field "path"  into newExif
put shell (newExif) into tResult
k

Re: Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 11:36 am
by Klaus
Hi Keith,

could you please explain this a bit more? "next to" is a bit vague :D
the LC-generated .exe sits next to the "Dependencies/Win/exiftool.exe" directory
Maybe -> specialfolderpath("engine") is helpful here?


Best

Klaus

Re: Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 11:38 am
by AxWald
Hi,

when calling "Shell" you must use backslashes ("\"). A good way to achieve this is using a function like that:

Code: Select all

function winshell what
   replace "/" with "\" in what
   set the hideConsoleWindows to true
   return shell(what)
end winshell
Should there be slashes they'll be corrected. And the flickering of the command line window is avoided.

Further, you'll save yourself a lot of troubles if you put quotes around all paths. To avoid unreadable code, use another function:

Code: Select all

function kwote what
   return quote & what & quote
end kwote
Now, assuming your fld "command" contains some parameteres, your code could look like:

Code: Select all

   put "Dependencies/Win/exiftool.exe" into exifToolPath
   put kwote(exifToolPath) && field "command" && kwote(field "path")  into newExif
   put winshell (newExif) into tResult
One more thing that could go wrong is the relative paths you're using. In this case your Standalone (.exe) should be in the same location as the folder "Dependencies".

I have learned to write such as "./Dependencies/Win/exiftool.exe" - if I have to debug later I see immediately this is a relative path I have coded, and not a part of a "calculated" path meant for further concatenating ...

Edit:
I just happened to crash into something that may be of interest here:
"Shell" works in the current "defaultFolder", so be careful when setting this & using "shell" with relative paths!

Have fun!

Re: Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 12:07 pm
by thatkeith
Klaus wrote:could you please explain this a bit more? "next to" is a bit vague :D
Heh. Yes, I guess it is. I meant in the same directory as the LC-produced .exe. Advice on better ways of doing this (and other things) is always appreciated! :lol:

Re: Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 12:09 pm
by thatkeith
Klaus and AxWald, thanks for the tips! I'll dive into this later today.

k

Re: Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 12:10 pm
by thatkeith
AxWald wrote: Edit:
I just happened to crash into something that may be of interest here:
"Shell" works in the current "defaultFolder", so be careful when setting this & using "shell" with relative paths!

Have fun!
Wow. Good to know! I'll keep this in mind as I, er, have fun. ;)

k

Re: Paths in shell calls in Windows & Mac

Posted: Fri Aug 05, 2016 5:59 pm
by thatkeith
Okay, confession time. I had got it right in one button's script... but failed to edit that of a second button. I know I should make my code more centralised, and this is a timely reminder. :oops: