help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (emacs+unix): How to have a file-name containing slashes, angle-bra


From: Xah
Subject: Re: (emacs+unix): How to have a file-name containing slashes, angle-brackets, etc?
Date: Sun, 24 Aug 2008 12:12:38 -0700 (PDT)
User-agent: G2/1.0

On Aug 24, 5:31 am, Nikolaj Schumacher <m...@nschum.de> wrote:
> Xah<xah...@gmail.com> wrote:
> > Unix is the worst, they pretty much just allow
> > alphanumerics and not even space. If you have anything like “,=();
> > \'"~&-” etc, you can expect most shell tools to erase you disk)
>
> Actually unix systems allow pretty much every character except / and the
> null character.

To say that unix allows much wider chars in file names is like saying
mud is the best medium for sculpture.

Unix file names, for much of its history up to perhaps mid 2000s,
effectively just allows alphanumerics plus hyphen “-” and underscore
“_”. As a contrast for comparison, Mac's file names often contain
punctuations such as “,$#!*()” and space, but also allows non-ascii
such as

euro lang chars çö
printer's symbols †‡°
euro lang puncs «»¡
math ≈∫µ∂ƒπ≠≤≥∞
special symbols ™®©£¢

etc since the early 1990 or before.

ascii punctuations chars and non-ascii chars such as above are also
allowed in filenames in Windows since about Microsoft Windows NT in
late 1990s or earlier. Tools in MacOS (such as AppleScript) and
Windows, support, expect, these chars in file names.

Sure, you can use many non-alphanumeric chars besides hyphen and
underscore in unix, but the system is simply not designed for it.
Majority of unix tools, including file name listing, will chock and
break if your filename contain these chars. The chocking doesn't
actually give you a nice error message, but silently break and often
resulting in unexpected and unpredicable behavior. In short, it's just
not designed for it.

Issues like these often perpetuate the myth that unix is “powerful”,
but in fact it's just raw and no-design.

I wrote a essay describing this situation... here:

The Nature of the “Unix Philosophy”
http://xahlee.org/UnixResource_dir/writ/unix_phil.html

plain text version follows:

---------------------------
The Nature of the “Unix Philosophy”

Xah Lee, 2006-05

In the computing industry, especially among unix community, we often
hear that there's a “Unix Philosophy”. In this essay, i dissect the
nature and characterization of such “unix philosophy”, as have been
described by Brian Kernighan, Rob Pike, Dennis Ritchie, Ken Thompson,
and Richard P Gabriel et al, and in recent years by Eric Raymond.

There is no one definite set of priciples that is the so-called “unix
philosophy”, but rather, it consistest of various slogans developed
over the decades by unix programers that purport to describe the way
unix is supposed to have been designed. The characteristics include:
“keep it simple”, “make it fast”, “keep it small”, “make it work on
99% of cases, but generality and correctness are less important”,
“diversity rules”, “User interface is not important, raw power is
good”, “everything should be a file”, “architecture is less important
than immediate workability”. Often, these are expressed by chantible
slogans that exhibits juvenile humor, such as “small is beautiful”,
“KISS (Keep It Simple, Stupid)”.

Suppose, we take a team of student programers to produce a large
software system. When the software is done, give it to software
critics to analyze and come up with some principles that characterize
its design decisions, without disclosing the nature of the programers.
The characterization of such software, will more or less fit the
descriptions of the “Unix Philosophy” as described in different ways
by various unix celebrities.

For example, it would focus on implementation simplicity as opposed to
interface simplicity. It will not be consistent in user interface, but
exhibits rawness. It would be correct only for most cases, as opposed
to mathematically correct or generic. It would employ simplistic data
structures and formats such as text-files with rows of lines and space
separated columns, as opposed to a structured system or binary format
that requires a spec. It would be speedy, but less on scalability. It
would consists of many small programs, as opposed to one large system
with inter-dependent components. It would be easy to patch and port,
but difficult to upgrade its structure or adapt entirely new
assumptions.

The essence of this theory is that when a software is produced for
real world use, it is necessary that it works in some acceptable way,
otherwise the software will be continuously debugged and refined. A
software system written by a bunch of student or otherwise under-
educated programers, but refined long enough for acceptably practical,
real world use, will necessarily develop characteristics that is known
as the Unix Philosophy.

  Xah
∑ http://xahlee.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]