Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am admittedly someone who wishes Bash were Python (ish). What's wrong with that though? Of course I want the REPL features of Bash, its terseness, its builtin commands for all sorts of OS and filesystem operations. But is it wrong to ask for a more modern syntax on the language side of things (i.e. the for loop for example)?


Well, a bash for loop is pretty close to Python:

    for x in a b c; do
        echo $x
    done
Or ranges:

    for i in {1..10}; do echo $i; done
Do you mean list comprehensions?


The number one use case of `for` in shell scripting is over the output of `$(ls .)` And I immediately run into a problem with filenames that have spaces and then I discover that a stringly typed language has lots of sharp edges.

I fall back on `for filename in os.listdir():`


If I may humbly offer a suggestion, looping over filenames should [edit: almost] never be done with ls. find can be used with much better fidelity:

https://www.shellcheck.net/wiki/SC2012

"ls is only intended for human consumption: it has a loose, non-standard format and may "clean up" filenames to make output easier to read."


Shells usually do not re-split on whitespace after filename generation. So, you could also just use an asterisk for your number one use case:

    dash$ touch "hi ho"
    dash$ touch "there, buddy"
    dash$ for f in *; do echo $f; done
    hi ho
    there, buddy
(EDIT: That was in a scratch directory.) But as @npongratz alludes to in sibling https://news.ycombinator.com/item?id=34727735

    find . [predicates] -print0 | xargs -0
is bulletproof and directory scanning, output, and input loops all run at full C speed. (One predicate is `-maxdepth 1` to not recurse.)


Try this:

   touch -- -n


I'm sure the full list of shell check rules is in the many dozens.. I was just trying to address one apparent misperception. And here I thought someone would complain about not putting $f in double quotes not * instead of ./* ;-)

Anyway, I did mention find-xargs, but it's also true your leading dash filenames mistaken for options point can cause trouble in naive invocations if find roots begin with dashes. Doubtless, a lotta gotchas..


FWIW, if you need to use `sh` instead of `bash` for some reason, you can do the range loop with:

    for i in $(seq 1 10); do echo $i; done


The seq command is not POSIX.

Only rely upon it when GNU is a focus, which is not everywhere.

These are the POSIX utilities:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/


Huh. Why did I misremember that?

I knew `seq` was available on BSDs. For some reason I thought it was on SVr4-derived Unices too (and therefore figured it was either actually Posix, or ubiquitous enough to be reliable anyway), but I guess I got that one wrong.

Maybe because GNU tends to be a bit more heavily influenced by SVr4 than BSD, historically?

Anyway, thanks for the correction.


If you're ok with integer math and no switches, you can easily make your own seq.

The next time that you are on an OSF/1 operating system, you can use this portable version. It's also probably faster than the fork() overhead, assuming dash.

  seq () {
    if [ -n "$3" ]
    then FIRST=$(($1 + 0)) INCREMENT=$(($2 + 0)) LAST=$(($3 + 0))
    else if [ -n "$2" ]
         then FIRST=$(($1 + 0)) INCREMENT=1 LAST=$(($2 + 0))
         else FIRST=1 INCREMENT=1 LAST=$(($1 + 0))
         fi
    fi
    c=$FIRST
    until [ $c -gt $LAST ]
    do printf %d\\n $c
       c=$((c + INCREMENT))
    done
  }


seq being available on BSDs doesn't mean either that it comes from POSIX.


Sorry, didn't mean to imply that.

The point I was making is that because (to my recollection) GNU tends to mimic SVr4, the fact that `seq` is in GNU is probably why I thought it was also available in SVr4-derived Unices.

But also, I know that `seq` is in the BSDs.

Therefore, if `seq` were in GNU, SVr4 and the BSDs, then a) the chances that it would have been included in Posix are very high, and b) even if it wasn't in Posix, the fact that it's in all 3 of those families of shell tools would make it ubiquitous enough that I'd be happy to rely on it for a personal project that I intended to be widely portable anyway.

(Posix tends to codify existing common practice, rather than designing new features for existing systems to implement.)


Ah, that’s kind of like refugees fleeing all kinds of failing states to better places, that have rule or law, democracy, human rights, prosperity and then actively trying to install the norms of the old country in the new place they fled to.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: