Chris Angelico <ros...@gmail.com>:
> On Tue, Dec 6, 2016 at 4:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:
>> Bash is nice, too nice. It makes it easy to write code that's riddled
>> with security holes. The glorious Unix tradition is to ignore the
>> pitfalls and forge ahead come what may.
>
> Bash assumes that the person typing commands has the full power to
> execute commands. I'm not sure what you mean by "security holes",
> unless it's passing text through bash that came from people who aren't
> allowed to type commands.
Let's mention a few traps:
* Classic shell programming is built on the concept of string lists. A
list of three file names could be stored in a variable as follows:
files="a.txt b.txt c.txt"
or maybe:
files=$*
Trouble is, whitespace is not a safe separator because it is a valid
character in filenames.
The only safe way out is to use bash's arrays, which are a deviation
of the classic foundation. That's why most (?) shell scripts just
ignore the possibility of whitespace in filenames.
* A common, classic pattern to pipeline data is something like this:
find_files |
while read filename; do
... do a thing or two with "$filename" ...
done
Unfortunately, the pattern suffers from several problems:
1. A filename can legally contain a newline.
2. A filename can legally begin and end with whitespace which is
stripped by the "read" builtin.
3. The "read" builtin treats the backslash as an escape character
unless the "-r" option is specified. The backslash is a valid
character in a filename.
* The classic "test" builtin (or "[ ... ]") has ambigous syntax:
if [ -e "$filename" -o -e "$filename.bak" ]; then
...
fi
results in a syntax error if "$filename" should be "=".
* This fails gracefully:
local x
x=$(false) || exit
This doesn't fail at all:
local x=$(false) || exit
Marko
--
https://mail.python.org/mailman/listinfo/python-list
