Home Original page

python 2.7.12 on Linux behaving differently than on Windows

BartC bc at freeuk.com
Sun Dec 4 17:19:56 EST 2016 
On 04/12/2016 20:26, DFS wrote:
> $python program.py column1=2174 and column2='R'
>
>
> Windows (correct)
> $print sys.argv[3]
> column2='R'
>
> Linux (incorrect)
> $print sys.argv[3]
> column2=R
>
> It drops the apostrophes, and the subsequent db call throws an error:
> sqlite3.OperationalError: no such column: R
>
> The way it's used in code is:
> argcnt   = len(sys.argv)
> querystr = ' '.join(sys.argv[1:argcnt])
>
>
> I tried using dbl-quotes in the command line, and with the join()
> statement, and neither worked.
>
>
> Edit: I got it to work this way:
> column2="'R'"
>
> but that's bogus, and I don't want users to have to do that.

You can put double quotes around the whole thing:

  "column2='R'"

otherwise I don't know what the solution other than for a program be 
aware of the possibility and allow for either input, if there are no 
conflicts (for example if both R and 'R' are valid inputs and mean 
different things).

Command parameters /do/ behave differently between Windows and Linux, 
for example try writing *.* as that third parameter.

In Windows, it will print *.*.

In Linux, if you have 273 files in the current directory, if will print 
the name of the first, and there will be /272 further command 
parameters/, each the name of a file. (I couldn't believe this when I 
found out; one of my directories recently had 3.4 million files in it, I 
don't really want *.* expanded to 3.4m arguments. Here, the fix is again 
to use double quotes: "*.*". But what if the user doesn't do that?)

-- 
Bartc
More information about the Python-list mailing list