#135 Some batch/shell script user interaction suggestions

[Gabriel Zanetti]

Hi all!

First of all, I just wanted to say you're doing a great work here :) I've been using JSW for almost 9 years now and I can't believe how much it has evolved.

However, as in any ever-evolving piece of software I think there are a some points to improve. It's worth mentioning that I'm using the WrapperListener integration method and launching my services by means of the command based batch/script file.

1. Unnecessary user input request: I noticed some of the .bat files used as templates have some pause calls. EG: after echoing Unable to locate a Wrapper executable using any of the following names a pause is executed. This is awfully bad. I created a simple GUI that calls the .bat file and executing a process that requires user input (for no reason at all) requires some more management of the output/input streams that should be unnecessary. Removing all pause calls from the .bat files does not reduce usability at all and decreases debugging time and the time to workaround this too.
2. The app.sh and app.bat files are really cool. Clearly, app.sh does magic to guess how to start/install/etc the daemons in the different platforms. However, I think some extra magic can be done there.
   1. Lack of information: the app.sh script does not output whether the daemon is running and/or is installed when querying its status. However, it is possible to know that for most (if not all) the different platforms. Furthermor, it is already implemented and even output: gettext '$APP_LONG_NAME is already running.'. In fact, shouldn't there an isInstalled() and isRunning() functions be extracted that would receive the platform as a parameter and perform the needed checks? Probably that would reduce repetition of some unfriendly if statements that perform related checks.
   2. Lack of uniformity: the app.sh and the app.bat script should be more related. I perfectly understand mixing so many platforms is mess, as there are things that are supported by some and unsopported by others. However, there are things that can be done in both platforms, and despite their differences, aim at the same result. For example, the output of commands. It is considerably different in content (as mentioned in 2.1) and in their format as well, such as the wrapperm | text added to the output of the Windows calls. Also the Windows calls result in no change in the exit code of the process while the Linux ones take some considerations and return non-zero exit codes given certain situations.

I'm pretty sure they would ease (at least to me) how the services/daemons are interacted programatically with. All of these resulted in me falling back to calling a Java Runtime.exec() and displaying my end users the output of the commands while, ideally, I should have some kind of uniform API to query for the information, status, and operation result of all the command line interactions. As I can't do this I must leave the next steps up to the user, once he interprets the output. The only thing I could wrap is checking if a daemon is installed by running a status and checking if the output contains the string is running.

I don't really know if all these actually make sense but I just felt I had to write them down. I hope this helps and again, keep it up, you're doing a great job :)

Regards,
Gabriel

[Maxime Andrighetto]

Hello Gabriel,

Thank you very much for your feedback.

About the .bat file: I understand that in your case any user input is
causing trouble, but on the other hand, some users launch the bat file
directly from the explorer. Without a 'pause' before the end of the script,
the command prompt would disappear right after it is executed without
leaving enough time to read the messages if an error happened. By default
we choose to pause he Wrapper if there was any error and let the script
finish normally otherwise. However the script files in the src/bin folder
are aimed to be customized, and you could easily edit them to remove
undesired commands.

Improving the outputs when querying the status of a daemon process, as well
as improving our return codes (for LSB compliance) is already in our
roadmap. We will also probably have to restructure the code and some
conditions as you advised. However, all of this has to be done with the
concern not to break backward compatibility for the users already using the
scripts, and thus some of the changes have been decided not to be pushed in
a minor release.

Windows services and UNIX daemon processes are actually quite different.
Actions like installing, removing, starting or stopping a Windows services
have to be done by the Wrapper itself, whereas on Unix it is a common
practice to use script file.

The "wrapperm |" text is formatted by the Wrapper log system and was added
to the output on Windows to help differentiate which log entries are coming
from Wrapper invocations used to control the Wrapper as a service. Similar
actions on Unix are handled by the script, but the script will only output
messages in the terminal without using the Wrapper log system.

The advantage of having a script file on Unix platforms is that it can
easily be customized by the users. But putting the script logic into the
Wrapper code in order to standardize the functioning on different platforms
might also be a good option for a future release.

