Re: Long filenames in DOS/Windows and Unix/Linux

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Spaces in file names are likely not to be an issue if you interact
with the filesystem via a GUI like Windows Explorer *or* if you use
a scripting language like Perl or Python that requires strings used
as filenames to be enclosed in quotation marks.  In those contexts,
space is just another character.
 
It can be a real issue if you're interacting via shell commands.
If I happen to know that none of the files I'm working with have
spaces (or other problematic characters) in their names, a lot of
things become easier -- but risky if there's a funny character I'm
not aware of.  For example, I might type something like:
>
    for file in * ; do cp -p $file $file.bak ; done

That’s the heart of the matter. Field splitting happens after parameter
expansion. The languages that don’t have trouble with spaces in
filenames[1] don’t do it that way. I suspect if some different design
decisions had been made long ago, nobody would be inferring from the
difficulties shell scripts have handling strings with spaces in that
they were unnecessary or even forbidden in filenames.

[1] or any other kind of string. Let’s not get tunnel vision about
    filenames: shell has trouble with spaces in other contexts too.

Tcl is the most instructive example: it has a similar word-base
structure to shell, but largely without getting into the same tangles
over spaces.

It would be ideal, I suppose, if interactive shells dealt better with
spaces in file names, but I'm not sure how that could be achieved.  In
current shells, removing two files named "foo" and "bar" is easy, and
removing a single file named "foo bar" requires some extra effort.  I
find that to be a good tradeoff.

Agreed. I note that tab completion normally adds any quotes needed,
which deals with most of the issues in interactive mode, for me.

As well as the above observations about shell syntax we could also
wonder whether it was ever really necessary to use the same syntax both
for interactive file management and a programming language.

--
https://www.greenend.org.uk/rjk/