I was recently trying to install some packages on a terminal emulator of
non-rooted Android phone. The terminal emulator has installed all the
Unix system programs in a separate directory and included that directory
in all its search paths.
As a result, the command `/bin/sh' is not recognized when you run it on
the terminal, but the command `sh' is.
Because of this, when you run `./configure' on the terminal emulator it
complains with an error that it can't run `bin/sh' or later, can't build
I was able to solve the second problem by defining `CONFIG_SHELL' which
will replace `/bin/sh' everywhere in the output `configure' script.
However, running `./configure' would still complain about not being able
to run `bin/sh'.
This was very strange for me, because I had set `CONFIG_SHELL'.
After a look, I noticed that the first line of the output `configure'
The error was caused by this line. When I manually removed it from
`configure', the configure script ran successfully and I was able to
build, check install programs.
It would be great if this first line of the configure script would also
check for `CONFIG_SHELL' (if its possible), instead of directly calling
Thank you very much for all the wonderful work on GNU Autoconf.
On Thu, Jul 13, 2017 at 9:46 PM, Paul Eggert <[hidden email]> wrote:
> Mohammad Akhlaghi wrote:
>> It would be great if this first line of the configure script would also
>> check for `CONFIG_SHELL'
> Unfortunately this does not work, as the operating system handles the first
> line before the configure script starts.
A hardcoded binary path isn't portable, the correct solution is to use
`env sh`. Typically this is seen as:
Which technically causes the same problem Mr. Akhlagi was
experiencing, but on most desktop Unixes the location of `env` is more
predictable than the location of various interpreters.
> A hardcoded binary path isn't portable, the correct solution is to use
> `env sh`. Typically this is seen as:
> #!/usr/bin/env sh
> Which technically causes the same problem Mr. Akhlagi was
> experiencing, but on most desktop Unixes the location of `env` is more
> predictable than the location of various interpreters.
I am extremely dubious that the location of env is more predictable than
/bin/sh. python or perl or whatnot, yes, but not /bin/sh, which is
probably the most hard-coded path in UNIX.
But more to the point for this specific request, it would surprise me a
good deal if Android would move sh and not also move env to some other
directory than /usr/bin. If you're going to break compatibility that
much, it's unlikely you're going to keep compatibility for env. But,
well, I've been surprised before....
On Thu, Jul 13, 2017 at 11:24 PM, Russ Allbery <[hidden email]> wrote:
> R0b0t1 <[hidden email]> writes:
>> A hardcoded binary path isn't portable, the correct solution is to use
>> `env sh`. Typically this is seen as:
>> #!/usr/bin/env sh
>> Which technically causes the same problem Mr. Akhlagi was
>> experiencing, but on most desktop Unixes the location of `env` is more
>> predictable than the location of various interpreters.
> I am extremely dubious that the location of env is more predictable than
> /bin/sh. python or perl or whatnot, yes, but not /bin/sh, which is
> probably the most hard-coded path in UNIX.
Yes, that's why I mentioned it. He could just call `env` but at the
same time he can also just call `sh`.
> But more to the point for this specific request, it would surprise me a
> good deal if Android would move sh and not also move env to some other
> directory than /usr/bin. If you're going to break compatibility that
> much, it's unlikely you're going to keep compatibility for env. But,
> well, I've been surprised before....
I agree, with the added comment that it's probably not wise to
consider Android to be a flavor of Unix. It actively prevents you from
using your hardware for general purpose computing and has a set of
very restrictive design goals.
It is my personal opinion that you should give up on whatever it is
you are trying to do, Mr. Akhlagi, and try to use a normal Linux
distribution instead of Android and set up a cross compiler for your
system. Even then you will run into problems as autoconf and its tests
were not necessarily designed to support cross compilation.
This leaves you in the position where you are doing what you are now,
trying to compile things on device, which can take multiple days for
large software packages. If you are interested in the ARM architecture
I suggest finding a low cost server. I can reply with an example
(perhaps the only example) if you want, otherwise I'd just as well
leave the link off of the list.
If you want to continue as you are I suggest you will get more out of
researching the changes Android made to Linux than you will out of
following up with each project you experience issues with. The Android
system architecture description has a list of changes in it and what
they break, which is essentially everything.
Thank you very much everyone for the great comments.
I can confirm that on this Android phone there is no `/usr' directory
either (it also doesn't have any `/bin' directory)! So a `#!/usr/bin/env
sh' first line would have a similar fate.
I do all my serious work with my GNU/Linux systems on my desktop and
laptop computers. But I have always been bothered by the fact that we
have such physically-portable and powerful devices (smartphones) with us
every where, but I can't use it as a simple command-line tool (with my
own programs as I do on my GNU/Linux system). It is a real shame!
In short, this is more like a hobby for me to have my most commonly used
command-line programs running natively on my phone to use in occasions
when I don't have my (physically) larger GNU/Linux systems nearby.
So I searched for a terminal emulator app for my smartphone and found
Termux (https://termux.com/). It uses the apt (Debian) package manager
to download and install pre-compiled most necessary low-level
command-line programs like a compiler and Make and etc (installed in
`/data/datacom.termux/files/usr'). However, I couldn't get the configure
script for my programs running until yesterday that I randomly started
playing with it again and found the cause and reported it to you.
I understand why Shebangs (
https://en.wikipedia.org/wiki/Shebang_%28Unix%29 ) would be necessary
for non-shell interpretters (like a Python script having a `#!
/bin/python' as its first line). But we are already running the
configure script within the shell and don't pass any other options with
the `#! /bin/sh' shebang.
So just out of curiosity, what is the necessity of `#! /bin/sh' in a
configure script? I am sure there must be things I am not aware of, but
I am curious to know.
Maybe I can use a simple script to remove such shebangs from all the
files in the tar-ball of a program before configuring and building it on