Your feedback is greatly appreciated and useful to improve the Wrapper.
Please let us know if you have further remarks or questions.

Best Regards,

Maxime

On Wed, Apr 27, 2016 at 12:46 PM, Gabriel Zanetti the-prophet@users.sf.net
wrote:

---

• [feature-requests:#135]
  https://sourceforge.net/p/wrapper/feature-requests/135/ Some batch/shell
  script user interaction suggestions*

Status: open
Group: Next_Release
Created: Wed Apr 27, 2016 03:46 AM UTC by Gabriel Zanetti
Last Updated: Wed Apr 27, 2016 03:46 AM UTC
Owner: nobody

Hi all!

First of all, I just wanted to say you're doing a great work here :) I've
been using JSW for almost 9 years now and I can't believe how much it has
evolved.

However, as in any ever-evolving piece of software I think there are a
some points to improve. It's worth mentioning that I'm using the
WrapperListener integration method and launching my services by means of
the command based batch/script file.

1. Unnecessary user input request: I noticed some of the .bat files
   used as templates have some pause calls. EG: after echoing Unable to
   locate a Wrapper executable using any of the following names a pause
   is executed. This is awfully bad. I created a simple GUI that calls the
   .bat file and executing a process that requires user input (for no reason
   at all) requires some more management of the output/input streams that
   should be unnecessary. Removing all pause calls from the .bat files does
   not reduce usability at all and decreases debugging time and the time to
   workaround this too.
2. The app.sh and app.bat files are really cool. Clearly, app.sh does
   magic to guess how to start/install/etc the daemons in the different
   platforms. However, I think some extra magic can be done there.
   1. Lack of information: the app.sh script does not output whether
      the daemon is running and/or is installed when querying its status.
      However, it is possible to know that for most (if not all) the different
      platforms. Furthermor, it is already implemented and even output: gettext
      '$APP_LONG_NAME is already running.'. In fact, shouldn't there an
      isInstalled() and isRunning() functions be extracted that would
      receive the platform as a parameter and perform the needed checks? Probably
      that would reduce repetition of some unfriendly if statements that perform
      related checks.
   2. Lack of uniformity: the app.sh and the app.bat script should be
      more related. I perfectly understand mixing so many platforms is mess, as
      there are things that are supported by some and unsopported by others.
      However, there are things that can be done in both platforms, and despite
      their differences, aim at the same result. For example, the output of
      commands. It is considerably different in content (as mentioned in 2.1) and
      in their format as well, such as the wrapperm | text added to the
      output of the Windows calls. Also the Windows calls result in no change in
      the exit code of the process while the Linux ones take some considerations
      and return non-zero exit codes given certain situations.

I'm pretty sure they would ease (at least to me) how the services/daemons
are interacted programatically with. All of these resulted in me falling
back to calling a Java Runtime.exec() and displaying my end users the
output of the commands while, ideally, I should have some kind of uniform
API to query for the information, status, and operation result of all the
command line interactions. As I can't do this I must leave the next steps
up to the user, once he interprets the output. The only thing I could wrap
is checking if a daemon is installed by running a status and checking if
the output contains the string is running.

I don't really know if all these actually make sense but I just felt I had
to write them down. I hope this helps and again, keep it up, you're doing a
great job :)

Regards,
Gabriel

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/wrapper/feature-requests/135/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Maxime Andrighetto]

Hello Gabriel,

We have just released a new version (3.5.30) of the Java Service Wrapper.

In this new version we improved the outputs when querying the status of a
daemon process.
It will now show whether the service is installed or not, and which system
is used if there are several possibilities for the current OS (init.d,
systemd, etc.).

We have still some points to improve in our script for the coming releases
and we keep in mind the precious feedback that you sent before.

The new version can be downloaded on sourceforge or from our website:
http://wrapper.tanukisoftware.com/doc/english/download.jsp

You may have a look at the release notes for a full list of changes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Best Regards,

Maxime

On Wed, Apr 27, 2016 at 7:02 PM, Maxime Andrighetto <maxime-tsl@users.sf.net

