Hacker News Reader

You can use brace expansion to avoid calling out to seq in a subshell (`{1..5}` expands to `1 2 3 4 5`)

Awesome, thanks!! Just found the section of the man page, looks like a pretty feature-filled expansion technique:

       A sequence expression takes the form {x..y[..incr]}, where x and y are either  integers  or
       single  characters, and incr, an optional increment, is an integer.  When integers are sup-
       plied, the expression expands to each number between x and y, inclusive.  Supplied integers
       may  be  prefixed  with  0  to  force each term to have the same width.  When either x or y
       begins with a zero, the shell attempts to force all generated terms  to  contain  the  same
       number  of digits, zero-padding where necessary.  When characters are supplied, the expres-
       sion expands to each character lexicographically between x  and  y,  inclusive,  using  the
       default  C locale.  Note that both x and y must be of the same type.  When the increment is
       supplied, it is used as the difference between each term.  The default increment is 1 or -1
       as appropriate.

...although I just tested it, and the increment and 0-padding only work in non-interactive mode ='(

> ...although I just tested it, and the increment and 0-padding only work in non-interactive mode ='(

Works for me...

    $ echo $0 # determine current shell (alternative: "ps -p $$")
    bash
    $ echo {01..100..20}
    001 021 041 061 081

But note that `{x..y}` has a major limitation: it doesn't support variables. Example:

    $ n=5
    $ echo {1..$n}
    {1..5}
    # intended output: 1 2 3 4 5

The `for ((...))` syntax mentioned by @zazaulola supports variables (it works in bash and zsh).

For completeness, here is a POSIX sh approach that doesn't require `seq` (in fact I notice this is what your "Uber Fancy" version uses internally):

    i=1
    while [ "$i" -le 5 ]; do
        echo "$i"
        i="$((i+1))"
    done

(but note that `continue` won't work properly).

You can always do double eval for variables:

    var=1234
    echo `echo {1..$var}`

Yup, which you could also write as eval echo {1..$var} . The second argument's variable is being interpolated as if it's a quoted string, before it gets passed to eval, so eval is actually seeing "{1..1234}" and not doing the interpolation itself (because it wouldn't, because the variable isn't valid in a range). This should prevent the need for a subshell and the second echo call.

With an array:

  var=12
  declare -a array=()
  eval "array=( {01..$var} )"
  echo "${array[@]}"
  # 01 02 03 04 05 06 07 08 09 10 11 12

Ahhh, my login shell is bash v3 (friggin' MacOS!) but my PATH has bash v5! On Bash v5 it works interactively! (probably v4+ too)

Surely the version you would actually use is:

  seq 5

Presumably the point is to do something with i rather than just printing.

  seq 5 | xargs -n1 <...>

Very beautiful. Of course now you have to deal with xargs' wacky syntax and options for string interpolation, which is probably why people don't do this.

Compare:

for i in {1..5}; do echo file_$i; done

with

seq 5 | xargs -I % echo file_%

I had to look up the manpage for xarg's -I, while the for loop uses a small number of orthogonal features entirely in my "working set".

This is also why people "uselessly" use cat.

I'm not sure whether you're trying to prove the authors point or not?

For myself I can generally write basic python (or c) without having to double check. Shell not so much. Eg Does the semi colon come before or after the do? Then there's the quoting rules and expansions etc.

All shell scripting is just running commands in a shell terminal. The language is designed as if you're at a VT100 terminal typing commands in by hand. Pressing 'Enter' key tells the shell to evaluate whatever was just typed in. A semi-colon is the equivalent of the 'Enter' key. Most commands allow you to pass arguments to them (and so don't need a semi-colon after) unless they are the end of a block, like done, fi, esac, etc, which don't take arguments, so they would get a semi-colon or newline after them. Most things want some whitespace between each element, so for example "[1-lt2]" doesn't parse, but " [ 1 -lt 2 ] " does.

If you read the man page from top to bottom, pretty much all your questions will go away. Bash is only as confusing and mysterious as every other language. Imagine trying to use C++ without ever reading a book on how C++ works. Bash is much simpler! But you should read the man page!

For me, the most beautiful representation of a loop is like this:

  for((x=1;x<=5;x++))
  do if [[ -v x ]] 
    then echo $x
    fi
  done

Tip: You can use { } instead of do/done to emulate C syntax.

Aside: [[ -v x ]] tests if the variable x is set. It should probably be [[ x -ne 0 ]] to match the example from the parent.

"You can use { } instead of do/done"

In sh ? In bash ? In zsh ? I am very glad if it is so in any of them

It works in bash/zsh/ksh but not in sh/dash. Examples:

    for i in 1 2 3 4 5; { echo $i; }
    for ((i=1;i<=5;i++)) { echo $i; }

(It doesn't work with `while` loops, at least not in bash.)

Thanks. I just tried

while (ls) { echo Hello; echo World }

does work in zsh

But if your break a line after {, then you get while> prompt and } does not trigger execution

Maybe a bug?

I strongly dislike this style. Way too easy to commit a one off error.

Personally, I never use naked loops if I can avoid them. Either foreach or higher order functions if the language has them.

if you like pipes and a more functional style:

  seq 5 | xargs -n1 <...>