How to waste computer memory?

[Michael Torrie]

On 03/19/2016 02:38 AM, Steven D'Aprano wrote:
> On Sat, 19 Mar 2016 01:30 pm, Random832 wrote:
> 
>> On Fri, Mar 18, 2016, at 20:55, Chris Angelico wrote:
>>> On Sat, Mar 19, 2016 at 9:03 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>>> Also, special-casing '\0' and '/' is
>>>> lame. Why can't I have "Results 1/2016" as a filename?
>>>
>>> Would you be allowed to have a directory named "Results 1" as well?
>>
>> If I were designing a new operating from scratch and didn't have to be
>> compatible with anything, I would probably have pathnames be tuples of
>> strings (maybe represented at the low level with percent-escaping),
>> rather than having a directory separator.
> 
> 
> ls -l /home/user/documents/stuff/foo
> 
> 
> ls -l "home","user","documents","stuff","foo"
> 
> 
> I think users of command line tools and shells will hate you.

Of course not.  Shells already associate specific meaning with certain
characters that can be used in file names.  For example the various
quoting characters, such as ' or ". These can be used in file names but
when referred to in the shell are escaped.  So it could be with path
separators. The file system itself could have no separators at all and
the shell could still use "/" to delineate the parts of the path on the
command line.  so

ls -l /home/user/documents/stuff/foo

would still work as would:

ls -l /home/user/documents/music\/fun/foo.

Even better directory delimiters could be set by an environment variable
(kind of like how sed lets you select a delimiter).

DIRSEP=|
ls -l "|home|user|documents|music/fun|foo"

This whole scheme breaks down when it comes to actually writing
programs, though.  Either you force all the libc apis to use lists of
strings for referring to paths (not so horrible but not
backwards-compatible), or you implement a similar escaping scheme in the
path names.  I think we'll stick with disallowing certain characters in
file names forever.