That's a poor job of parameter handling. Without double-quoting, the script cannot handle filenames containing whitespace or pathname pattern-matching metacharacters (*, ?, [...]).

You can double-quote the parameter, but, if the script isn't provided an argument, $1 will expand to a zero-length string instead of no field at all. There's a difference between the two and your script depends on this difference to default to reading stdin.

Since AWK is required to support - as an explicit reference to standard input, it makes sense to use it as a default value when $1 is unset (assuring that the script can function as a filter in a pipeline). "${1--}" will do this and will properly handle whitespace and pattern matching characters in a pathname. It would also be a good idea to exit with an error if the filename argument is provided but null.

This script suffers from the same problems as the other, but the damage is exacerbated by the incorrect use of eval.

In addition to whitespace, your eval approach is vulnerable to filenames with all kinds of shell metacharacters (to name a few): ;&*?"{(['. Aside from the possiblity of unintentionally running a command (possibly in the background), whitespace will cause field splitting to pass a partial, incorrect filename to cut and to the redirection operator.

Worst of all is that these bugs are the result of unnecessary complexity. There's nothing about ...

Code:

cmd='cut -d" "  -f'${range}' '${file}'>'${file}'.tmp'

... that requires eval; nothing at all. Just run it directly:

Code:

cut -d ' ' -f "${range}" "${file}" > "${file}.tmp"

Regards,
Alister