[9fans] blanks already handled properly?

[FJ Ballesteros <nemo@gsyc.escet.urjc.es>]

I may be going mad, but, isn't the space problem already solved?

We know that

1 file names may contain spaces, thus ' ' is a legal file name char.
2 spaces are used both as delimiters in command lines and as part of
file names.

1 just means that most programs using [^ \n\t]* as a regexp for a file
name
  should just use [^\n\t]* instead. For example, I tried in acme to
select
  "a b" and button-3 on it: nothing happen. Didn't look at the source
but
  probably acme stopped at the blank.

2 means that file formats should consider that ambiguity.

The shell, IMHO, is already happy with spaces (to my surprise). I tried
with something like:

	touch x 'a b' a2
	files=a*
	for (f in $files) echo $f
	script_that_prints_one_arg_per_line $files

it all worked fine. Thus the shell is already aware that
an already expanded name is just a name, and it doesn't
matter if it contains a ' '  (yes, don't laught, I learned this today).
The use of lists in rc is a good thing, now I know.

So, isn't the answer just that
1. all programs must consider ' ' as a valid char while scanning for
names
   (like the shell already seems to do).
2. [file] formats must be chosen so that they are not ambiguous if file
   names contained on them contain blanks.
3. programs not outputing commands don't need to quote the printed names
4. programs outputing commands  need to quote the printed names.

All this would require is just Rob's %q and a shell q command to
do things like
touch x 'a b' a2
files=a*
for (f in $files) echo cp `{q $f} /other/place/`{q $f}

 [ But note that this other line works without requiring quoting:
	for (f in $files) cp $f /other/place/$f          ]

In case this solves the problem, we would only have to search for
programs that don't handle ' ' within file names and fix them; then
remove quoting from the output of programs that do not output commands;
then add quoting to the output of programs that output commands.

What do you say?