John Weiss wrote:
I just ran a quick test. Any Unix shell treats --option='foo bar'
as a single element of *argv[]. The single-quotes protected the
space from the shell. (I tested with bash, ash, csh, tcsh, ksh, and
bsh.)
For Windows, however I wouldn't be surprised if whitespace chars
John Weiss wrote:
> I just ran a quick test. Any Unix shell treats "--option='foo bar'"
> as a single element of "*argv[]". The single-quotes protected the
> space from the shell. (I tested with bash, ash, csh, tcsh, ksh, and
> bsh.)
>
> For Windows, however I wouldn't be surprised if
On Mon, Jan 24, 2005 at 01:37:38PM +, Angus Leeming wrote:
Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
We don't. All hell breaks loose at this point and always has. The existing
code to split a string up into an argv array is:
:
[snip]
:
On Mon, Jan 24, 2005 at 01:37:38PM +, Angus Leeming wrote:
> Jean-Marc Lasgouttes wrote:
> > What I was not sure about is how you handle option=='foo bar'.
>
> We don't. All hell breaks loose at this point and always has. The existing
> code to split a string up into an argv array is:
:
This is just a status report. No action needed ;-)
I have two patches for the 1.3.x tree:
* The attached patch is just a re-packaging of a number of other, smaller
patches that I've posted to the list before. I describe these again below.
* I have one other patch for the 1.3.x tree that I have
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc has stated at various occassions that all of the
Angus above were fine to apply to the 1.3.x tree. I was just waiting
Angus for the problems Kayvan was having with LyX 1.4.x to be
Angus resolved. That now seems to be the case, so I
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus * I have one other patch for the 1.3.x tree that I have also
Angus posted earlier and so am not attaching here,
Angus placeholders_13x.diff: Define converters as python
Angus $$s/scripts/lyxpreview2ppm.py
Angus Jean-Marc has said he's happy
Jean-Marc Lasgouttes wrote:
I have taken a look at it, and it seems fine to me. I have to admit I
have problems understanding Forkedcall::generateChild, but I trust
your carefulness (?).
It's not meant to be hard. It does this:
Store the input string
exe option option option
as a
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus It's not meant to be hard. It does this:
Angus Store the input string exe option option option as a
Angus vectorchar
Angus Convert all spaces ' ' to '\0'
What I was not sure about is how you handle option=='foo bar'.
Angus To reassure
Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
We don't. All hell breaks loose at this point and always has. The existing
code to split a string up into an argv array is:
char *argv[MAX_ARGV];
string line = command_;
int index = 0;
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
Angus We don't. All hell breaks loose at this point and always has.
But you argue that is it not really a problem for what we are doing,
right?
Jean-Marc Lasgouttes wrote:
Angus Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
Angus We don't. All hell breaks loose at this point and always has.
But you argue that is it not really a problem for what we are doing,
right? What about spaces in
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc Lasgouttes wrote: Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
Angus We don't. All hell breaks loose at this point and always has.
But you argue that is it not really a problem for
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED]
writes:
Angus Jean-Marc Lasgouttes wrote: Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
Angus We don't. All hell breaks loose at this point and always has.
But you argue
But you argue that is it not really a problem for what we are
doing, right? What about spaces in paths?
Angus Screws things up.
Is that a problem in practice? (do we encounter this case in 1.3.x?)
We have never had any official Windows users to date.
What about filepaths with
Kuba Ober wrote:
But you argue that is it not really a problem for what we are
doing, right? What about spaces in paths?
Angus Screws things up.
Is that a problem in practice? (do we encounter this case in 1.3.x?)
We have never had any official Windows users to date.
What about
What about filepaths with spaces on unices, then? IIRC they tend to break
LaTeX runs anyway, so maybe we don't care either?
Ahhh. But MikTeX on Windows definitely does support spaces in file names.
Moreover, since everything is copied to a temp directory for compilation
and the file names
This is just a status report. No action needed ;-)
I have two patches for the 1.3.x tree:
* The attached patch is just a re-packaging of a number of other, smaller
patches that I've posted to the list before. I describe these again below.
* I have one other patch for the 1.3.x tree that I have
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc has stated at various occassions that all of the
Angus> above were fine to apply to the 1.3.x tree. I was just waiting
Angus> for the problems Kayvan was having with LyX 1.4.x to be
Angus> resolved. That now seems to be
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> * I have one other patch for the 1.3.x tree that I have also
Angus> posted earlier and so am not attaching here,
Angus> placeholders_13x.diff: Define converters as "python
Angus> $$s/scripts/lyxpreview2ppm.py"
Angus> Jean-Marc has
Jean-Marc Lasgouttes wrote:
> I have taken a look at it, and it seems fine to me. I have to admit I
> have problems understanding Forkedcall::generateChild, but I trust
> your carefulness (?).
It's not meant to be hard. It does this:
Store the input string
"exe option option option"
as a
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> It's not meant to be hard. It does this:
Angus> Store the input string "exe option option option" as a
Angus> vector
Angus> Convert all spaces ' ' to '\0'
What I was not sure about is how you handle option=='foo bar'.
Angus> To
Jean-Marc Lasgouttes wrote:
> What I was not sure about is how you handle option=='foo bar'.
We don't. All hell breaks loose at this point and always has. The existing
code to split a string up into an argv array is:
char *argv[MAX_ARGV];
string line = command_;
int index = 0;
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> What I was not sure about is how you handle option=='foo bar'.
Angus> We don't. All hell breaks loose at this point and always has.
But you argue that is it not really a problem for what we are
Jean-Marc Lasgouttes wrote:
> Angus> Jean-Marc Lasgouttes wrote:
>>> What I was not sure about is how you handle option=='foo bar'.
>
> Angus> We don't. All hell breaks loose at this point and always has.
>
> But you argue that is it not really a problem for what we are doing,
> right? What
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote: Jean-Marc Lasgouttes wrote:
What I was not sure about is how you handle option=='foo bar'.
>>
Angus> We don't. All hell breaks loose at this point and always has.
>> But you argue that is it not
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
>
> Angus> Jean-Marc Lasgouttes wrote: Jean-Marc Lasgouttes wrote:
> What I was not sure about is how you handle option=='foo bar'.
>>>
> Angus> We don't. All hell breaks loose at this point and
> >>> But you argue that is it not really a problem for what we are
> >>> doing, right? What about spaces in paths?
> >
> > Angus> Screws things up.
> >
> > Is that a problem in practice? (do we encounter this case in 1.3.x?)
>
> We have never had any official Windows users to date.
What about
Kuba Ober wrote:
>> >>> But you argue that is it not really a problem for what we are
>> >>> doing, right? What about spaces in paths?
>> >
>> > Angus> Screws things up.
>> >
>> > Is that a problem in practice? (do we encounter this case in 1.3.x?)
>>
>> We have never had any official Windows
> > What about filepaths with spaces on unices, then? IIRC they tend to break
> > LaTeX runs anyway, so maybe we don't care either?
>
> Ahhh. But MikTeX on Windows definitely does support spaces in file names.
> Moreover, since everything is copied to a temp directory for compilation
> and the
30 matches
Mail list logo
