[FeatureRequest] Busybox support for SpaceFM tools

[slo-sleuth]

I'm working with SpaceFM in Slitaz Linux, which uses busybox by default, not BASH. Is there an easy was to alter the SpaceFM tools feature to support the ASH shell? The Slitaz devs say that installing BASH and linking to sh breaks critical slitaz scripts.

Thank you.

[slo-sleuth]

What might work is having the ability to specify the path to /bin/bash as the shell in the Global SpaceFM settings, since Slitaz allows for bash installation without it becoming the default shell.

[IgnorantGuru]

SpaceFM does not run sh, so I don't understand your motivation in wanting to link to that. It runs /bin/bash expressly. SpaceFM has a hard dependency on the genuine /bin/bash, and uses bash4 commands that are not handled by other shells. Genuine bash was selected to give consistency to SpaceFM custom commands and plugins, and SpaceFM uses some /bin/bash calls for internal functions as well. (You can run other kinds of scripts in SpaceFM - it executes any scripts within a bash shell - but bash v4 is required.)

So you should be able to just install bash - it doesn't need to be the default shell afaik. Slitaz has been using SpaceFM for awhile and no other reports about this, so again I'm not sure what you're trying to accomplish or what problem you're encountering.

If you haven't done so, you might run spacefm in a terminal so you can see debugging output - this will show you exactly how its running scripts.

[slo-sleuth]

Thanks for the reply. The fact that SpaceFM expressly calls /bin/bash is good to hear, and I would expect then that installing bash4 would solve the problem. However, I have installed bash4 in slitaz and user-created tools do not work as the ash shell is getting called. You can see sample output here: http://goo.gl/DSOTiG where I posted the issue as a bug in slitaz (since the operation works as expected in Ubuntu).

I can correct the SpaceFM behavior by symbolically linking /bin/sh to /bin/bash. By default, slitaz symbolically links /bin/sh to /bin/busybox. I find that user created tools fail to work in slitaz in both the stable and rolling versions. Slitaz-rolling packages the latests SpaceFM and is my choice of the two operating systems.

So, in summary, the reason I was wanting to be able to set the path for bash was because I did not know it was hard coded to /bin/bash. But my findings are that bash is not getting called and instead /bin/sh, which I supposed was due to SpaceFM using an environmental variable to find /bin/bash.

I hope I have been clear enough. Please let me know if I can provide more information.

On Wed, Jan 8, 2014 at 10:15 AM, IgnorantGuru notifications@github.comwrote:

SpaceFM does not run sh, so I don't understand your motivation in wanting to link to that. It runs /bin/bash expressly. SpaceFM has a hard dependency on the genuine /bin/bash, and uses bash4 commands that are not handled by other shells. Genuine bash was selected to give consistency to SpaceFM custom commands and plugins, and SpaceFM uses some /bin/bash calls for internal functions as well. (You can run other kinds of scripts in SpaceFM

• it executes any scripts within a bash shell - but bash v4 is required.)

So you should be able to just install bash - it doesn't need to be the default shell afaik. Slitaz has been using SpaceFM for awhile and no other reports about this, so again I'm not sure what you're trying to accomplish or what problem you're encountering.

— Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/413#issuecomment-31861742 .

[IgnorantGuru]

SpaceFM custom command lines are inserted into a script which begins with "#!/bin/bash" (which when executed causes it to be interpreted with /bin/bash). You are putting non-bash command lines into that script, so when executed it's being run with bash when it should be run with ash.

Likewise, custom scripts generated by SpaceFM also begin with "#!/bin/bash" indicating that bash should be used to run the script.

Custom command lines will always be inserted into a bash script, so they must be bash compatible to work correctly. Custom scripts can be changed to any kind of executable script. eg you can change "#!/bin/bash" at the top of the script to "#!/bin/sh". You can also change the default script that SpaceFM uses when new commands are created. However, by changing the script, if you distribute your command to other users, you must note the shell dependency.

Shells are not fully compatible, so for custom command lines SpaceFM must use something consistent. It uses bash. So you'll need to select Script instead of Command Line on the Command tab of the Menu Item Properties dialog, and change the script as you like. The "$fm_import" functionality should work with most shells. [Actually it does NOT work with ash, which means ash scripts cannot import SpaceFM file manager variables, making them very limited.]

I think that's what you're encountering. Let me know if that's not clear or you're getting different results.

