Linux bash & cfexecute & Lucee

Hi,
I can not fix this problem:

cfhttp.cfm:

bash script mozjpeg.sh:
#!/bin/bash
/opt/mozjpeg/bin/cjpeg -quality 80 /var/www/website/tmp/_$1.jpg > /var/www/
website/tmp/moz$1.jpg

When I start for the first time cfhttp.cfm get this error:

https://lh3.googleusercontent.com/-D_38mVkijt8/Vtd3y7Y9BhI/AAAAAAAACmA/GdI-sxT_1cY/s1600/moz.png

If I run the second time (I update the page) the problem goes away (Jpeg
file is created correctly)
! This in all situations.
I tried to run bash /var/www/website/import/sh/mozjpeg.sh _97341 from the
shell and it works the first time.

How can I fix?

are you sure that the file exists and that there are no permissions
issues when you call cfexecute?

try to check with calling before
calling execute.

when you run the bash from shell then you are most likely doing it under
a different user, so possibly permission issues at play here.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 3/2/2016 3:32 PM, Ivan wrote:

Hi,
I can not fix this problem:

cfhttp.cfm:
|
<cfexecutename=“bash"arguments=”/var/www/website/import/sh/mozjpeg.sh
#NuovaImg#"timeout="600"variable=“result”/>

|

bash script mozjpeg.sh:
|
#!/bin/bash
/opt/mozjpeg/bin/cjpeg -quality 80/var/www/website/tmp/_$1.jpg

/var/www/website/tmp/moz$1.jpg
|

When I start for the first time cfhttp.cfm get this error:

https://lh3.googleusercontent.com/-D_38mVkijt8/Vtd3y7Y9BhI/AAAAAAAACmA/GdI-sxT_1cY/s1600/moz.png

If I run the second time /(I update the page)/ the problem goes away
/(Jpeg file is created correctly)/! This in all situations.
I tried to run bash /var/www/website/import/sh/mozjpeg.sh _97341 from
the shell and it works the first time.

How can I fix?


Love Lucee? Become a supporter and be part of the Lucee project today!


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/c8a4a6f4-8a83-464d-aa8d-f321806e53f0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/c8a4a6f4-8a83-464d-aa8d-f321806e53f0%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

Hi Igal,
I included fileExists() before cfexecute. At the first run return false. If
I update, return true.

I confirm. It would seem that so many cfexecute one after the other is not
good. I grouped all in a bash file.

I may have found where the error…

Before I have others cfexecute. It 'possible that the first
are not completed and the seconds fail.

I do the tests.

I wonder is there a way to instantiate a shell and keep it resident in memory across cfexecute commands, or through some other as yet unbuilt feature? Could be very useful in a case like Ivan’s where multiple commands need to be run. I know I have written code that used multiple shell commands in a single method, and it would seem like a good thing for commands that are going to be executed in sequence within the same context/thread be able to share the same instance of the shell.

FYI, I know in Ivan’s case he was able to solve his issue by putting all the commands in a single sh file, but there would invariably be cases where that solution doesn’t work because other things are going on inside the code in between individual shell calls.

Is this issue resonating with anyone else? I have been pining for a better method of CLI integration than what cfexecute has always offered. Looking at the Java.lang.Runtime class, it doesn’t look like there is a way to persist a process within the context of an exec() method call, but maybe some of the more expert Java coders know something I don’t about it.

I know you can do something like this:

process_runtime = local.runtime.getRuntime();
process_exec = local.process_runtime.exec( javacast( "string[]", ["bash", "-c", str ]) );
exitCode = local.process_exec.waitFor();
process_exec2 = local.process_runtime.exec( javacast( "string[]", ["bash", "-c", str2 ]) );
exitCode = local.process_exec.waitFor();

but you are still instantiating a new bash shell with each .exec() method call.

I realize leaving it open could be playing with fire and maybe that’s why java.lang.Runtime calls each exec() in a separate process. It just seems like there should be a better way to integrate with the shell than what currently exists.

