cross-compiling on OS X, make menuconfig fails

[t***@freescale.com]

I'm trying to cross-compile a PowerPC kernel from an Intel OS X system.
I've almost got it working, except "make menuconfig" dies. It says
I'm missing ncurses:

*** Unable to find the ncurses libraries or the
*** required header files.
*** 'make menuconfig' requires the ncurses libraries.

However, I do not think that ncurses is the real problem, since I do
have ncurses installed. I think the real problem is that the
check-lxdialog.sh is trying to execute this code:

echo -e ' #include CURSES_LOC \n main() {}' | gcc
'-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o
.lxdialog.tmp

And the compiler is failing with this output:

<stdin>:1: error: syntax error before ‘-’ token
<stdin>:1: error: stray ‘#’ in program

So something strange is going on. Has anyone been able to cross-compile
from an Intel Mac running OS X?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Tony Breeds]

Post by t***@freescale.com
I'm trying to cross-compile a PowerPC kernel from an Intel OS X system.

<snip>

Post by t***@freescale.com
However, I do not think that ncurses is the real problem, since I do
have ncurses installed. I think the real problem is that the
echo -e ' #include CURSES_LOC \n main() {}' | gcc
'-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o
.lxdialog.tmp
<stdin>:1: error: syntax error before ‘-’ token
<stdin>:1: error: stray ‘#’ in program

On most linux systems echo supports c-syle escapes with "-e". I'm
guessing which ever echo you're getting dosesn't do that.

I think the best fix is to ensure you're getting bash as your shell.

A nasty hack would be to make check-lxdialog.sh do something like:
(echo ' #include CURSES_LOC';echo 'main() {}') | gcc '-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o .lxdialog.tmp

But you'll likley find other palces it breaks.

Yours Tony

linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Timur Tabi]

Post by Tony Breeds
On most linux systems echo supports c-syle escapes with "-e". I'm
guessing which ever echo you're getting dosesn't do that.

Yes, that is my problem.

Post by Tony Breeds
I think the best fix is to ensure you're getting bash as your shell.

The script starts off with this line:

#!/bin/sh

Doesn't that mean that it should be interpreted by sh and not bash?

Post by Tony Breeds
(echo ' #include CURSES_LOC';echo 'main() {}') | gcc '-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o .lxdialog.tmp

This works. Do you think if I posted a patch that makes this change, it will be
accepted?

[Sam Ravnborg]

Post by Timur Tabi

Post by Tony Breeds
On most linux systems echo supports c-syle escapes with "-e". I'm
guessing which ever echo you're getting dosesn't do that.

Yes, that is my problem.

Post by Tony Breeds
I think the best fix is to ensure you're getting bash as your shell.

#!/bin/sh
Doesn't that mean that it should be interpreted by sh and not bash?

Post by Tony Breeds
(echo ' #include CURSES_LOC';echo 'main() {}') | gcc '-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o .lxdialog.tmp

This works. Do you think if I posted a patch that makes this change, it will be
accepted?

Yes.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Al Viro]

Post by Timur Tabi

Post by Tony Breeds
On most linux systems echo supports c-syle escapes with "-e". I'm
guessing which ever echo you're getting dosesn't do that.

Yes, that is my problem.

Post by Tony Breeds
I think the best fix is to ensure you're getting bash as your shell.

#!/bin/sh
Doesn't that mean that it should be interpreted by sh and not bash?

Post by Tony Breeds
(echo ' #include CURSES_LOC';echo 'main() {}') | gcc '-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o .lxdialog.tmp

This works. Do you think if I posted a patch that makes this change, it will be
accepted?

Yes.

Good grief, folks...

check() {
$cc -xc - -o $tmp 2>/dev/null <<'EOF'
#include CURSES_LOC
main() {}
EOF
...
if you insist on feeding these two lines to gcc stdin. Nasty hack, indeed...

<<'word'
[lines]
word

redirects stdin and feeds lines to it verbatim. Same without quotes will
do the same, but do expansion in the text first.

It's been there since the original Bourne's shell in v7 and it's a bloody
standard way to redirect from text...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sam Ravnborg]

