Borsenkow Andrej <[EMAIL PROTECTED]> writes:

> On Чтв, 2002-01-10 at 21:12, Guillaume Cottenceau wrote:
> > Borsenkow Andrej <[EMAIL PROTECTED]> writes:
> > 
> > [...]
> > 
> > > > use
> > > > startx "KDE 3"
> > > > or
> > > > startx 'KDE 3'
> > > 
> > > Are you serious? 
> > 
> > Yes -- why ?
> > 
> 
> Because why should users go into trouble of typing extra characters
> while there is absolutely no real reasons to keep this name?

Well "absolutely" is a bit too strong IMO. If 99% of people use a
graphical logging manager (and that's what our users do), I would
even then think that there is a real reason: in written language,
you need a space between a name and a number, even if the number
reflects the revision/version number of what name refers to.


[...]

> No it is not bugged. It is the basic shell design that is flawed.
> 
> startx build argument list like (very approximately)
> 
> 
> for i in "$@"
> 
> arglist="$arglist $i"
> 
> - at this step distinction between one argument "KDE 3" and two
> arguments "KDE" "3" disappears - 

Right so we could say that it's the "for" loop in shell which
forgets spaces in names. What I wanted to say is that if "startx"
designers would have thought/wanted of really supported a target
name with space in the name, it could be written otherwise
(granted xinit would also support it).

 
> and then calls xinit with
> 
> xinit $arglist
> 
> - it must call it without quotes to be able to pass multiple arguments -

Yes. We really miss lists/tuples here :-(.

 
> To preserve arguments with spaces you need something like
> 
> for i in "$@"
>  arglist="$arglist \"$i\""
> 
> eval "xinit $arglist"
> 
> But why do this if you never actually expect arguments with spaces in
> them?

:-).
 

[...]

> > [gc@obiwan ~] ruby -e 'puts ARGV[0]' "first arg"
> > first arg
> >
> 
> It is not a problem.

No it was just the demonstration that using "first arg" really
gives the string "first arg" to the program, not just "first", so
that it was really the startx program and not the argument
processing when calling a program, which was bugged. I thought
(wrongly) that you stated that in your previous post :-).


-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/

Reply via email to