python 2.7.12 on Linux behaving differently than on Windows

Marko Rauhamaa marko at
Mon Dec 5 15:14:17 EST 2016

Chris Angelico <rosuav at>:

> On Tue, Dec 6, 2016 at 4:23 AM, Marko Rauhamaa <marko at> 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:


   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" ...

   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

   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


More information about the Python-list mailing list