python 2.7.12 on Linux behaving differently than on Windows

Mon Dec 5 15:14:17 EST 2016

Chris Angelico <rosuav at gmail.com>:
> On Tue, Dec 6, 2016 at 4:23 AM, Marko Rauhamaa <marko at 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