Stephen Harris wrote:
----- Original Message ----- From: "Micha feigin" <[EMAIL PROTECTED]>
To: <lyx-users@lists.lyx.org>
Sent: Wednesday, January 11, 2006 12:52 AM
Subject: Re: sixth release of LyXWinInstaller
Stephen Harris wrote:
----- Original Message ----- From: "Micha feigin" <[EMAIL PROTECTED]>
To: "Stephen Harris" <[EMAIL PROTECTED]>
Sent: Tuesday, January 10, 2006 11:02 PM
Subject: Re: sixth release of LyXWinInstaller
[...]
David Carlisle
Wed, 21 Nov 2001 21:03:33 -0000
"I'm sorry but this isn't really a bug but a feature of the underlying
TeX system. Although LaTeX uses a brace delimited syntax, this
has to expand to the primitive TeX syntax, and
Micha feigin:
"Whatever the lame excuse, this is a bug and not a feature since
everything works just fine under linux, spaces and all. Besides,
everything else works with spaces so I don't see any reason why this
shouldn't.
Beside the fact that people expect it to work with spaces in the path
both in linux and in windows, so adapt the features to the people and
not the people to the features." ...
SH: This is such a compelling and convincing argument that it
certainly deserves recognition from the forum for its perspicuous
explanation of why, since it works on linux, that it should work on
Windows. I will contribute only a Wordy, clarifying remark:
"Unix and Unix-like operating systems assign a device name to each
device, but this is not how the files on that device are accessed.
Instead, Unix creates a virtual file system, which makes all the
files on all the devices appear to exist under one hierarchy. This
means, in Unix, there is one root directory, and every file existing
on the system is located under it somewhere."
You didn't say anything here. In windows you start the path with the
drive letter in linux its just / it doesn't change anything with
regard to the spaces.
I thought I was dropping a hint that there is a difference between the
Linux and Windows file systems and the characters they allow.
I am saying that it is not a feature but either a bug or a design
flow. The >fact that it works on linux and not on windows and that
windows handles >spaces elsewhere means that either bibtex or latex
are doing something >wrong,
Nope, your logic fails. The way this works on Linux is much different
than the workaround the LyX developers used. Not only that, it is nearly
impossible for it to work the same way on Windows as it does on Linux.
It would require changing TeX itself.
Supported Characters http://support.microsoft.com/?kbid=324054
"When you use UNIX, you can use any character in a file name. You
can use special characters that are typically not valid by "escaping"
the character (for example, by prefixing the special character with
a backslash [\]); you cannot perform an escaping procedure in Windows.
The following characters are supported in UNIX file names, but are
not supported in Windows file or folder names:
* Slash mark (/) Backslash (\) Quotation mark (" ")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* Colon (:)
* Asterisk (*)
* Question mark (?)
* Angle brackets (< >)
* Pipe (|)
Micha: "everything works just fine under linux, spaces and all."
SH: So if in Linux if one can use ~/My\ Bst\ Files/research.bst
to escape spaces, then how does one escape spaces in Windows?
Your logic implies that tex understands these escape sequences and ignores
escaped spaces (although I don't escape space in linux). If tex doesn't use the
file system to analyze the escape sequences then it is aware of escape sequences
itself which would make them work in windows.
If tex doesn't understand the escape sequences then it wouldn't help if you use
them in the path also under linux.
The problem with your logic is that you claim that tex uses spaces to delimit a
string. But a space is a space is a space. If it can recognize that a space is
part of the path and not a delimiter in linux (escaping or not) it should be
able to do the same under windows.
Either tex understands escape sequences (which includes escaping spaces) or it
has a method of defining what a string is, including the spaces which is
different on windows and linux, or it has different spaces for string delimiting
and path spaces under linux.
You are mixing up allowed characters in the path, escaping characters that would
otherwise have another meaning and what consists of a string to be analyzed. You
claim that tex uses space to delimit a string (and thus the path), how can it
tell that on linux a space is a part of the path and on windows it doesn't
understand that?
That is ignoring the fact that you can change your character set under linux.
Different allowed character sets (where both allow space by the way) to explain
why there should be a problem doesn't do it. If escaping spaces is used it has
to be internal.
Micha: "so I don't see any reason why this shouldn't."
SH: There may exist a workaround in Windows (temp) but that does
not mean it works because of your logic of spaces working in Linux.
13 July 2005
"Axel Rasche reported that spaces in the file path caused BibTeX
to fail. The adopted solution copies the BibTeX data base to the
temp directory, mangling its name in the process into something
that's both recognizable to the user and useable by BibTeX."
SH: The part that is useable by Bibtex contains _no spaces_.
Micha continues:
"especially since you need to expect spaces in windows (a lot of
>>"regular" users in windows don't know how to move the home
directory from >C:\Documents and Settings\<user>\My Documents not to
mention that its impossible with XP home
edition, you need the professional for that."
Why did you bring this up? It seems like an imaginary issue.
The "regular" user installs the Miktex default to C:\texmf which
has a C:\texmf\bibtex\bst sub-directory
The default for custom bst files is C:\localtexmf\bibtex\bst
The default Working directory for LyX is
C:\Documents and Settings\username\My Documents
The default Temporary directory for LyX is
C:\Documents and Settings\username\Local Settings\Temp\
This works just fine for the "regular" user. There is no
need to "move their home directory". Nor did I advocate that.
I mentioned that Dan's solution seemed a bit like overkill.
This problem has nothing to do with "regular" user experience.
The problem was demonstrated by a poweruser who decided
to put his .bst file in a directory with spaces and then browse
to it. The "regular" user just follows the Miktex recommended
install procedure and doesn't have a problem.
I think the priority of fixing this should relate to its frequency
of being reported as a problem. Apparently, the frequency is
rare (6 mos._since there aren't any other reports by regular users
of abandoning standard procedure: creating a directory with
spaces in it, and placing a custom .bst file there instead of
C:\localtexmf\bibtex\bst and experiencing a failure.
Angus, who was the principle official porter of LyX to Windows
says this is not worth the effort to fix/fragile code. As a LyX user,
I regard the time of the developers as a resource or asset. I don't
want to see developer time, which is limited, and there are a lot of
problems to fix, squandered on minute, infrequent inconveniences.
I compiled LyX140pre3 for Windows. The spellchecker works
with F7, but not if I click on "spellchecker". It doesn't consider
ther3 a misspelled word. IOW, I think every other problem and
goal has a higher priority. I've spent enough time on this thread.
Feel free to have the last Word,
Stephen
+++++++++++++++++++++++++++++++++++++++++++
This Mail Was Scanned By Mail-seCure System
at the Tel-Aviv University CC.
