Re: Unidentified subject!

Robert Collins wrote:
> On Mon, 2003-06-09 at 15:09, ${john}$ wrote:
>>The .exe suffix screws things up. A lot of packages identify the target 
>>as Cygwin, and your executables then get that extension. Then the build 
>>fails because a filename is hard-coded in a makefile somewhere 
>>(debian/rules, for example). If you ask me, the .exe has to go. No other 
>>Debian platform uses an extension for exectuables, and you're not going 
>>to persuade everyone to change their packages to accommodate it. So I 
>>guess that means fixing config.guess, so it can identify Debian win32 
>>systems and act appropriately; then and rebuilding gcc. Something like that.
> 
> Don't do this. The .exe suffix should stay. There have been many long
> discussions on this elsewhere, I won't repeat them now.

Your case is so strong that you're not going to bother telling anybody 
what it is. Well gee, I'm convinced.

My argument is simple -- I can't see the port ever happening with the 
.exe extension. Based on the packages I've built, I'd say that suffix 
will breaks hundreds of makefiles in Debian packages. And I'm not 
talking about automatically generated files that can be fixed by 
tweaking a tool or batch editing -- AFAICS, most of these would need to 
be fixed by hand and accepted by maintainers and/or upstreams (varies). 
So anyone who thinks .exe is practicable first needs to explain which 
magic fairy is going to arrange this,

>>Then there's the filename problem -- normally, Windows doesn't do 
>>certain characters, for example colons. You'll hit this one building 
>>packages for perl-doc, defoma, spamassassin, countless Perl modules, 
>>etc. Apparently you can turn on POSIX compliance, which sounds like the 
>>way to go. In a previous discussion I think people suggested patching 
>>newlib to substitute another character, but I don't like the idea of 
>>changing filenames. It just opens up more potential problems (eg 
>>breaking hard-coded filenames in scripts and configs, risks clashes with 
>>other files in Debian, etc).
> 
> Well, IIRC : isn't in the POSIX portable filename list anyway

But it is part of NTFS's POSIX namespace (as is every Unicode character 
except / and null) which means you may use it in a filename. (Whether 
any bit of Windows API will oblige you in this respect is another matter.)

[...]
> and AFAIK : will still refer to alternate streams on NT kernels.

It certainly does if you use it as part of a conventional filename. I 
had assumed that could be circumvented, but perhaps not.

Looking back at was suggested on this list before, I note that it was 
not substitution, but escaping and unescaping of problem-characters. In 
practice, I'd say that's as good as storing the names correctly. (The 
escaping would cause filenames would appear wrong from non-Cygwin apps; 
but said apps wouldn't be able to use them if they were named correctly 
anyway.) That system should work for Win9x too, although nobody should 
think for one minute I give a damn about whether this port ultimately does.

While we're talking file names, I'll point out that I have here a box 
with a moderate number of packages installed, and there are...
,
| john@termite:~$ dpkg -S '*' | sed "s/^[^:]*: //" | tr A-Z a-z \
| > | sort | uniq -d | wc -l
|    161
`
...161 package files with names that differ only by capitalisation. 
Another little issue that people might want to consider, given that VFAT 
and the win32 and DOS NTFS namespaces preserve case but are not case 
sensitive.

-- 
John Ineson