[issue43554] email: encoded headers lose their quoting when refolded
New submission from Emil Styrke :
When a header with an encoded (QP or Base64) display_name is refolded, it may
lose (some of) its encoding. If it then contains illegal "atext" tokens, an
invalid header will result.
For example, `From: =?utf-8?Q?a=2C=20123456789012345678901234567890123456?=
` will become `From: a, 123456789012345678901234567890123456
` This contains a comma character which needs to be quoted:
correct rendering would be `From: "a, 123456789012345678901234567890123456"
`. Note that this example isn't even folded to multiple
lines, since the decoded text is short enough to fit in one line.
This can be triggered by `BytesParser(policy=policy.default).parsebytes("From:
=?utf-8?Q?a=2C=20123456789012345678901234567890123456?=
").as_bytes()`, but the offending code seems to be in or
below `email.policy.EmailPolicy.fold`. See attached file for examples with and
without folding.
--
components: Library (Lib)
files: test_folding_bug.py
messages: 389061
nosy: Emil.Styrke
priority: normal
severity: normal
status: open
title: email: encoded headers lose their quoting when refolded
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49893/test_folding_bug.py
___
Python tracker
<https://bugs.python.org/issue43554>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16328] win_add2path.py sets wrong user path
New submission from Emil Styrke: OS: Windows 7 Ultimate x64 Python version: 2.7.3 x64 win_add2path.py in the scripts directory is supposed to add the Scripts directory according to its source. However, it tries to add $PYTHONPATH/Scripts, when in fact the Scripts directory is at $PYTHONPATH/Tools/Scripts in 2.7. However, it seems like e.g. Setuptools still installs itself in $PYTHONPATH/Scripts, so maybe the right solution is to add both directories. Furthermore, the script sets the default user path to %PATH%, which is not correct at least on windows 7. I have to manually delete this part of the user path to get the user path merged correctly with the system path in cmd.exe. -- components: Demos and Tools, Windows messages: 173840 nosy: Emil.Styrke priority: normal severity: normal status: open title: win_add2path.py sets wrong user path type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue16328> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16328] win_add2path.py sets wrong user path
Emil Styrke added the comment: Ok, thanks for clearing that up. And yes, I meant the pythonpath variable in the script, which seems to be derived from sys.executable. But in that case, it's unfortunate that the c:\python27\scripts dir is not created during install. I did win_add2path right after install, and then it didn't add the scripts path because it didn't exist. -- ___ Python tracker <http://bugs.python.org/issue16328> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4944] os.fsync() doesn't work as expect in Windows
Emil Styrke added the comment: I have experienced this issue with Python 2.7.8 and 2.7.9. It is almost the same issue as the OP experiences as far as I can tell: spawn some Python threads that each create a file, flush, fsync, close, then start a subprocess which uses the file through the Windows API. One thing that may differ is that I create the file and spawn the child from the same thread. I tried with close_fds=True, and it indeed works then, but like the OP, in my production code I need to get the output from the process, so it is not a usable workaround for me. Test script and child program code is available at https://gist.github.com/anonymous/5d7d198cd3c22b31fa2a (the file upload button doesn't work for me it seems). Running the script on my machine will print at least one failure most of the time, but not always. -- nosy: +Emil.Styrke versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue4944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4944] os.fsync() doesn't work as expect in Windows
Emil Styrke added the comment: eryksun, thank you for the explanation, the penny finally dropped for me. It's the *other* child processes that keep the file open, not the parent. Actually this bug started hitting me after I *stopped* doing exactly what you suggest (fdopen on the temp file), and instead started using file names generated by my program (opened with regular "open") and now I see why that is. If I use os.fdopen with the O_NOINHERIT flag, it works as expected. -- ___ Python tracker <http://bugs.python.org/issue4944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