Robert> On Mar 3, 2016, at 1:08 AM, Ivan <@Ivan> wrote:

I confirm. It would seem that so many cfexecute one after the other is not good. I grouped all in a bash file.


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/14ab8bd9-9502-458d-9dec-41c884eb00f8%40googlegroups.com https://groups.google.com/d/msgid/lucee/14ab8bd9-9502-458d-9dec-41c884eb00f8%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

Maybe. I am specifically thinking about a use case where some processes have to be run inside the Lucee environment in between executions of shell scripts. You can use the script version I showed below to get stdout and stderr if the process returns correctly, but it will still close the shell after executing.

The solution I have found is to connect to the console via an SSH client like Ganymede Ganymed SSH-2 for Java http://www.ganymed.ethz.ch/ssh2/

You can instantiate an SSH session and pass it commands to execute, then close the session when done. That does not seem like it would scale, though.> On Mar 3, 2016, at 9:13 PM, Michael Sprague <@Michael_Sprague> wrote:

Don’t have an answer to your question but in cases when an existing/static sh file won’t suffice couldn’t one be written dynamically and then executed? Just a thought.

Mike

On Thu, Mar 3, 2016 at 11:49 PM, Robert Munn <@Robert_Munn mailto:Robert_Munn> wrote:
I wonder is there a way to instantiate a shell and keep it resident in memory across cfexecute commands, or through some other as yet unbuilt feature? Could be very useful in a case like Ivan’s where multiple commands need to be run. I know I have written code that used multiple shell commands in a single method, and it would seem like a good thing for commands that are going to be executed in sequence within the same context/thread be able to share the same instance of the shell.

FYI, I know in Ivan’s case he was able to solve his issue by putting all the commands in a single sh file, but there would invariably be cases where that solution doesn’t work because other things are going on inside the code in between individual shell calls.

Is this issue resonating with anyone else? I have been pining for a better method of CLI integration than what cfexecute has always offered. Looking at the Java.lang.Runtime class, it doesn’t look like there is a way to persist a process within the context of an exec() method call, but maybe some of the more expert Java coders know something I don’t about it.

I know you can do something like this:

process_runtime = local.runtime.getRuntime();
process_exec = local.process_runtime.exec( javacast( “string[]”, [“bash”, “-c”, str ]) );
exitCode = local.process_exec.waitFor();
process_exec2 = local.process_runtime.exec( javacast( “string[]”, [“bash”, “-c”, str2 ]) );
exitCode = local.process_exec.waitFor();

but you are still instantiating a new bash shell with each .exec() method call.

I realize leaving it open could be playing with fire and maybe that’s why java.lang.Runtime calls each exec() in a separate process. It just seems like there should be a better way to integrate with the shell than what currently exists.

Robert

On Mar 3, 2016, at 1:08 AM, Ivan <@Ivan mailto:Ivan> wrote:

I confirm. It would seem that so many cfexecute one after the other is not good. I grouped all in a bash file.


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/14ab8bd9-9502-458d-9dec-41c884eb00f8%40googlegroups.com https://groups.google.com/d/msgid/lucee/14ab8bd9-9502-458d-9dec-41c884eb00f8%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2E2850F5-EE9E-4365-AA2B-9167C49B6DA4%40gmail.com https://groups.google.com/d/msgid/lucee/2E2850F5-EE9E-4365-AA2B-9167C49B6DA4%40gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB1Zp0%2Bbw%2BkZ%2Bm_6PMoA5ak6M%2BrWPfNoHTpsG0FovsPQPSVWRg%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAB1Zp0%2Bbw%2BkZ%2Bm_6PMoA5ak6M%2BrWPfNoHTpsG0FovsPQPSVWRg%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

cfexecute doesn’t scale, period. 1000 cfexecutes will bring your system to
a halt. Furthermore, when doing anything file system intensive, cfexecute
will often return before i/o is actually complete, further complicating
processing within CFML, and often requiring logic that not just waits for
the files existence, but it’s completion.

