At 18.59 28/04/2002, you wrote:
Premise: I give up. Something must be terribly wrong with me. I try to be
reasonable. I try to be understanding. I try to explain rationally my point
of view. I try to bring real-world examples as proof of my design choices.
I try to come at compromises with your ideas. And it never works. So, I
give up. Just do whatever you want, I won't waste my time anymore, because
it just doesn't work. You all seem pretty smart guys, so I must be the problem
Go ahead and be happy, the annoying troublemaker finally shut up. I'll
never question whatever future choice of yours, this will be my last message
> > what about paths starting with one or two (back-)slashes? I think
> > those, as far as possible, should be portable, that is translate to
> > the same path in all subsystems. It's the only way we can guarantee
> > interoperability
>To guarantee interoperability you'd better use absolute system path names,
>but they use the backslash as element separator, which forces you to
>escape it, for instance in PSX shells.
POSIX+, as an extension to the standard, accepts backslashes as path
separators (backslash isn't in the portable filename character set, so this
should be ok). They still need to be escaped wherever the backslash is a
special character (shell commands, C code, etc.). The negative effects can
be mitigated by appropriate good programming practices, like enclosing
paths for shell commands in single quotes to avoid any kind of special
interpretation of characters
A possible alternative approach is using the forward slash for Win32/DOS
wherever possible in the user interface
> > >For the PSX subsystem, we could define that "/dev/x" will be
> > >translated by PSXDLL.DLL into "\POSIX+\SYSTEM\x" and PSXSS.EXE, at
> > >initialization time, will create symbolic links in "\POSIX+\SYSTEM"
> > >to real devices.
> > if it's not a real directory it shouldn't appear like a real
> > directory. Until we have a filesystem that can host a true /dev
> > directory, better use a double-slash path for such virtual
> > directories, like //./dev/ or similar. The Single Unix Specification
> > (SUS) as of version 3 allows double-slash paths with
> > implementation-specific meaning, and Win32 accepts double-slash paths
> > too. /dev in itself is not defined by the SUS, it is by Filesystem
> > Hierarchy Standard (FHS), but we're far from being able to implement
> > it fully anyway
>Since open() and fopen() are implemented in the PSX client library
>(PSXDLL.DLL) you do NOT need a file system to implement dev, proc etc name
>spaces.
Many /proc objects have been created with the sole purpose of being passed
as pathnames to programs, to allow programs to access stuff they couldn't
normally access. Having /proc implemented locally in POSIX+ kind of defeats
its whole purpose. For example, a common /proc trick is passing to some
program a pathname of /proc/self/fd/1 to force it to write on the standard
output. Think of most Win32 programs, even many command line utilities have
this limitation
|
