From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] blanks in file names
Message-ID: <20020703140033.A6013@cackle.proxima.alt.za>
References: <6b76d268c7227b6451a9cd533b0576a7@plan9.escet.urjc.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <6b76d268c7227b6451a9cd533b0576a7@plan9.escet.urjc.es>; from Fco.J.Ballesteros on Wed, Jul 03, 2002 at 10:00:55AM +0200
Date: Wed,  3 Jul 2002 14:00:36 +0200
Topicbox-Message-UUID: c06cde58-eaca-11e9-9e20-41e7f4b1d025

*** ramble alert! ***

On Wed, Jul 03, 2002 at 10:00:55AM +0200, Fco.J.Ballesteros wrote:
> 
> IMHO, the problem is mostly the user programs and not the kernel.
> AFAIK, the kernel is fine if you don't use / and \0 as delimiters
> (which seems reasonable to me, although some guys might want to use it too).
> 
Yes, it would be convenient for the delimiter to be soft, for example.

> But the tradition that blanks separate arguments is deeply embedded in
> user programs, perhaps most notably the shell.
> 
I certainly will not argue with this.

> Assume the kernel has changed to use openv[], what would the shell
> do to deal with spaces vs 00A0s ?
> 
Well, it's not as if I'm the genius here :-)
  
The command line (ignore the shell for a moment as its interpreter)
is a very clear expression of the user's intent, in that there is
a long tradition behind it and, eqaully important(ly), it is visually
unambiguous (within human limits).    The feature one often overlooks
of spaces is that they can be repeated with no change of semantics
or replaced by other whitespace with similar results (cf. sendmail's
configuration file and its tab/space madness).

So it would seem reasonable to retain the convention unchanged in
the familiar contexts and seek alternatives in the new, graphical
environments, for example.  Is there perhaps an undiscovered
technique to express a shell pipeline in a graphical format?  If
so, can new separator rules be brought to apply, escaping some of
the limitations of the traditional approach?

Maybe facetiously, I'd like to point out that the space is the
absence of a character to the eye, if we used a typescript interface
with pixel-dots in the character positions, drag-and-dropping
command line parameters would be automatically quoted by the
background pixel-dots.  That is, until you want a pixel-dot character
in an argument. Sigh.

Still, a background of single quotes would work and be horrendously
ugly, argument completion may become mandatory as the shell now no
longer can provide that function as everything is quoted.

In short, no, I do not have an answer for Nemo, but it seems to me
that bending the conventional interface is not going to work well,
we ought to be looking for new answers, not unlike the ingeniousness
that brought us Plan 9 in the first place and acme as the most
extreme example.

++L