At the end of the day, cfexecute is not, generally, a good option. The best
options are generally finding a .jar that does what you want and
implementing that instead of going to the OS level. For apps that don’t
have many concurrent users (e.g. admin interfaces) cfexecute is fine, but
if you need to scale, its just not the right tool for the job :slight_smile:

– DennyOn Sunday, March 6, 2016 at 1:51:48 PM UTC-5, Robert Munn wrote:

Maybe. I am specifically thinking about a use case where some processes
have to be run inside the Lucee environment in between executions of shell
scripts. You can use the script version I showed below to get stdout and
stderr if the process returns correctly, but it will still close the shell
after executing.

The solution I have found is to connect to the console via an SSH client
like Ganymede Ganymed SSH-2 for Java

You can instantiate an SSH session and pass it commands to execute, then
close the session when done. That does not seem like it would scale, though.

On Mar 3, 2016, at 9:13 PM, Michael Sprague <mikes...@gmail.com <javascript:>> wrote:

Don’t have an answer to your question but in cases when an existing/static
sh file won’t suffice couldn’t one be written dynamically and then
executed? Just a thought.

Mike

On Thu, Mar 3, 2016 at 11:49 PM, Robert Munn <robert...@gmail.com <javascript:>> wrote:

I wonder is there a way to instantiate a shell and keep it resident in
memory across cfexecute commands, or through some other as yet unbuilt
feature? Could be very useful in a case like Ivan’s where multiple
commands need to be run. I know I have written code that used multiple
shell commands in a single method, and it would seem like a good thing for
commands that are going to be executed in sequence within the same
context/thread be able to share the same instance of the shell.

FYI, I know in Ivan’s case he was able to solve his issue by putting all
the commands in a single sh file, but there would invariably be cases where
that solution doesn’t work because other things are going on inside the
code in between individual shell calls.

Is this issue resonating with anyone else? I have been pining for a
better method of CLI integration than what cfexecute has always offered.
Looking at the Java.lang.Runtime class, it doesn’t look like there is a way
to persist a process within the context of an exec() method call, but maybe
some of the more expert Java coders know something I don’t about it.

I know you can do something like this:

process_runtime = local.runtime.getRuntime();
process_exec = local.process_runtime.exec( javacast( “string[]”, [“bash”,
“-c”, str ]) );
exitCode = local.process_exec.waitFor();
process_exec2 = local.process_runtime.exec( javacast( “string[]”, [“bash”
, “-c”, str2 ]) );
exitCode = local.process_exec.waitFor();

but you are still instantiating a new bash shell with each .exec() method
call.

I realize leaving it open could be playing with fire and maybe that’s why
java.lang.Runtime calls each exec() in a separate process. It just seems
like there should be a better way to integrate with the shell than what
currently exists.

Robert

On Mar 3, 2016, at 1:08 AM, Ivan <ivan....@gmail.com <javascript:>> wrote:

I confirm. It would seem that so many cfexecute one after the other is
not good. I grouped all in a bash file.


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/14ab8bd9-9502-458d-9dec-41c884eb00f8%40googlegroups.com
https://groups.google.com/d/msgid/lucee/14ab8bd9-9502-458d-9dec-41c884eb00f8%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/2E2850F5-EE9E-4365-AA2B-9167C49B6DA4%40gmail.com
https://groups.google.com/d/msgid/lucee/2E2850F5-EE9E-4365-AA2B-9167C49B6DA4%40gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAB1Zp0%2Bbw%2BkZ%2Bm_6PMoA5ak6M%2BrWPfNoHTpsG0FovsPQPSVWRg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAB1Zp0%2Bbw%2BkZ%2Bm_6PMoA5ak6M%2BrWPfNoHTpsG0FovsPQPSVWRg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Robert, would you have time to post a little snippet of how you use
Ganymede?