Post by Al Viro
Good grief, folks...

Thanks Al.
I've queued up the following patch.

Sam

commit c99cc32e0d92f5fdbdd39a7f42cfff869062fff5
Author: Sam Ravnborg <***@uranus.ravnborg.org>
Date: Tue Apr 29 20:02:44 2008 +0200

kconfig: made check-lxdialog more portable

OS-X shell did not like 'echo -e' so implement
suggestion from Al Viro to use a more portable construct.

Signed-off-by: Sam Ravnborg <***@ravnborg.org>
Cc: Al Viro <***@ZenIV.linux.org.uk>

diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 62e1e02..5552154 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -36,8 +36,10 @@ trap "rm -f $tmp" 0 1 2 3 15

# Check if we can link to ncurses
check() {
- echo -e " #include CURSES_LOC \n main() {}" |
- $cc -xc - -o $tmp 2> /dev/null
+ $cc -xc - -o $tmp 2>/dev/null <<'EOF'
+#include CURSES_LOC
+main() {}
+EOF
if [ $? != 0 ]; then
echo " *** Unable to find the ncurses libraries or the" 1>&2
echo " *** required header files." 1>&2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Timur Tabi]

Post by Sam Ravnborg

Post by Al Viro
Good grief, folks...

Thanks Al.
I've queued up the following patch.
Sam
commit c99cc32e0d92f5fdbdd39a7f42cfff869062fff5
Date: Tue Apr 29 20:02:44 2008 +0200
kconfig: made check-lxdialog more portable
OS-X shell did not like 'echo -e' so implement
suggestion from Al Viro to use a more portable construct.

Just for the record:

Acked-By: Timur Tabi <***@freescale.com>

This works on OS X. I haven't tested it on Linux, though.

FYI, there are other issues that break cross-compiling from OS X, but none of
them are related to /bin/sh. I'll post patches for those later this week.

[Sam Ravnborg]

Post by Timur Tabi

Post by Sam Ravnborg

Post by Al Viro
Good grief, folks...

Thanks Al.
I've queued up the following patch.
Sam
commit c99cc32e0d92f5fdbdd39a7f42cfff869062fff5
Date: Tue Apr 29 20:02:44 2008 +0200
kconfig: made check-lxdialog more portable
OS-X shell did not like 'echo -e' so implement
suggestion from Al Viro to use a more portable construct.

This works on OS X. I haven't tested it on Linux, though.
FYI, there are other issues that break cross-compiling from OS X, but none of
them are related to /bin/sh. I'll post patches for those later this week.

Thanks.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[SL Baur]

Post by Sam Ravnborg

Post by Al Viro
Good grief, folks...

Thanks Al.
I've queued up the following patch.
Sam
commit c99cc32e0d92f5fdbdd39a7f42cfff869062fff5
Date: Tue Apr 29 20:02:44 2008 +0200
kconfig: made check-lxdialog more portable
OS-X shell did not like 'echo -e' so implement
suggestion from Al Viro to use a more portable construct.
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 62e1e02..5552154 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -36,8 +36,10 @@ trap "rm -f $tmp" 0 1 2 3 15
# Check if we can link to ncurses
check() {
- echo -e " #include CURSES_LOC \n main() {}" |
- $cc -xc - -o $tmp 2> /dev/null
+ $cc -xc - -o $tmp 2>/dev/null <<'EOF'
+#include CURSES_LOC
+main() {}
+EOF
if [ $? != 0 ]; then
echo " *** Unable to find the ncurses libraries or the" 1>&2
echo " *** required header files." 1>&2

This looks O.K. As a note, whatever behavior is being described here
is system dependent, because on my installation of that other OS, `echo -e'
works fine whether it is invoked as /bin/bash or /bin/sh which appears to be
a strict copy of /bin/bash.

$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
root:xnu792.25.20~1/RELEASE_I386

Reviewed-by: SL Baur <***@xemacs.org>

-sb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sam Ravnborg]

Post by SL Baur
This looks O.K. As a note, whatever behavior is being described here
is system dependent, because on my installation of that other OS, `echo -e'
works fine whether it is invoked as /bin/bash or /bin/sh which appears to be
a strict copy of /bin/bash.
$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
root:xnu792.25.20~1/RELEASE_I386

Thanks for your feedback.
The patch is already upstream so I unfortunately
cannot add your Reviewed-by: tag.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Roland Kuhn]

