Re: [ros-kernel] File system struct - ENOUGH ALREADY

[KJK::Hyperion <no...@li...>]

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