wrote:

Hello Gabriel,

Thank you very much for your feedback.

About the .bat file: I understand that in your case any user input is
causing trouble, but on the other hand, some users launch the bat file
directly from the explorer. Without a 'pause' before the end of the script,
the command prompt would disappear right after it is executed without
leaving enough time to read the messages if an error happened. By default
we choose to pause he Wrapper if there was any error and let the script
finish normally otherwise. However the script files in the src/bin folder
are aimed to be customized, and you could easily edit them to remove
undesired commands.

Improving the outputs when querying the status of a daemon process, as well
as improving our return codes (for LSB compliance) is already in our
roadmap. We will also probably have to restructure the code and some
conditions as you advised. However, all of this has to be done with the
concern not to break backward compatibility for the users already using the
scripts, and thus some of the changes have been decided not to be pushed in
a minor release.

Windows services and UNIX daemon processes are actually quite different.
Actions like installing, removing, starting or stopping a Windows services
have to be done by the Wrapper itself, whereas on Unix it is a common
practice to use script file.

The "wrapperm |" text is formatted by the Wrapper log system and was added
to the output on Windows to help differentiate which log entries are coming
from Wrapper invocations used to control the Wrapper as a service. Similar
actions on Unix are handled by the script, but the script will only output
messages in the terminal without using the Wrapper log system.

The advantage of having a script file on Unix platforms is that it can
easily be customized by the users. But putting the script logic into the
Wrapper code in order to standardize the functioning on different platforms
might also be a good option for a future release.

Your feedback is greatly appreciated and useful to improve the Wrapper.
Please let us know if you have further remarks or questions.

Best Regards,

Maxime

On Wed, Apr 27, 2016 at 12:46 PM, Gabriel Zanetti the-prophet@users.sf.net
wrote:

---

• [feature-requests:#135]
  https://sourceforge.net/p/wrapper/feature-requests/135/
  https://sourceforge.net/p/wrapper/feature-requests/135/ Some
  batch/shell
  script user interaction suggestions*

Status: open
Group: Next_Release
Created: Wed Apr 27, 2016 03:46 AM UTC by Gabriel Zanetti
Last Updated: Wed Apr 27, 2016 03:46 AM UTC
Owner: nobody

Hi all!

First of all, I just wanted to say you're doing a great work here :) I've
been using JSW for almost 9 years now and I can't believe how much it has
evolved.

However, as in any ever-evolving piece of software I think there are a
some points to improve. It's worth mentioning that I'm using the
WrapperListener integration method and launching my services by means of
the command based batch/script file.

1. Unnecessary user input request: I noticed some of the .bat files
   used as templates have some pause calls. EG: after echoing Unable to
   locate a Wrapper executable using any of the following names a pause
   is executed. This is awfully bad. I created a simple GUI that calls the
   .bat file and executing a process that requires user input (for no
   reason
   at all) requires some more management of the output/input streams that
   should be unnecessary. Removing all pause calls from the .bat files
   does
   not reduce usability at all and decreases debugging time and the time
   to
   workaround this too.
2. The app.sh and app.bat files are really cool. Clearly, app.sh does
   magic to guess how to start/install/etc the daemons in the different
   platforms. However, I think some extra magic can be done there.
   1. Lack of information: the app.sh script does not output whether
      the daemon is running and/or is installed when querying its status.
      However, it is possible to know that for most (if not all) the
      different
      platforms. Furthermor, it is already implemented and even output:
      gettext
      '$APP_LONG_NAME is already running.'. In fact, shouldn't there an
      isInstalled() and isRunning() functions be extracted that would
      receive the platform as a parameter and perform the needed checks?
      Probably
      that would reduce repetition of some unfriendly if statements that
      perform
      related checks.
   2. Lack of uniformity: the app.sh and the app.bat script should be
      more related. I perfectly understand mixing so many platforms is
      mess, as
      there are things that are supported by some and unsopported by
      others.
      However, there are things that can be done in both platforms, and
      despite
      their differences, aim at the same result. For example, the output
      of
      commands. It is considerably different in content (as mentioned in
      2.1) and
      in their format as well, such as the wrapperm | text added to the
      output of the Windows calls. Also the Windows calls result in no
      change in
      the exit code of the process while the Linux ones take some
      considerations
      and return non-zero exit codes given certain situations.

I'm pretty sure they would ease (at least to me) how the services/daemons
are interacted programatically with. All of these resulted in me falling
back to calling a Java Runtime.exec() and displaying my end users the
output of the commands while, ideally, I should have some kind of uniform
API to query for the information, status, and operation result of all the
command line interactions. As I can't do this I must leave the next steps
up to the user, once he interprets the output. The only thing I could wrap
is checking if a daemon is installed by running a status and checking if
the output contains the string is running.

I don't really know if all these actually make sense but I just felt I had
to write them down. I hope this helps and again, keep it up, you're doing a
great job :)

