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

Re: Does anyone have a distro in which the seq command/program works?

Expand Messages
  • thad_floryan
    ... Hi Ed, Ningo! You hit the nail on the head. But what threw me off was the correct execution of my 2nd example above. I just grep d for seq in .bash*
    Message 1 of 9 , Jul 9, 2013
      --- In linux@yahoogroups.com, ed <ed@...> wrote:
      > On Tue, Jul 09, 2013 at 12:22:47AM -0700, Thad Floryan wrote:
      > > [...]
      > > 1st: $ seq 10
      > > bash: [: 10: unary operator expected
      > >
      > > 2nd: $ seq 1 10
      > > 1 2 3 4 5 6 7 8 9 10
      > >
      > > 3rd: $ seq 1 1 10
      > > 1
      > > [...]
      >
      > I can confirm correct output (second example above) for all three:
      >
      > $ lsb_release -id
      > Distributor ID: Debian
      > Description: Debian GNU/Linux 7.0 (wheezy)
      >
      > Also repeated on coreutils 8.14 compiled on SunOS 5.8 running on
      > SunOS 5.10...
      >
      > I'm wondering are you actually executing seq in your above example,
      > I'm surprised to see a response from bash rather than the seq
      > program. Do you have it aliased? What if you execute it as
      > /usr/bin/seq?

      Hi Ed,

      Ningo! You hit the nail on the head. But what threw me off was the
      correct execution of my "2nd" example above.

      I just grep'd for seq in .bash* and found these lines and I have no
      idea where they came from (seriously) in .bash_aliases -- it must be
      some artifact from some default bash configs from ages ago:

      # "repeat" command. Like:
      #
      # repeat 10 echo foo
      repeat ()
      {
      local count="$1" i;
      shift;
      for i in $(seq 1 "$count");
      do
      eval "$@";
      done
      }

      # Subfunction needed by `repeat'.
      seq ()
      {
      local lower upper output;
      lower=$1 upper=$2;
      while [ $lower -le $upper ];
      do
      output="$output $lower";
      lower=$[ $lower + 1 ];
      done;
      echo $output
      }

      Arggh! Facepalm and headslap. I'm removing those lines ASAP from
      all systems (sigh, maybe tomorrow after some sleep) since that repeat
      function is of NO use to me whatsoever. Actually I'll comment them
      out with a note they hose the seq progrsm. This is gonna take awhile
      to boot up some 30 systems and comment-out that code everywhere.

      Thanks again!

      Thad
    • ed
      ... Around 2004-ish when I was building OpenBSD firewalls I had something similar to emulate the seq program in sh. The correct thing to do would have been to
      Message 2 of 9 , Jul 9, 2013
        On Tue, Jul 09, 2013 at 07:48:17AM -0000, thad_floryan wrote:
        > Arggh! Facepalm and headslap. I'm removing those lines ASAP from
        > all systems (sigh, maybe tomorrow after some sleep) since that repeat
        > function is of NO use to me whatsoever. Actually I'll comment them
        > out with a note they hose the seq progrsm. This is gonna take awhile
        > to boot up some 30 systems and comment-out that code everywhere.

        Around 2004-ish when I was building OpenBSD firewalls I had something
        similar to emulate the seq program in sh. The correct thing to do would
        have been to locate packages or build coreutils, but due to laziness I
        emulated it in sh one way or another. It bit me though somehow, I can't
        remember the details but it was non-trivial and ended up producing
        duff output.

        > Thanks again!

        No problem! Glad it's sorted.

        --
        Best regards,
        Ed http://www.s5h.net/
      • thad_floryan
        ... Hi Ed, When I run seq 10 , seq 1 10 or seq 1 1 10 I m now getting one number per line over 10 lines which makes perfect sense for use in shell scripts
        Message 3 of 9 , Jul 9, 2013
          --- In linux@yahoogroups.com, ed <ed@...> wrote:
          > On Tue, Jul 09, 2013 at 07:48:17AM -0000, thad_floryan wrote:
          > > Arggh! Facepalm and headslap. I'm removing those lines ASAP from
          > > [...]
          > > Thanks again!
          >
          > No problem! Glad it's sorted.

          Hi Ed,

          When I run 'seq 10', 'seq 1 10' or 'seq 1 1 10' I'm now getting one
          number per line over 10 lines which makes perfect sense for use in
          shell scripts and the floating point capability works fine too after
          commenting the errant lines in the .bash_aliases file(s):

          $ seq 1 .5 5
          1.0
          1.5
          2.0
          2.5
          3.0
          3.5
          4.0
          4.5
          5.0

          Hard to believe I haven't used seq in many years since I first found
          it circa the late 1980s -- I wonder if it was in the Usenet archives
          for comp.sources.unix? The only extant list of archives is here:

          http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/

          and that doesn't even include, for example, my tprobe program which
          is in volume 26 (1992) per:

          http://ae-www.technion.ac.il/pkgs/g-k/in/tprobe/tprobe

          and 'seq' is not even in this list:

          http://ae-www.technion.ac.il/pkgs/o-s/

          Most of the archive sites have gone belly-up at a great loss of good
          software. I'm going to need to check the Wayback Machine later this
          week. They have their own problems with the US Government's National
          Security Letters as Brewster Kahle (founder of the nonprofit
          Internet Archive, perhaps the greatest of our digital libraries, and
          of the Wayback Machine, which allows you to browse an archive of the
          Web that reaches back to 1996) relates in this article:

          "What It's Like to Get a National-Security Letter"

          http://www.newyorker.com/online/blogs/elements/2013/06/what-its-like-to-get-a-national-security-letter.html

          The US government is clearly going ape-/bat-s*** crazy nowadays.

          Thad
        • Doug
          ... Ran the commands on pclos KDE 32-bit. All commands work, but print the output one line at a time. 1 2 3 and so on. --doug -- Blessed are the
          Message 4 of 9 , Jul 9, 2013
            On 07/09/2013 03:28 AM, ed wrote:
            >
            >
            > On Tue, Jul 09, 2013 at 12:22:47AM -0700, Thad Floryan wrote:
            >> [...]
            >> 1st: $ seq 10
            >> bash: [: 10: unary operator expected
            >>
            >> 2nd: $ seq 1 10
            >> 1 2 3 4 5 6 7 8 9 10
            >>
            >> 3rd: $ seq 1 1 10
            >> 1
            >> [...]
            >> If you would please perform the 1st, 2nd and 3rd examples and report
            >> back if the output of all 3 is identical, we can pin this down and
            >> hopefully get it fixed.

            Ran the commands on pclos KDE 32-bit. All commands work, but print the
            output one line at a time.
            1
            2
            3
            and so on.
            --doug
            --
            Blessed are the peacemakers..for they shall be shot at from both sides.
            --A.M.Greeley
          • J
            ... I must admit, sheepishly, to laughing hysterically at Thad s misfortune. Thanks for brightening my day :) I laugh mainly because I ve done the same thing
            Message 5 of 9 , Jul 9, 2013
              On Tue, Jul 9, 2013 at 3:48 AM, thad_floryan <thad@...> wrote:
              > Arggh! Facepalm and headslap. I'm removing those lines ASAP from
              > all systems (sigh, maybe tomorrow after some sleep) since that repeat
              > function is of NO use to me whatsoever. Actually I'll comment them
              > out with a note they hose the seq progrsm. This is gonna take awhile
              > to boot up some 30 systems and comment-out that code everywhere.

              I must admit, sheepishly, to laughing hysterically at Thad's
              misfortune. Thanks for brightening my day :)

              I laugh mainly because I've done the same thing in the past by writing
              functions or specialized aliases into .bashrc and then forgetting
              about them down the road. Thankfully, I never had the amount of
              hardware Thad has so fixing the issue when it bit me was a matter of
              only three or four systems. But I do feel your pain and sympathise :)

              Jeff
            • thad_floryan
              ... Hi Jeff, You re very welcome! This is how we learn. For the life of me I don t know for how many years/decades those lines in .bash_aliases have been
              Message 6 of 9 , Jul 10, 2013
                --- In linux@yahoogroups.com, J <dreadpiratejeff@...> wrote:
                > On Tue, Jul 9, 2013 at 3:48 AM, thad_floryan <thad@...> wrote:
                > > Arggh! Facepalm and headslap. I'm removing those lines ASAP from
                > > all systems (sigh, maybe tomorrow after some sleep) since that
                > > repeat function is of NO use to me whatsoever. Actually I'll
                > > comment them out with a note they hose the seq progrsm. This is
                > > gonna take awhile to boot up some 30 systems and comment-out that
                > > code everywhere.
                >
                > I must admit, sheepishly, to laughing hysterically at Thad's
                > misfortune. Thanks for brightening my day :)

                Hi Jeff,

                You're very welcome! This is how we learn. For the life of me I
                don't know for how many years/decades those lines in .bash_aliases
                have been copied from system to system much like my .appt, .emacs,
                .less, .xfigrc, .xinitrc, and other files have been.

                The .bash_aliases on one of the first systems I just "fixed" was
                dated 1-October-2008 and I know other sytems' files are w-a-y older
                than that one.

                The important thing to learn from this is better programming and the
                use of variables that absolutely and positively can/should not have
                any conflicts with other things on a system.

                I've written 10,000+ line scripts for clients to do special things,
                one of the most interesting was one for Sigaba to create installable
                packages for Solaris systems. Key points are these:

                1. explicitly define any program that is used in a script with all
                those definitions near the script's beginning, and

                2. variables and such used in a script must be unique to the script

                A quick example of (1) is the following:

                ECHO=/usr/bin/echo
                SEQ=/usr/bin/seq
                ...

                which should ONLY be used in the script in this fashion:

                $SEQ 10

                Several quick examples of (2) are the following to forms with the
                name of the script being the first part of the variable name or the
                second form with a "_" prefix to all variable names to help assure
                there's no conflicts with anything else on the system:

                SCRIPT_I=0
                _foo=123
                SCRIPT_I=$_foo
                $ECHO $SCRIPT_I
                123

                That may seem like extra and unnecessary typing, but when you look
                at large scripts in toto it's clear what's being done where and the
                items are also easier to search for in an editor when they cannot be
                confused with anything else (e.g., comments and other text).

                Yes, I understand that's a "style", but it's one that's served me well
                for many years.

                > I laugh mainly because I've done the same thing in the past by
                > writing functions or specialized aliases into .bashrc and then
                > forgetting about them down the road. Thankfully, I never had the
                > amount of hardware Thad has so fixing the issue when it bit me was
                > a matter of only three or four systems. But I do feel your pain
                > and sympathise :)

                It's not that bad and gives me an opportunity to verify some of the
                older systems still boot. I just had a problem with one having its
                CMOS/RTC battery die so I need to check all systems and replace with
                fresh batteries as required. Seems to be a mix of CR2032 and CR1220
                (all the same voltage but different diameters and thicknesses). This
                is a good reference:

                https://en.wikipedia.org/wiki/List_of_battery_sizes

                as is this (all of which are PDFs on the following page):

                http://www.digikey.com/catalog/en/partgroup/cr-coin-series/3437

                Thad
              • thad_floryan
                ... Hi Doug, Thank you for checking. And I should have caught the fact the test I ran had the numbers 1-10 horizontally which isn t very useful in a script
                Message 7 of 9 , Jul 10, 2013
                  --- In linux@yahoogroups.com, Doug <dmcgarrett@...> wrote:
                  > On 07/09/2013 03:28 AM, ed wrote:
                  > >
                  > > On Tue, Jul 09, 2013 at 12:22:47AM -0700, Thad Floryan wrote:
                  > >> [...]
                  > >> 1st: $ seq 10
                  > >> bash: [: 10: unary operator expected
                  > >>
                  > >> 2nd: $ seq 1 10
                  > >> 1 2 3 4 5 6 7 8 9 10
                  > >>
                  > >> 3rd: $ seq 1 1 10
                  > >> 1
                  > >> [...]
                  > >> If you would please perform the 1st, 2nd and 3rd examples and
                  > >> report back if the output of all 3 is identical, we can pin this
                  > >> down and hopefully get it fixed.
                  >
                  > Ran the commands on pclos KDE 32-bit. All commands work, but print
                  > the output one line at a time.
                  > 1
                  > 2
                  > 3
                  > and so on.

                  Hi Doug,

                  Thank you for checking. And I should have "caught" the fact the test
                  I ran had the numbers 1-10 horizontally which isn't very useful in a
                  script needing numbers sequentially for, say, a loop's iteration.

                  The intervention of bash in my test should also have alerted me to
                  the source of the problem -- I was simply too weary to fathom that
                  at the time.

                  After several naps this afternoon I'm catching up on sleep so I should
                  be back to normal Wednesday (today).

                  Thad
                Your message has been successfully submitted and would be delivered to recipients shortly.