Skip to contentSkip to conversation

do not expect executable permissions for in-tree shell scripts

PATCH In review Olaf Hering 3 participants 6 messages Jun 5, 2010 – Jun 10, 2010 PowerPC

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 do not expect executable permissions for in-tree shell scripts

scripts in the kernel source do not have executable permissions if they were created with patch(1) run mkuboot.sh with bash, its tagged as bash script.

/opt/cross/kernel/linux-2.6.33-cross-host-kernel-source/arch/powerpc/boot/wrapper: line 273: /opt/cross/kernel/linux-2.6.33-cross-host-kernel-source/scripts/mkuboot.sh: Permission denied

---

This happens with 2.6.33, other versions have this bug as well.

 arch/powerpc/boot/wrapper |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/powerpc/boot/wrapper +2 -2
@@ -270,7 +270,7 @@ membase=`${CROSS}objdump -p "$kernel" |
 case "$platform" in
 uboot)
     rm -f "$ofile"
-    ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
+    bash ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
 	$uboot_version -d "$vmz" "$ofile"
     if [ -z "$cacheit" ]; then
 	rm -f "$vmz"
@@ -330,7 +330,7 @@ coff)
     ;;
 cuboot*)
     gzip -f -9 "$ofile"
-    ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
+    bash ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
             $uboot_version -d "$ofile".gz "$ofile"
     ;;
 treeboot*)
#1 lore raw
Quoted 3 lines · On Sat, 5 Jun 2010 10:10:39 +0200 Olaf Hering <[email protected]> wrote:

scripts in the kernel source do not have executable permissions if they were created with patch(1) run mkuboot.sh with bash, its tagged as bash script.

Wouldn't it be better to use ${SHELL}? Not every system has bash.

Cheers,
Sean

#2 lore raw
Quoted 8 lines · Sean MacLennan
Quoted 3 lines · On Sat, 5 Jun 2010 10:10:39 +0200 Olaf Hering <[email protected]> wrote:

scripts in the kernel source do not have executable permissions if they were created with patch(1) run mkuboot.sh with bash, its tagged as bash script.

Wouldn't it be better to use ${SHELL}? Not every system has bash.

Maybe.
As it stands right now, mkuboot.sh does not run without bash.

And:
Reality check please.
A _development system_ without bash, installed per default on every sane Linux distro, does most likely not exist.

Olaf

#3 lore raw
Quoted 8 lines · On Sat, 5 Jun 2010 19:44:37 +0200 Olaf Hering <[email protected]> wrote:

Maybe.
As it stands right now, mkuboot.sh does not run without bash.

And:
Reality check please.
A _development system_ without bash, installed per default on every sane Linux distro, does most likely not exist.

Hmmm, can't argue with that. I wouldn't consider building a kernel on the warp sane ;) And to be honest, I am not sure anyone has tried. We officially support it, but I have never done it and don't plan to try.

Cheers,
Sean

#4 lore raw
Quoted 7 lines · Sean MacLennan
Quoted 4 lines · On Sat, 5 Jun 2010 19:44:37 +0200 Olaf Hering <[email protected]> wrote:

Maybe.
As it stands right now, mkuboot.sh does not run without bash.

Quoted 8 lines
Quoted 4 lines

And:
Reality check please.
A _development system_ without bash, installed per default on every sane Linux distro, does most likely not exist.

Hmmm, can't argue with that. I wouldn't consider building a kernel on the warp sane ;) And to be honest, I am not sure anyone has tried. We officially support it, but I have never done it and don't plan to try.

I still don't like it very much.. why not chmod'ing it +x instead ? :-)

Cheers,
Ben.

#5 lore raw
Quoted 1 line · Benjamin Herrenschmidt

I still don't like it very much.. why not chmod'ing it +x instead ? :-)

I looked at a few other scripts in the source tree, they are called with $(CONFIG_SHELL) <name>, or perl <name>, or awk <name> or even sh <name>.

So my change adds some sort of consistency and makes packaging more robust.

Olaf