Regards,
Gabriel

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/wrapper/feature-requests/135/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

---

• [feature-requests:#135]
  https://sourceforge.net/p/wrapper/feature-requests/135/ Some batch/shell
  script user interaction suggestions*

Status: open
Group: Next_Release
Created: Wed Apr 27, 2016 03:46 AM UTC by Gabriel Zanetti
Last Updated: Wed Apr 27, 2016 03:46 AM UTC
Owner: nobody

Hi all!

First of all, I just wanted to say you're doing a great work here :) I've
been using JSW for almost 9 years now and I can't believe how much it has
evolved.

However, as in any ever-evolving piece of software I think there are a
some points to improve. It's worth mentioning that I'm using the
WrapperListener integration method and launching my services by means of
the command based batch/script file.

1. Unnecessary user input request: I noticed some of the .bat files
   used as templates have some pause calls. EG: after echoing Unable to
   locate a Wrapper executable using any of the following names a pause
   is executed. This is awfully bad. I created a simple GUI that calls the
   .bat file and executing a process that requires user input (for no reason
   at all) requires some more management of the output/input streams that
   should be unnecessary. Removing all pause calls from the .bat files does
   not reduce usability at all and decreases debugging time and the time to
   workaround this too.
2. The app.sh and app.bat files are really cool. Clearly, app.sh does
   magic to guess how to start/install/etc the daemons in the different
   platforms. However, I think some extra magic can be done there.
   1. Lack of information: the app.sh script does not output whether
      the daemon is running and/or is installed when querying its status.
      However, it is possible to know that for most (if not all) the different
      platforms. Furthermor, it is already implemented and even output: gettext
      '$APP_LONG_NAME is already running.'. In fact, shouldn't there an
      isInstalled() and isRunning() functions be extracted that would
      receive the platform as a parameter and perform the needed checks? Probably
      that would reduce repetition of some unfriendly if statements that perform
      related checks.
   2. Lack of uniformity: the app.sh and the app.bat script should be
      more related. I perfectly understand mixing so many platforms is mess, as
      there are things that are supported by some and unsopported by others.
      However, there are things that can be done in both platforms, and despite
      their differences, aim at the same result. For example, the output of
      commands. It is considerably different in content (as mentioned in 2.1) and
      in their format as well, such as the wrapperm | text added to the
      output of the Windows calls. Also the Windows calls result in no change in
      the exit code of the process while the Linux ones take some considerations
      and return non-zero exit codes given certain situations.

I'm pretty sure they would ease (at least to me) how the services/daemons
are interacted programatically with. All of these resulted in me falling
back to calling a Java Runtime.exec() and displaying my end users the
output of the commands while, ideally, I should have some kind of uniform
API to query for the information, status, and operation result of all the
command line interactions. As I can't do this I must leave the next steps
up to the user, once he interprets the output. The only thing I could wrap
is checking if a daemon is installed by running a status and checking if
the output contains the string is running.

I don't really know if all these actually make sense but I just felt I had
to write them down. I hope this helps and again, keep it up, you're doing a
great job :)

Regards,
Gabriel

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/wrapper/feature-requests/135/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/