[IgnorantGuru]

Also, from your output it looks like when executing a script headed with "#!/bin/bash", slitaz is actually executing it with ash. This sounds like a bad setup in Slitaz. Maybe they have linked /bin/bash to /bin/ash?

If you create this script:

#!/bin/bash
x[1]=2

And save it as script.sh. Then run:

chmod +x script.sh

Then run:

./script.sh

You should receive no error. If you get an error from ash, then it sounds like Slitaz isn't setup right - it's running bash scripts with ash for some reason?

[slo-sleuth]

I'm not certain I understand all that you have stated, but I will study it. In response to your last message, I'll provide the following:

In the default Slitaz install, there is no bash binary or symlink:

find / -name bash

#

ash and sh are linked to busybox:

ls -l /bin/ash /bin/sh

lrwxrwxrwx 1 root root 7 Jan 8 20:35 /bin/ash -> busybox lrwxrwxrwx 1 root root 7 Jan 8 20:35 /bin/sh -> busybox

It I create a new 'Time' tool using the command 'date' in default Slitaz, I get the error:

/tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 45: fm_pwd_panel[1]=/: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 47: fm_tab_panel[1]=1: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 48: fm_pwd_panel1_tab[1]=/: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 49: fm_pwd_tab[1]=/: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 54: syntax error: unexpected "("

Because I started spacefm from the command line, I receive the following debug output:

spacefm

TASK_COMMAND(0x81d0ca0)=date SPAWN=/bin/sh /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh run pid = 7502 child finished pid=7502 exit_status=2

That output seems to show that /bin/sh is being called, not bash, and that is symlinked to busybox. Installing bash does not solve the problem:

tazpkg get-install bash

Connecting to mirror.slitaz.org (46.105.127.17:80) bash-4.2.tazpkg 100% |***| 267k 0:00:00 ETA

Tracking dependencies for: bash

Missing: readline

1 missing package to install.

Connecting to mirror.slitaz.org (46.105.127.17:80) readline-6.2.tazpkg 100% |***| 78952 0:00:00 ETA

Installation of: readline

Copying readline... [ Done ] Extracting readline... [ Done ] Extracting the pseudo fs... [ Done ] Installing readline... [ Done ] Removing all tmp files... [ Done

]

readline (6.2) is installed.

Installation of: bash

Copying bash... [ Done ] Extracting bash... [ Done ] Extracting the pseudo fs... [ Done ] Installing bash... [ Done ] Removing all tmp files... [ Done ] Processing post-install commands...

Do you want to set Bash to default (y/N) ? :

bash (4.2) is installed.

spacefm

TASK_COMMAND(0x81d1348)=date SPAWN=/bin/sh /tmp/spacefm-root-7be5ec7f.tmp/5f475816-tmp.sh run pid = 8189 child finished pid=8189 exit_status=2

I believe this is because /bin/sh is still called to execute the script in the temp file, or am I missing something. This would explain while a symlink from /bin/sh to the newly installed /bin/bash fixes the SpaceFM tool execution.

Does this add any clarity?

On Wed, Jan 8, 2014 at 7:53 PM, IgnorantGuru notifications@github.comwrote:

Also, from your output it looks like when executing a script headed with "#!/bin/bash", slitaz is actually executing it with ash. This sounds like a bad setup in Slitaz. Maybe they have linked /bin/bash to /bin/ash?

If you create this script:

!/bin/bash

x[1]=2

And save it as script.sh. Then run:

chmod +x script.sh

Then run:

./script.sh

You should receive no error. If you get an error from ash, then it sounds like Slitaz isn't setup right - it's running bash scripts with ash for some reason?

— Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/413#issuecomment-31871362 .

[slo-sleuth]

I forgot to add that for this reason--the /bin/sh call by SpaceFM--the script.sh you suggested does not fix the issue. Only a symlink from /bin/sh to /bin/bash seems to correct.

On Wed, Jan 8, 2014 at 9:07 PM, slo.sleuth@gmail.com slo.sleuth@gmail.comwrote:

I'm not certain I understand all that you have stated, but I will study it. In response to your last message, I'll provide the following:

In the default Slitaz install, there is no bash binary or symlink:

find / -name bash

#

ash and sh are linked to busybox:

ls -l /bin/ash /bin/sh

