[issue28595] shlex.shlex should not augment wordchars
Gustavo Goretkin added the comment: Sorry, I typo'd that last example pretty badly. Should be >>> list(shlex.shlex(b"mkdir Bad\xffButLegalPath".decode("utf-8", >>> "surrogateescape"))) ['mkdir', 'Bad', '\udcff', 'ButLegalPath'] -- ___ Python tracker <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Gustavo Goretkin added the comment: >Instead of trying to enumerate all possible wordchars, I think a more robust >solution is to use whitespace_split to include *all* characters not otherwise >considered special. I agree with that approach. Also note that dash/hyphen gets incorrectly tokenized. >>> import shlex >>> list(shlex.shlex("mkdir -p somepath")) ['mkdir', '-', 'p', 'somepath'] White listing all valid word characters is not good, because the surrogateescape mechanism can include all sorts of "characters". In bash: $ echo mkdir $(echo -ne "Bad\xffButLegalPath") mkdir Bad?ButLegalPath the path is one token. However currently in shlex, it gets broken into multiple tokens: >>> list(shlex.shlex(b"mkdir Bad\ffButLegalPath".decode("utf-8", >>> "surrogoateescape"))) ['mkdir', 'Bad', '\x0c', 'fButLegalPath'] -- nosy: +Gustavo Goretkin ___ Python tracker <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26343] os.O_CLOEXEC not available on OS X
Gustavo Goretkin added the comment: Can the documentation be updated accordingly? Currently the documentation (roughly) says that this is available. If not separately noted, all functions that claim “Availability: Unix” are supported on Mac OS X, which builds on a Unix core. os.O_EXLOCK os.O_CLOEXEC These constants are only available on Unix. -- ___ Python tracker <http://bugs.python.org/issue26343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26343] os.O_CLOEXEC not available on OS X
Gustavo Goretkin added the comment: It looks like cpython will check to see if O_CLOEXEC is #defined. In my system's /usr/include/sys/fcntl.h #if __DARWIN_C_LEVEL >= 200809L #define O_CLOEXEC 0x100 /* implicitly set FD_CLOEXEC */ #endif -- ___ Python tracker <http://bugs.python.org/issue26343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26343] os.O_CLOEXEC not available on OS X
New submission from Gustavo Goretkin: I am on OS X 10.9.5 Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.O_CLOEXEC Traceback (most recent call last): File "", line 1, in AttributeError: module 'os' has no attribute 'O_CLOEXEC' I checked on my system $ man 2 open | grep CLOEXEC O_CLOEXEC mark as close-on-exec The O_CLOEXEC flag causes the file descriptor to be marked as close-on- exec, setting the FD_CLOEXEC flag. The state of the file descriptor I first noticed this on an anaconda distribution of python, but it looks like it is also present on the 3.5 .dmg file on https://www.python.org/downloads/ -- components: Macintosh messages: 260135 nosy: Gustavo Goretkin, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: os.O_CLOEXEC not available on OS X versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue26343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com