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