Roland Mainz <[EMAIL PROTECTED]> wrote:
> > If you look at the error messages from ksh, you see the same message
> > from within a "runat" session and from within an unlinked dir.
>
> That's incorrect. "runat" starts the shell without having an abolute
> $PWD, the ksh93 patch simply added file names which were not resolveable
> within the shell which caused much trouble.
If this is true, then there is no additional problem in case you are inside
an attribute directory.
> > > - All calls to |open()| needs to be intercepted (which is non-trivial as
> > > much of this code sits in libast and other libraries)
> >
> > Why?
>
> Because there is no central location in the shell which calls |open()|
> (which needs to be replaced by |openat()| for XATTR files), The calls
> are distributed all over libshell, libcmd and libast, making it very
> hard to keep it under control.
You do not need to change open() into openat(), you just need to add
a routine that puts you into the attribute directory.
> > > - All directory operations need to be adjusted, this includes pattern
> > > matching, filename completion (vi, emacs, gmacs), file name caching etc.
> >
> > Why?
>
> Because the code expects that each filesystem object has a proper parent
> object which can be resolved with normal filesystem operatons. Please
> read the code.
I do not see any relation to XATTRs here.
> > > - All functions and builts which operate relative to $PWD need to be
> > > made aware that there is the special case PWD=. and that there are
> > > directories which live outside the normal namespace
> >
> > This also applies to a ksh that runs inside a removed dir.
>
> See above.
So you admit that it is no problem?
> > > - Many of the builtin commands such as "mv", "cp" needs to be modified
> > > to support XATTRs in their operations, others need to be made aware
> > > about the PWD=. case
> >
> > Never try to implement non-trivial commands inside a shell.
>
> This is no solution.
??? I see no reason why "cp" should be inside a shell.
If you like the functionality, use a different name, but never use the
official name unless you make sure that the internal implementation in the
shell behaves exactly as the official external program.
> Jörg... please... you're not in "auto-defend"-mode to protect the XATTR
> implementation in Solaris, right ?
> As I said I have nothing against XATTR files and I even proposed a
> possible solution for the trouble. Please lets discuss that instead of
> trying to hack each single application to fit the parallel XATTR file
> object universe.
I believe that you are confused about some aspects of the XATTR implementation
as you try to look for problems where no problems are.
Please just take into account that:
- XATTRs are in a different name space
- XATTRs may be accessed the same way as other files in case you did
call a "special chdir" command or function.
- The Sun XATTR implementation is the best I am aware of and is the only
implementation that is able to be the "umbrella" for all other XATTR
systems on other platforms.
- Only a few applications need to be changed in order to work with XATTRs
> > Why does ksh miss a "tar" builtin?
>
> Umpf... his could be done, however the builtins should be limited to
> often used utilities to boost performance. /usr/bin/tar is IMO far away
> from that category.
Then please tell me why ksh includes "mv" as a builtin?
I use "star" 10-100 times more often than "mv" and I still use "star"
a bit more ioften than "cp". So am I correct that you vote to remove
"cp" and "mv" from the list of builtins of ksh?
> > > - All consumers of libshell need to be adjusted, this includes biosh,
> > > dtksh, ksh93, tksh and others.
> >
> > I don't understand this.
>
> It means: You have to apply the same mess with catching |open()|,
> directory operations etc. to the libshell consumers as they implement
> lots of builtin commands, too. Please try to understand how
> ksh93+libshell works, e.g. it could be described as "... a hightly
> flexible framework to implement shell support for applications...".
This answer looks like a prove that you seem to have a major missconception
with understanding how an XATTR integration in a shell should be done.
Or do you like to tell us that ksh has bad concepts in it's implementation?
> > > % cd ... # moves into the XATTR subdirectory
> > > Maybe the system call should be seperated for directories and files and
> > > allow the usage of prefix or postfix strings to identify XATTR files.
> >
> > This proposal - using ... - (from Microsoft in 2001) has been rejected by
> > the
> > POSIX commitee because it is not compatible with POSIX.
>
> Yes, and the XATTR API seems to be incompatible to the POSIX shell.
> Wonderfull... ;-(
You stil have to prove this.....
If some of your statements are true, then it may be that the ksh93
_implementation_ is broken. But this does not apply to "the POSIX shell".
"The POSIX shell" is just a definition that (from my knowledge) is not
incompatible to Sun's XATTR implementation.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
