On Tue, 2006-12-19 at 05:59 +1100, Cameron Simpson wrote:
> On 18Dec2006 08:54, Mikkel L. Ellertson <mikkel@xxxxxxxxxxxxxxxx> wrote:
> | You will find that a lot of commands will not handle spaces in a
> | directory/file name well. A big part of that is that when a lot of
> | the CLI programs were written, spaces were not allowed in names.
>
> What makes you believe this last sentence? I've been able to put spaces
> in filenames in UNIX for more than 20 years, and I know the APIs and
> filesystems have allowed it longer than that.
>
> It is true that a lot of badly authored shell scripts don't cope with
> space in names and that, as you've said, because spaces separate words
> in the shell that working with names with spaces is slightly fiddly.
>
> But they've been _allowed_ for decades; the only character you can't put
> in a UNIX filename is a NUL ('\0') because the API uses C strings, which
> are NUL terminated.
> --
> Cameron Simpson <cs@xxxxxxxxxx> DoD#743
> http://www.cskk.ezoshosting.com/cs/
>
Hi, Cameron,
I would have to side with Mikkel on this one. It is not that you
cannot put spaces in the name strings, but that many commands and as you
point out shell scripts don't handle them well. It is generally bad
form to put spaces in filenames. Not that unix or linux can't handle
it, but that it is simply adding unnecessary issues to managing files
and command authoring. Yes, you can write utilites that will parse such
file names or directory names.
However, think about how you enter a command:
mv x y.
Now if x contains a space, a literal command could be:
mv "x z" "y z"
However, things get hinky when adding arguements, or parsing remotely.
Does the string properly end at the quotes, or is the quote (also
permitted, since all printing characters are acceptable) also part of
the name. What are the rules and how are they to be implemented? As
the scripts become deeper, say three or four levels down, where are the
quotations going to end up and what are the parsing rules? Ditto for
directories. This type of murkiness should really be avoided in system
programming or file system structure to help prevent inadvertant errors.
It is even more of a problem when people who are not native speakers of
the programmers personal language attempt to utilize his software or
code.
Personally I dislike using spaces in file names for a plethora of
reasons. It makes reading a list (ls command) more difficult, it makes
command parsing more difficult, and adds unnecessary overhead. You have
a variety of printing, non labeling characters that can be used to
identify the break between words in a file name, from the lowly
underscore to the "." period, and others. I prefer the "_" and
recommend to everyone I teach that they use it. The "_" is far less
ambiguous, clean, and amenable to simple parsing. It also matches the
parsing rules for most programming languages, reducing the number of
rule sets that must be remembered.
I would not prevent anyone from using spaces, but would remind them
that their work belongs to a greater community than themselves, and that
providing for the future portability of their work is good stewardship.
In fact until I came upon Windows using spaces I had never seen a space
in file name, and that encompassed over 15 years experience on 13
different operating systems.
Just my point of view.
Regards,
Les Howell
