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?I fall back on `for filename in os.listdir():`
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."
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.) touch -- -nAnyway, 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..
for i in $(seq 1 10); do echo $i; doneOnly rely upon it when GNU is a focus, which is not everywhere.
These are the POSIX utilities:
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.
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
}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.)