bug-bash
[Top][All Lists]
Advanced

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

Re: Question


From: Bob Proulx
Subject: Re: Question
Date: Mon, 11 Sep 2017 12:54:15 -0600
User-agent: NeoMutt/20170609 (1.8.3)

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]