Handling statement OR assignment continuation '\' on Win32 platform

[SureshKalkunte]

BPO	11252
Nosy	@birkenfeld, @ambv

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ambv'
closed_at = <Date 2011-02-21.20:17:07.862>
created_at = <Date 2011-02-20.03:40:06.926>
labels = ['interpreter-core', 'type-bug', 'OS-windows']
title = "Handling statement OR assignment continuation '\\' on Win32 platform"
updated_at = <Date 2011-02-24.16:08:12.525>
user = 'https://bugs.python.org/SureshKalkunte'

bugs.python.org fields:

activity = <Date 2011-02-24.16:08:12.525>
actor = 'Suresh.Kalkunte'
assignee = 'lukasz.langa'
closed = True
closed_date = <Date 2011-02-21.20:17:07.862>
closer = 'lukasz.langa'
components = ['Interpreter Core', 'Windows']
creation = <Date 2011-02-20.03:40:06.926>
creator = 'Suresh.Kalkunte'
dependencies = []
files = []
hgrepos = []
issue_num = 11252
keywords = []
message_count = 8.0
messages = ['128890', '128898', '128932', '128989', '129031', '129039', '129222', '129277']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'lukasz.langa', 'Suresh.Kalkunte']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue11252'
versions = ['Python 2.6', 'Python 2.7']

[SureshKalkunte]

Referring to URL for files used to build the Apache Portable Runtime Utilities library using Python 2.7.1(AMD64) or 2.6.5(Cygwin) on a Win32 system (Windows 7), when apr/build/gen-build.py (http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/build/gen-build.py?revision=886996&view=markup) parses '\' on line 96 and 97 in apr-util/build.conf (http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/build.conf?revision=886996&view=markup), it recognizes them as separate tokens causing the script to fail on line 168 "assert file[-2:] == '.c'". If the line continuation notation ('\') is removed from build.conf, gen-build.py performs without errors.

On a Redhat Linux, I have verified Python 2.5.5 (and trust 2.7.1 to provide the same behavior on Linux) handles '\' without errors leading me to believe that if this is a bug, it is only on Win32 platform (and instances where '\' is used for directory path separation).

I am new to Python, from searching the python bug database, I have not been able to find the above condition covered. If this bug has already been identified, please disregard.

[birkenfeld]

Why do you think this is a bug in Python as opposed to one in the script parsing the .conf file?

[SureshKalkunte]

If the defect was with the script, the failure to bypass the '\' notation would have to be true on Redhat Linux. Since build.conf with '\' notation gets parsed without errors on Redhat Linux, I am under the impression the parsing performed by Python on Win32 recognizes '\' as a legitimate file token resulting in the script to fail.

In summary, I view semantics of '\' being different in Win32 vs. Linux as an inconsistency and hence thought it to be a possible defect in Python. However, if Python scripts do not guarantee platform independence, i.e, one's scripts need to be cognizant of platform idiosyncrasy, then, I believe it is not a bug in Python.

[ambv]

Unfortunately the bug is not in ConfigParser but rather in your gen-build.py. There is nothing special about backslashes and ConfigParser reads them in as part of the value for ldap/paths.

But then look what happens in gen-build.py:215. The split() returns

['ldap/apr_ldap_init.c', '\\', 'ldap/apr_ldap_option.c', '\\', 'ldap/apr_ldap_rebind.c']

and later on the map() in line 216 adds new elements to the list. However, on Linux glob.glob('\\') == [] so nothing is actually added. OTOH on Windows glob.glob('\\') == ['\\']. This behaviour is correct. As a side note, the assert actually fails on '/' (thanks to clean_path).

So, the easiest fix for you is to get rid of the backslashes from the configuration file. They work on Linux by mere coincidence.

[SureshKalkunte]

Yes, the easier fix is to change build.conf file to not use '\'. However,

on Linux glob.glob('\\') == [] so nothing is actually added.
OTOH on Windows glob.glob('\\') == ['\\']

is more definite compared to

They work on Linux by mere coincidence

[SureshKalkunte]

lukasz.langa, confirming the difference in return values for glob.glob() on Win32/Cygwin vs. Linux as the following results show:

--------------------------------------------------------

F1()
ret_val1
     F2(ret_val1)
ret_val2

--
\\\
Cygwin
///

string.split()
/
glob.glob('/')
['/']

string.split()
\
     glob.glob('\')
['\\']

--
\\\
Win32
///

string.split()
/
glob.glob('/')
['/']

string.split()
\
     glob.glob('\')
['\\']

--
\\\
Linux
///

string.split()
/
glob.glob('/')
['/']

string.split()
\
     glob.glob('\')
[]

---

For my education, is there a reason why glob.glob('\') on Win32/Cygwin returns ['\\'] instead of [] in Linux ?

[ambv]

OK, now I know more about glob than I ever wanted to! :) Basically it comes down to this:

unix>>> os.path.split('\\')
('', '\\')

win32>>> os.path.split('\\')
('\\', '')

This is why \ is recognized as the root directory on Win32 and as a non-existent file on Unix.

In case of / both Unix and Win32 treat it as a valid directory separator so os.path.split('/') returns ('/', ''). This is why / is recognized as the root directory on both systems.

Does this answer your questions?

[SureshKalkunte]

Thanks for the education (hopefully a slight detour for you 8-). I included '/' to convey uniform behavior across platforms.

I will take it that the difference in what os.path.split() returns on Win32 vs. Linux is not a bug in Python since its Win32 users have come to expect the response it gives ? if yes, please point me to a resource (i.e, if you are aware, else do not bother 8-) that identifies such other conundrums.