This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Multiple occurances of: Closing quotes separate words
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Andrey.Kislyuk, acue, cvrebert, eric.araujo, eric.smith, ezio.melotti, python-dev, r.david.murray, robodan, vinay.sajip
Priority: normal Keywords:

Created on 2016-10-09 01:34 by acue, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (2)
msg278329 - (view) Author: Arno-Can Uestuensoez (acue) Date: 2016-10-09 01:34
I am currently writing an extended options scanner including shlex-compatibility mode. So including numerous extended unittests for compatibility verification.

I am not sure whether the following behaviour of shlex.split() is correct:

Quote from manual: 
  Parsing Rules: Closing quotes separate words ("Do"Separate is parsed as "Do" and Separate);

Case-0: Works
 sopts = """-a "Do"Separate """
 resx = ["-a", '"Do"', 'Separate', ]
 shlex.split(sopts,posix=False)
 assert res == resx 

Case-1: Fails - should work?
 sopts = """-a "Do"Separate"this" """
 resx = ["-a", '"Do"', 'Separate', '"this"', ]
 shlex.split(sopts,posix=False)
 assert res == resx 

Case-2: Works - should fail?
 sopts = """-a "Do"Separate"this" """ #@UnusedVariable
 resx = ["-a", '"Do"', 'Separate"this"', ]
 shlex.split(sopts,posix=False)
 assert res == resx 

The Case-0 is as defined in the manuals.

Is Case-1 or Case-2 the correct behaviour?
Which of Case-1, Case-2 is an error?

REMARK: I haven't found an eralier issue, so filing this here.
msg278343 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-10-09 05:04
Case 2 (the actual behavior) is correct.  Quotes *within* words are ignored, only a leading quoted string will result in a separate word.  (That's recursive: try '"Do""This""Separate).

That said, we don't really care about non-posix mode, it's just there for backward compatibility.  I don't know why we haven't changed the default for shlex.shlex to posix=True.
History
Date User Action Args
2022-04-11 14:58:38adminsetgithub: 72577
2016-10-09 05:04:27r.david.murraysetstatus: open -> closed
resolution: not a bug
messages: + msg278343

stage: resolved
2016-10-09 01:34:18acuecreate