lrwxrwxrwx 1 root root 7 Jan 8 20:35 /bin/ash -> busybox lrwxrwxrwx 1 root root 7 Jan 8 20:35 /bin/sh -> busybox

It I create a new 'Time' tool using the command 'date' in default Slitaz, I get the error:

/tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 45: fm_pwd_panel[1]=/: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 47: fm_tab_panel[1]=1: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 48: fm_pwd_panel1_tab[1]=/: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 49: fm_pwd_tab[1]=/: not found /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh: line 54: syntax error: unexpected "("

Because I started spacefm from the command line, I receive the following debug output:

spacefm

TASK_COMMAND(0x81d0ca0)=date SPAWN=/bin/sh /tmp/spacefm-root-42c5dc51.tmp/38b8f628-tmp.sh run pid = 7502 child finished pid=7502 exit_status=2

That output seems to show that /bin/sh is being called, not bash, and that is symlinked to busybox. Installing bash does not solve the problem:

tazpkg get-install bash

Connecting to mirror.slitaz.org (46.105.127.17:80) bash-4.2.tazpkg 100% |***| 267k 0:00:00 ETA

Tracking dependencies for: bash

Missing: readline

1 missing package to install.

Connecting to mirror.slitaz.org (46.105.127.17:80) readline-6.2.tazpkg 100% |***| 78952 0:00:00 ETA

Installation of: readline

Copying readline... [ Done ] Extracting readline... [ Done ] Extracting the pseudo fs... [ Done ] Installing readline... [ Done ] Removing all tmp files... [ Done ]

readline (6.2) is installed.

Installation of: bash

Copying bash... [ Done ] Extracting bash... [ Done ] Extracting the pseudo fs... [ Done ] Installing bash... [ Done ] Removing all tmp files... [ Done ] Processing post-install commands... Do you want to set Bash to default (y/N) ? :

bash (4.2) is installed.

spacefm

TASK_COMMAND(0x81d1348)=date SPAWN=/bin/sh /tmp/spacefm-root-7be5ec7f.tmp/5f475816-tmp.sh run pid = 8189 child finished pid=8189 exit_status=2

I believe this is because /bin/sh is still called to execute the script in the temp file, or am I missing something. This would explain while a symlink from /bin/sh to the newly installed /bin/bash fixes the SpaceFM tool execution.

Does this add any clarity?

On Wed, Jan 8, 2014 at 7:53 PM, IgnorantGuru notifications@github.comwrote:

Also, from your output it looks like when executing a script headed with "#!/bin/bash", slitaz is actually executing it with ash. This sounds like a bad setup in Slitaz. Maybe they have linked /bin/bash to /bin/ash?

If you create this script:

!/bin/bash

x[1]=2

And save it as script.sh. Then run:

chmod +x script.sh

Then run:

./script.sh

You should receive no error. If you get an error from ash, then it sounds like Slitaz isn't setup right - it's running bash scripts with ash for some reason?

— Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/413#issuecomment-31871362 .

[IgnorantGuru]

SPAWN=/bin/sh

An unhacked copy of SpaceFM would never produce that output. This indicates that whoever packaged SpaceFM did deep source hacking to use /bin/sh instead of /bin/bash. As a result they broke core functionality program-wide. SpaceFM has a hard dependency on bash v4 for a reason (but does not require bash as your default shell). SpaceFM should not even be able to be installed without bash v4 installed.

You'll need to file a bug report on this with your packager. sh != bash

Thanks for the report anyway but I will offer no support on this - warranty void.

[slo-sleuth]

Thanks IgnorantGuru. I completely understand: not your issue. I will recompile the package and not hack it. It should would fine with the hard path calls to /bin/bash in the Slitaz environment, anyway. I suspect this was done in a misplaced attempt to remove the Bash dependency and keep the distro smaller.

Excellent piece of software, by the way. I'm involved in data recovery and the configurability of SpaceFM is ideal for this work. Thank you for all your efforts and helping me to identify the issue.

On Wed, Jan 8, 2014 at 1:21 PM, IgnorantGuru notifications@github.comwrote:

Closed #413 https://github.com/IgnorantGuru/spacefm/issues/413.

— Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/413 .

[IgnorantGuru]

I suspect this was done in a misplaced attempt to remove the Bash dependency and keep the distro smaller.