Hi Steve!

Post by SL Baur

Post by Sam Ravnborg

Post by Al Viro
Good grief, folks...

Thanks Al.
I've queued up the following patch.
Sam
commit c99cc32e0d92f5fdbdd39a7f42cfff869062fff5
Date: Tue Apr 29 20:02:44 2008 +0200
kconfig: made check-lxdialog more portable
OS-X shell did not like 'echo -e' so implement
suggestion from Al Viro to use a more portable construct.
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/
kconfig/lxdialog/check-lxdialog.sh
index 62e1e02..5552154 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -36,8 +36,10 @@ trap "rm -f $tmp" 0 1 2 3 15
# Check if we can link to ncurses
check() {
- echo -e " #include CURSES_LOC \n main() {}" |
- $cc -xc - -o $tmp 2> /dev/null
+ $cc -xc - -o $tmp 2>/dev/null <<'EOF'
+#include CURSES_LOC
+main() {}
+EOF
if [ $? != 0 ]; then
echo " *** Unable to find the ncurses libraries or
the" 1>&2
echo " *** required header
files." 1>&2

This looks O.K. As a note, whatever behavior is being described here
is system dependent, because on my installation of that other OS, `echo -e'
works fine whether it is invoked as /bin/bash or /bin/sh which
appears to be
a strict copy of /bin/bash.
$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
root:xnu792.25.20~1/RELEASE_I386

Yes, they changed that between Tiger and Leopard, where I have

---
$ uname -v
Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008;
root:xnu-1228.4.31~1/RELEASE_I386
$ /bin/bash -c 'echo -e "buh\n"'
buh

$ /bin/sh -c 'echo -e "buh\n"'
-e buh

$ /bin/echo -e "buh\n"
-e buh\n
---

The second one is POSIX+XSI, the third one plain POSIX. The first one
is what people are used to ;-)

Ciao,
Roland

--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both. - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M+ !
V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e++++ h---- y+++
------END GEEK CODE BLOCK------

[SL Baur]

Post by Roland Kuhn
Hi Steve!

Post by SL Baur
$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
root:xnu792.25.20~1/RELEASE_I386

Yes, they changed that between Tiger and Leopard, where I have
---
$ uname -v
Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008;
root:xnu-1228.4.31~1/RELEASE_I386
$ /bin/bash -c 'echo -e "buh\n"'
buh
$ /bin/sh -c 'echo -e "buh\n"'
-e buh
$ /bin/echo -e "buh\n"
-e buh\n
---
The second one is POSIX+XSI, the third one plain POSIX. The first one is
what people are used to ;-)

Check.

$ /bin/bash -c 'echo -e "buh\n"'
buh

$ /bin/sh -c 'echo -e "buh\n"'
buh

$ /bin/echo -e "buh\n"
-e buh\n

Of all the things to "standardize" on, why something like bash
which has no standards? pdksh, ash, dash or POSIX mode zsh,
would have been better...

-sb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Arnd Hannemann]

Post by SL Baur

Post by Roland Kuhn
Hi Steve!

Post by SL Baur
$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
root:xnu792.25.20~1/RELEASE_I386

Yes, they changed that between Tiger and Leopard, where I have
---
$ uname -v
Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008;
root:xnu-1228.4.31~1/RELEASE_I386
$ /bin/bash -c 'echo -e "buh\n"'
buh
$ /bin/sh -c 'echo -e "buh\n"'
-e buh
$ /bin/echo -e "buh\n"
-e buh\n
---
The second one is POSIX+XSI, the third one plain POSIX. The first one is
what people are used to ;-)

Check.
$ /bin/bash -c 'echo -e "buh\n"'
buh
$ /bin/sh -c 'echo -e "buh\n"'
buh
$ /bin/echo -e "buh\n"
-e buh\n
Of all the things to "standardize" on, why something like bash
which has no standards? pdksh, ash, dash or POSIX mode zsh,
would have been better...

It also depends on the shell option xpg_echo IIRC.
If xpg_echo is off echo -e should work in /bin/sh, too.

Regards,
Arnd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Roland Kuhn]

Hi Timur!

Post by t***@freescale.com
I'm trying to cross-compile a PowerPC kernel from an Intel OS X
system. I've almost got it working, except "make menuconfig" dies.
*** Unable to find the ncurses libraries or the
*** required header files.
*** 'make menuconfig' requires the ncurses libraries.
However, I do not think that ncurses is the real problem, since I do
have ncurses installed. I think the real problem is that the check-
echo -e ' #include CURSES_LOC \n main() {}' | gcc '-
DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -
o .lxdialog.tmp
<stdin>:1: error: syntax error before ‘-’ token
<stdin>:1: error: stray ‘#’ in program
So something strange is going on. Has anyone been able to cross-
compile from an Intel Mac running OS X?

For some strange reason Apple decided to change 'echo':

/bin/bash -c 'echo -e ...' does the right thing
/bin/sh -c 'echo -e ...' keeps the "-e" in the output but interprets
the \n
/bin/echo -e ... does no interpretation and even keeps the \n

I'd recommend installing the coreutils-default package from fink, then
you get a sane /sw/bin/echo.

Side-note on sanity: ISTR that POSIX defines echo in this (/bin/echo)
strange way, urging people to use printf instead.

Ciao,
Roland

--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both. - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M+ !
V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e++++ h---- y+++
------END GEEK CODE BLOCK------

[Timur Tabi]

Post by Roland Kuhn
/bin/bash -c 'echo -e ...' does the right thing
/bin/sh -c 'echo -e ...' keeps the "-e" in the output but interprets
the \n
/bin/echo -e ... does no interpretation and even keeps the \n

Wow, that is messed up. Especially since "/bin/sh --version" and "/bin/bash
--version" give me the same output.

Would you say that OS X is broken? I'm having a hard time finding documentation
for 'sh', so I can't find out what echo -e is supposed to do in 'sh'.

I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'
scripts. Has that code been merged in?

Post by Roland Kuhn
I'd recommend installing the coreutils-default package from fink, then
you get a sane /sw/bin/echo.

But the scripts still reference /bin/sh, so I would need to change the scripts
or symlink /bin/sh. If I'm going to symlink /bin/sh, I'd rather just symlink it
to /bin/bash.

Post by Roland Kuhn
Side-note on sanity: ISTR that POSIX defines echo in this (/bin/echo)
strange way, urging people to use printf instead.

But printf is bash, not sh. I would need to change #!/bin/sh to #!/bin/bash.

[Al Viro]

Post by Timur Tabi
I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'
scripts. Has that code been merged in?

I have no patches pending but I may have lost them.
As I am 100% ignorant about what is bash and what is not bash specialities
I will more or less be blind when I apply them so I hope they are well
tested.

*shrug*

As a sanity check, try to run them with ash(1). Before going into review
of portability.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sam Ravnborg]

Post by Timur Tabi
I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'
scripts. Has that code been merged in?

I have no patches pending but I may have lost them.
As I am 100% ignorant about what is bash and what is not bash specialities
I will more or less be blind when I apply them so I hope they are well
tested.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Mark Rustad]

Post by Timur Tabi
I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'
scripts. Has that code been merged in?

I have no patches pending but I may have lost them.
As I am 100% ignorant about what is bash and what is not bash
specialities
I will more or less be blind when I apply them so I hope they are well
tested.

So why use /bin/sh ever in the kernel build system? I consciously
began using /bin/bash consistently in scripts years ago because you
just never know what you get when you use /bin/sh. I remember
replacing /bin/sh with /bin/bash in gcc's build system to get it to
work on some system at some point. Life is too short to keep having to
fight silliness like this and I can't see a valid reason why a system
building a Linux kernel, or for that matter gcc, should not have the
bash shell installed on it.

And on some systems, changing /bin/sh to point to /bin/bash can result
in subtle problems with that system's environment, so that is not a
good option. At least by using /bin/bash you know what you get and the
dependency is then known to all.

[Alexey Dobriyan]

Post by Timur Tabi
I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'
scripts. Has that code been merged in?

I have no patches pending but I may have lost them.
As I am 100% ignorant about what is bash and what is not bash specialities
I will more or less be blind when I apply them so I hope they are well
tested.

So why use /bin/sh ever in the kernel build system? I consciously began
using /bin/bash consistently in scripts years ago because you just never
know what you get when you use /bin/sh. I remember replacing /bin/sh with
/bin/bash in gcc's build system to get it to work on some system at some
point. Life is too short to keep having to fight silliness like this and I
can't see a valid reason why a system building a Linux kernel, or for that
matter gcc, should not have the bash shell installed on it.

Think harder.

And on some systems, changing /bin/sh to point to /bin/bash can result in
subtle problems with that system's environment, so that is not a good
option. At least by using /bin/bash you know what you get and the
dependency is then known to all.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Willy Tarreau]

Post by Alexey Dobriyan

Post by Timur Tabi
I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'
scripts. Has that code been merged in?

I have no patches pending but I may have lost them.
As I am 100% ignorant about what is bash and what is not bash specialities
I will more or less be blind when I apply them so I hope they are well
tested.

So why use /bin/sh ever in the kernel build system? I consciously began
using /bin/bash consistently in scripts years ago because you just never
know what you get when you use /bin/sh. I remember replacing /bin/sh with
/bin/bash in gcc's build system to get it to work on some system at some
point. Life is too short to keep having to fight silliness like this and I
can't see a valid reason why a system building a Linux kernel, or for that
matter gcc, should not have the bash shell installed on it.

Think harder.

Hint: not every joe user may install bash into /bin... That's why we
see some scripts begin with "/usr/bin/env bash" as there are less
systems without env in /usr/bin than systems without bash in /bin (or
at all).

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Timur Tabi]

Post by Willy Tarreau
Hint: not every joe user may install bash into /bin... That's why we
see some scripts begin with "/usr/bin/env bash" as there are less
systems without env in /usr/bin than systems without bash in /bin (or
at all).

I agree that #!/bin/bash is a bad idea. I think the easiest, and maybe the
best, approach is to fix shell issue one-by-one. The one I found was easily
fixed by Al Viro's here-document change.

[SL Baur]

Post by Willy Tarreau

Life is too short to keep having to fight silliness like this and I
can't see a valid reason why a system building a Linux kernel, or for that
matter gcc, should not have the bash shell installed on it.

Hint: not every joe user may install bash into /bin... That's why we
see some scripts begin with "/usr/bin/env bash" as there are less
systems without env in /usr/bin than systems without bash in /bin (or
at all).

/bin/sh standard behaviour is defined. We follow standards not written or
dictated by us. I'm proud of that.

-sb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jan Engelhardt]

Post by Willy Tarreau
Hint: not every joe user may install bash into /bin... That's why we
see some scripts begin with "/usr/bin/env bash" as there are less
systems without env in /usr/bin than systems without bash in /bin (or
at all).

Too bad #!bash does not search $PATH.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Bernd Petrovitsch]

On Tue, 2008-04-29 at 09:51 -0500, Timur Tabi wrote:
[...]

Post by Timur Tabi
But printf is bash, not sh. I would need to change #!/bin/sh to #!/bin/bash.

Yes, also:
---- snip ----
{2}type -all printf
printf is a shell builtin
printf is /usr/bin/printf
---- snip ----
And the latter is part of coreutils.

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: [phone] fax: [phone]
Embedded Linux Development and Services

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/