bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question


From: Saint Michael
Subject: Re: Question
Date: Mon, 11 Sep 2017 15:04:48 -0400

Dear Bob
I use Linux. My business to provide services for problems that I solve, as
you mention, by calling Awk, sed, join, etc., and databases. I allow my
customers to login to a box that I provide in my datacenter. I cannot
accept that it is impossible to restrict them to only call my *,sh scripts.
I found a company that has a nice obfuscating and encrypting product for
shell script, and I am trying it. I am no worried only about passwords, but
the overall logic itself.

Many thanks for the time you took to respond. But in this case you fall
close to an error. The market needs a tool so we can generate solutions and
also protect our intellectual property. I am not smart enough to write it,
but somebody will.

Yours

Federico

On Mon, Sep 11, 2017 at 2:54 PM, Bob Proulx <bob@proulx.com> wrote:

> Saint Michael wrote:
> > Dear Maintainer
>
> Note that I am not the maintainer.
>
> > Is there a commercial or free software that can take a Bash script and
> > transparently turn it into a C executable, provided the machines where it
> > runs has any of the external commands like awk, etc?
>
> Not as far as I am aware.  And since no one else has spoken up with a
> suggestion then I assume not.
>
> > Something like a Java virtual machine, for Shell.
>
> Yes.  That already exists!  It is the bash shell interpreter itself.
> If you install a JVM then it can interpret Java programs.  If you
> install bash then it can interpret bash programs.  Same thing.
>
> The underlying issue is that shells are by design mostly there to
> invoke external programs.  Therefore most of the activity of the shell
> is to run other programs such as awk, grep, sed, and so forth.  It
> isn't enough to have only the bash program but also the entire set of
> other programs that is invoked.  Java by comparison can also execute
> external programs but since that is not the primary design goal of it
> most Java programs do not spend 99% of their code doing so.
>
> > I think this language is powerful and I want to distribute some
> > tools that contain critical information.
> >
> > So far I have been googling and there is only obfuscation tools, not
> > compilation tools.
>
> Making a shell script compiler would be a very hard problem because
> the shell is an interpretive language with a primary task of invoking
> external programs.  It would be very, very hard.  Impossible actually.
> The nature of interpretive languages are that they can do things that
> compiled languages cannot do.  For example interpreted programs can
> generate code on the fly and interpret it.  Such as creating functions
> during runtime.  Such as dynamically creating and executing code based
> upon dynamic input.  Such tasks are easily done using an interpreted
> language but must be done differently when using a compiled language.
> One cannot create a compiler that can compile every capability of an
> interpreted language without itself embedding an interpreter for that
> language.
>
> If you restrict an interpretive language down to only features that
> can be compiled then it is always possible to write a compiler for it.
> But then it is for a restricted set of language features as compared
> to the original language.  It is a different language.  Sometimes this
> is an acceptable tradeoff.  But I will hazard a guess that for the
> shell and for programs written for it this would be a quite different
> language and no longer useful.  Possible.  But not useful.
>
> > I think this language is powerful and I want to distribute some
> > tools that contain critical information.
>
> You don't say what critical information you are talking about.  But it
> makes me think things like accounts and passwords that you would not
> want to be available in clear text.  Note that obfuscating them in a
> compiled program does not make them inaccessible.
>
> You also don't say which OS you are using.  Most of us here will
> probably be using a GNU/Linux distribution which includes the shell
> natively or the Apple Mac which includes a working environment.
> Therefore I will assume you are using MS-Windows.  I suggest either
> bundling an entire environment such as MinGW such as Bash for Windows
> or Cygwin so that all of your external dependencies are satisfied.
> Or using a different language such as C which is natively compiled.
> Or using a restricted set of Perl, Python, Ruby, or other that already
> has a compiler available for that restricted subset.
>
> Bob
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]