Loading ...
Sorry, an error occurred while loading the content.
 

Re: Global profile for ash

Expand Messages
  • jl0242
    Okay, now I m really confused. Looking at this output: http://pastebin.com/f5c759f53 It looks like the path is set correctly. Ash seems to be using a version
    Message 1 of 9 , Apr 24, 2009
      Okay, now I'm really confused. Looking at this output:

      http://pastebin.com/f5c759f53

      It looks like the path is set correctly. Ash seems to be using a version of 'find' that's not from /urs/bin *or* /opt/bin. Line 10 shows output from the version of 'find' that ash is using, line 15 shows the output from the version in /usr/bin, and line 29 shows the output from the version in /opt/bin (the findutils version, the version that I actually want).

      Since the steps clearly show that /opt/bin is at the front of the path (don't know where this is being set from, but I suppose that doesn't matter) - where on earth is ash getting getting this 3rd copy of find??

      Sorry, I realise now this is far more linux/shell related than slug related :S


      --- In nslu2-general@yahoogroups.com, "jl0242" <japher@...> wrote:
      >
      > Hi,
      >
      > I'm having some path problems when running scripts on Unslung 6.10. I was running Unslung 6.8 until I recently rebuilt my slug, and I somehow had this set correctly before the rebuild!
      >
      > I want my scripts to use the bins in /opt/bin, rather than /usr/bin. /us/bin seems to contain the cutdown BusyBox v1.3.1 apps, and /opt/bin contains the full apps (e.g. installed via findutils, coreutils, etc). When I log in via ssh (into bash), my path seems to be set correctly (it's not set in my .bashrc, but I assume it's set in the global profile for bash). However, when I run a script that contains the header line #!/bin/sh, the context in which the script executes doesn't seem to have /opt/bin at the front of the path (it uses apps in /usr/bin). This is causing my scripts to fail.
      >
      > As a quick demonstration, the below shows what happens when I run the find command (using an option that only the findutils version supports) in both bash and ash:
      >
      > ~$ find -maxdepth 1
      > .
      > ./.ssh
      > ./.bash_history
      > ./.bash_profile
      > ./.bashrc
      > ./.inputrc
      > ~$ sh
      >
      >
      > BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) Built-in shell (ash)
      > Enter 'help' for a list of built-in commands.
      >
      > \w$ find -maxdepth 1
      > BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) multi-call binary
      >
      > No help available.
      >
      > \w$ exit
      >
      > Is there a global profile I can set for ash? I've looked in /etc/profile, but the path being set looks correct:
      >
      > PATH=/opt/sbin:/opt/bin:/sbin:/bin:/usr/sbin:/usr/bin
      >
      > (/opt/bin is before /usr/bin)
      >
      > So I can only assume that /etc/profile is not going to help me.
      >
      > Do I have to do this via a diversion script?
      >
      > Cheers,
      >
      > joe
      >
    • Carl Lowenstein
      ... As a general rule, you should specify the exact path for programs that you run in a script. So don t say find , say /opt/bin/find . If you have to put it
      Message 2 of 9 , Apr 24, 2009
        On Fri, Apr 24, 2009 at 10:16 AM, jl0242 <japher@...> wrote:
        >
        >
        > Okay, now I'm really confused. Looking at this output:
        >
        > http://pastebin.com/f5c759f53
        >
        > It looks like the path is set correctly. Ash seems to be using a version of
        > 'find' that's not from /urs/bin *or* /opt/bin. Line 10 shows output from the
        > version of 'find' that ash is using, line 15 shows the output from the
        > version in /usr/bin, and line 29 shows the output from the version in
        > /opt/bin (the findutils version, the version that I actually want).
        >
        > Since the steps clearly show that /opt/bin is at the front of the path
        > (don't know where this is being set from, but I suppose that doesn't matter)
        > - where on earth is ash getting getting this 3rd copy of find??

        As a general rule, you should specify the exact path for programs that
        you run in a script.
        So don't say "find", say "/opt/bin/find".
        If you have to put it in many places in the script, you can do something like
        FIND=/opt/bin/find
        and then refer to it as $FIND

        carl
        --
        carl lowenstein <clowenstein@...>
      • jl0242
        Sounds sensible! No idea how I had this working in the past, but I ll go with the full path in the script (and just do this in future scripts too). Cheers.
        Message 3 of 9 , Apr 25, 2009
          Sounds sensible!

          No idea how I had this working in the past, but I'll go with the full path in the script (and just do this in future scripts too).

          Cheers.

          --- In nslu2-general@yahoogroups.com, Carl Lowenstein <clowenstein@...> wrote:
          >
          > On Fri, Apr 24, 2009 at 10:16 AM, jl0242 <japher@...> wrote:
          > >
          > >
          > > Okay, now I'm really confused. Looking at this output:
          > >
          > > http://pastebin.com/f5c759f53
          > >
          > > It looks like the path is set correctly. Ash seems to be using a version of
          > > 'find' that's not from /urs/bin *or* /opt/bin. Line 10 shows output from the
          > > version of 'find' that ash is using, line 15 shows the output from the
          > > version in /usr/bin, and line 29 shows the output from the version in
          > > /opt/bin (the findutils version, the version that I actually want).
          > >
          > > Since the steps clearly show that /opt/bin is at the front of the path
          > > (don't know where this is being set from, but I suppose that doesn't matter)
          > > - where on earth is ash getting getting this 3rd copy of find??
          >
          > As a general rule, you should specify the exact path for programs that
          > you run in a script.
          > So don't say "find", say "/opt/bin/find".
          > If you have to put it in many places in the script, you can do something like
          > FIND=/opt/bin/find
          > and then refer to it as $FIND
          >
          > carl
          > --
          > carl lowenstein <clowenstein@...>
          >
        • John
          ... Actually, for some shells, it does matter when the path was set. For speed, some shells will cache the location of an executable and the cache is not
          Message 4 of 9 , Apr 25, 2009
            On Fri, Apr 24, 2009 at 05:16:46PM -0000, jl0242 wrote:
            > Okay, now I'm really confused. Looking at this output:
            >
            > http://pastebin.com/f5c759f53
            >
            > It looks like the path is set correctly. Ash seems to be using a
            > version of 'find' that's not from /urs/bin *or* /opt/bin. Line
            > 10 shows output from the version of 'find' that ash is using,
            > line 15 shows the output from the version in /usr/bin, and line
            > 29 shows the output from the version in /opt/bin (the findutils
            > version, the version that I actually want). (don't know where
            > this is being set from, but I suppose that doesn't matter)

            Actually, for some shells, it does matter when the path was
            set. For speed, some shells will cache the location of an
            executable and the cache is not necessarily flushed or updated when
            you change the path. Ash, however, is likely too lightweight to have
            this feature.

            > Since the steps clearly show that /opt/bin is at the front of the path

            According to the printout, /opt/bin is not at the front of the
            path: /opt/sbin is. It may seem unlikely but did you check to see
            if /opt/sbin has your third version of find?

            > - where on earth is ash getting getting this 3rd copy of find??

            Did you try "which find"? Most shells have a "which" command to
            tell you the shell's opinion of the location of an executable.

            John
          • jl0242
            Cheers John, I m starting to think there is a bigger problem here. I ve been doing some googling on this No help available error and it actually sounds like
            Message 5 of 9 , Apr 26, 2009
              Cheers John,

              I'm starting to think there is a bigger problem here. I've been doing some googling on this "No help available" error and it actually sounds like it's a bug:
              http://www.mail-archive.com/busybox@.../msg00793.html

              I installed 'which' via ipkg. Have a look at this output (something's not right here IMO):

              # which find
              /opt/bin/find
              # find -maxdepth 1
              BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) multi-call binary

              No help available.

              # /opt/bin/find -maxdepth 1
              .
              ./backup
              ./repair
              ./tmpmnt
              ./share
              ./share2
              #

              Not much more on the list about this problem, but I found a couple of examples:
              http://tech.groups.yahoo.com/group/nslu2-linux/message/20778
              http://tech.groups.yahoo.com/group/nslu2-linux/message/20842


              --- In nslu2-general@yahoogroups.com, John <jl.050877@...> wrote:
              >
              > On Fri, Apr 24, 2009 at 05:16:46PM -0000, jl0242 wrote:
              > > Okay, now I'm really confused. Looking at this output:
              > >
              > > http://pastebin.com/f5c759f53
              > >
              > > It looks like the path is set correctly. Ash seems to be using a
              > > version of 'find' that's not from /urs/bin *or* /opt/bin. Line
              > > 10 shows output from the version of 'find' that ash is using,
              > > line 15 shows the output from the version in /usr/bin, and line
              > > 29 shows the output from the version in /opt/bin (the findutils
              > > version, the version that I actually want). (don't know where
              > > this is being set from, but I suppose that doesn't matter)
              >
              > Actually, for some shells, it does matter when the path was
              > set. For speed, some shells will cache the location of an
              > executable and the cache is not necessarily flushed or updated when
              > you change the path. Ash, however, is likely too lightweight to have
              > this feature.
              >
              > > Since the steps clearly show that /opt/bin is at the front of the path
              >
              > According to the printout, /opt/bin is not at the front of the
              > path: /opt/sbin is. It may seem unlikely but did you check to see
              > if /opt/sbin has your third version of find?
              >
              > > - where on earth is ash getting getting this 3rd copy of find??
              >
              > Did you try "which find"? Most shells have a "which" command to
              > tell you the shell's opinion of the location of an executable.
              >
              > John
              >
            • Rod Whitby
              ... If your shell is actually a symlink to busybox, and busybox has find enabled as an applet, then I think it will find the applet first ahead of whatever
              Message 6 of 9 , Apr 26, 2009
                jl0242 wrote:
                > I'm starting to think there is a bigger problem here. I've been doing some googling on this "No help available" error and it actually sounds like it's a bug:
                > http://www.mail-archive.com/busybox@.../msg00793.html
                >
                > I installed 'which' via ipkg. Have a look at this output (something's not right here IMO):
                >
                > # which find
                > /opt/bin/find
                > # find -maxdepth 1
                > BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) multi-call binary
                >
                > No help available.
                >

                If your shell is actually a symlink to busybox, and busybox has 'find'
                enabled as an applet, then I think it will find the applet first ahead
                of whatever is in the path. Only if you give a full pathname
                (/opt/bin/find) will it ignore the in-built find applet.

                -- Rod
              • jl0242
                Thanks Rod, you ve hit the nail on the head there. I m pretty sure I m seeing the busybox find applet in action here. A few questions: 1. Is there any
                Message 7 of 9 , Apr 27, 2009
                  Thanks Rod, you've hit the nail on the head there. I'm pretty sure I'm seeing the busybox 'find' applet in action here. A few questions:

                  1. Is there any problem in me symlinking /bin/sh to /opt/bin/bash? (I have bash installed). Will this affect any core Unslung (6.10) functionality?

                  2. Has the 'find' applet always been included in the BusyBox config for Unslung? I'm not sure entirely certain why, but I never had these problems before I moved to Unslung 6.10 recently. The other examples I've found on the list all seem to have been posted since Unslung 6.10.

                  3. Is there a reason that Unslung is still using BusyBox 1.3.1? They look to have got to 1.14.x now.

                  Thanks for the help!

                  Cheers,
                  joe


                  --- In nslu2-general@yahoogroups.com, Rod Whitby <rod@...> wrote:
                  >
                  > jl0242 wrote:
                  > > I'm starting to think there is a bigger problem here. I've been doing some googling on this "No help available" error and it actually sounds like it's a bug:
                  > > http://www.mail-archive.com/busybox@.../msg00793.html
                  > >
                  > > I installed 'which' via ipkg. Have a look at this output (something's not right here IMO):
                  > >
                  > > # which find
                  > > /opt/bin/find
                  > > # find -maxdepth 1
                  > > BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) multi-call binary
                  > >
                  > > No help available.
                  > >
                  >
                  > If your shell is actually a symlink to busybox, and busybox has 'find'
                  > enabled as an applet, then I think it will find the applet first ahead
                  > of whatever is in the path. Only if you give a full pathname
                  > (/opt/bin/find) will it ignore the in-built find applet.
                  >
                  > -- Rod
                  >
                • Mike (mwester)
                  ... Don t do that. As others have already pointed out, there are numerous other ways to ensure that you get the correct find utility. There are differences
                  Message 8 of 9 , Apr 30, 2009
                    jl0242 wrote:
                    > Thanks Rod, you've hit the nail on the head there. I'm pretty sure I'm seeing the busybox 'find' applet in action here. A few questions:
                    >
                    > 1. Is there any problem in me symlinking /bin/sh to /opt/bin/bash? (I have bash installed). Will this affect any core Unslung (6.10) functionality?

                    Don't do that. As others have already pointed out, there are numerous
                    other ways to ensure that you get the correct "find" utility.

                    There are differences between /bin/sh (the busybox "ash" shell) and bash
                    -- these differences may result in strange behavior of your device, or
                    may even prevent it from booting correctly.

                    I'm still confused - why not just set the default shell for your login
                    account to /bin/bash, and be done with all this? If you need to run
                    bash for some reason from a startup script then just invoke bash
                    directly from your startup script:

                    S99MyStrangeProgram:

                    #!/bin/bash
                    do whatever stuff one needs...


                    > 2. Has the 'find' applet always been included in the BusyBox config for Unslung? I'm not sure entirely certain why, but I never had these problems before I moved to Unslung 6.10 recently. The other examples I've found on the list all seem to have been posted since Unslung 6.10.

                    No. A great deal of work was done to make it possible to use the
                    busybox find applet, in order to save flash space.

                    > 3. Is there a reason that Unslung is still using BusyBox 1.3.1? They look to have got to 1.14.x now.

                    Er -- Unslung 6.x pre-dates busybox 1.14 by a loooong ways. You have to
                    look at what was generally considered a stable version of busybox back
                    when Unslung 6.x development was underway.

                    Also, there's the need for flash space; the design goal for the 6.x
                    busybox was to add the applets necessary to be able to do the unsling
                    operation with a minimum of extra flash space consumed, and to do so
                    while retaining compatibility with the busybox version shipped by
                    Linksys (because of dependencies and custom Linksys patches to busybox).

                    The intent is that should one require non-busybox utils, one would
                    install procps, core-utils, bash, etc. and set the appropriate shells
                    and paths (as has been suggested in previous emails).


                    Mike (mwester)
                  Your message has been successfully submitted and would be delivered to recipients shortly.