Agreed. I would strongly suggest filing a bug report, because they're causing serious breakage to all users of SpaceFM in Slitaz (if that's who distributed that package).

[slo-sleuth]

I am doing so. I already started the forum discussion, where it was suggested the problem was SpaceFM. Of course, we see otherwise.

On Wed, Jan 8, 2014 at 1:45 PM, IgnorantGuru notifications@github.comwrote:

I suspect this was done in a misplaced attempt to remove the Bash dependency and keep the distro smaller.

Agreed. I would strongly suggest filing a bug report, because they're causing serious breakage to all users of SpaceFM in Slitaz (if that's who distributed that package).

— Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/413#issuecomment-31881122 .

[IgnorantGuru]

On your comment here:

My suggestion, to achieve both goals of a light distribution and a fully functional SpaceFM (for those who desire it) would be to recompile SpaceFM without the /bin/sh modification, but leave bash out of the dependencies in the recipe. Users wishing the fully SpaceFM experience will need to install bash (this can be mentioned in the SpaceFM description), but shouldn't need to symlink /bin/sh to /bin/bash because SpaceFM makes express calls to /bin/bash.

Unfortunately that is incorrect. Even core functions in SpaceFM require bash v4. It is a hard dependency of the app. Not including it may cause mysterious breakages which most users will not understand. This gives the app a very poor introduction so please don't recommend ignoring hard dependencies. What you're suggesting is that it's an optional dependency, which is not the case. ntl thanks for informing them of the breakage.

[IgnorantGuru]

Note to self: Add comment in file-task.c warning not to use sh; a test to ensure /bin/bash installed?

[slo-sleuth]

I'll modify my comment and thought better of including that in the bug report.

On Wed, Jan 8, 2014 at 2:18 PM, IgnorantGuru notifications@github.comwrote:

Reopened #413 https://github.com/IgnorantGuru/spacefm/issues/413.

— Reply to this email directly or view it on GitHubhttps://github.com/IgnorantGuru/spacefm/issues/413 .

[slo-sleuth]

Slitaz has updated to SpaceFM 0.9.4 and made bash as dependency, but custom commands (and f4 terminal launch) are broken still.

I located the changes being applied to SpaceFM through the Slitaz spacefm package receipt:

<Package description>
...

DEPENDS="glibc-base glib libgio util-linux-uuid libxcb xcb-util expat \
gtk+ startup-notification dbus dbus-glib gdk-pixbuf udev bash udevil"

BUILD_DEPENDS="gtk+-dev dbus-glib-dev dbus-dev startup-notification-dev \
libxcb-dev xcb-util-dev expat-dev gdk-pixbuf-dev intltool udev-dev \
coreutils-file-special"

# Rules to configure and make the package.
compile_rules()
{
    cd $src
    patch -Np1 -i $stuff/prefdlg.ui.diff 
    patch -Np1 -i $stuff/settings.h.diff 
    patch -Np1 -i $stuff/vfs-file-task.c.diff

    # We dont want bash hardcoded
    sed -i s'|/bin/bash|/bin/sh|'g src/*.c src/*.h src/*/*.c src/*/*.h

    ./configure \
        --with-preferable-sudo="/usr/bin/subox" \
        --disable-pixmaps \
        $CONFIGURE_ARGS &&
    make && make install
}

# Rules to gen a SliTaz package suitable for Tazpkg.
genpkg_rules()
{
    mkdir -p $fs/usr/share $fs/etc/spacefm
    cp -a $install/usr/bin $fs/usr
    for d in applications mime icons spacefm
    do
        cp -a $install/usr/share/$d $fs/usr/share
    done
    cp $stuff/spacefm.conf $fs/etc/spacefm
    cp -a $stuff/xdg $fs/etc
    # Faenza --> SliTaz
    mv $fs/usr/share/icons/Faenza $fs/usr/share/icons/SliTaz
    rm -rf $fs/usr/share/icons/hicolor/128x128
    # /bin/bash --> /bin/sh
    sed -i s'|/bin/bash|/bin/sh|'g $fs/usr/bin/spacefm-auth
}

I'll try to get the package maintainer to drop the practice of replacing /bin/bash with /bin/sh to restore full functionality of SpaceFM in Slitaz. At this point, with the inclusion of bash as a dependency, the sed lines in the package receipt may be carry over from previous builds. I'm also trying to hunt down the patches to determine what changes are being made there.