>>>> Ook, so go for //, or go for /proc/varlink. /proc/varlink is
>>>> pretty long to type, but we already have more strange things in
>>>> /proc filesystem :-).
>>> Looks like /proc/varlink prefix is preferrable. This way you'll
>>> not break anything for already existing links (links to now not
>>> existing /proc/varlink will be affected but this could break only
>>> program specially written to be broken with varlinks :-) Of
>>> course /proc/varlink is long to type, but this is better than
>>> other suggestions...
>> If the length is a problem, I'm sure a quick...
>> Q> ln -s /proc/varlink /vl
>> ...would soon cure that...
> I am not know about how this is could be done, but in simplest
> possible realisation this will not work. The idea is that symlink
> must start from exactly following 14 bytes:
> 2F 70 72 6F 63 2F 76 61 72 6C 69 6E 6B 2F
> and this prefix will be stripped out before varlink expansion...
> With this approach you could not find directory /varlink in /proc
> but /proc/varlink//.${uid}/tmp will be expanded to /.500/tmp,
> /.501/tmp, etc...
Ah...in that case, I misunderstood what you were aiming at, sorry.
The way I understood it, what was proposed was to have a directory in
the /proc filesystem called /proc/varlinks which contained a SymLink
entry for each currently existing environment variable with a leading
/ in it, thus making each of them available as part of a path...for
example, exploring my current environment:
Q> ls -al /proc/varlink | tr -s ' ' | cut -d ' ' -f 1,9-
Q> lrwxrwxrwx BASH -> /bin/bash
Q> lrwxrwxrwx EDITOR -> /usr/bin/joe
Q> lrwxrwxrwx ENV -> /home/cus/rhw/.bashrc
Q> lrwxrwxrwx HISTFILE -> /home/cus/rhw/.bash_history
Q> lrwxrwxrwx HOME -> /home/cus/rhw
Q> lrwxrwxrwx KAFFEHOME -> /usr/share/kaffe
Q> lrwxrwxrwx LD_LIBRARY_PATH -> /usr/lib
Q> lrwxrwxrwx MAIL -> /var/spool/mail/rhw
Q> lrwxrwxrwx PWD -> /home/cus/rhw
Q> lrwxrwxrwx SHELL -> /bin/bash
Q> lrwxrwxrwx VISUAL -> /usr/bin/joe
If that had been the case, then my proposal would've worked fine, but
obviously with your suggested implementation, such is not the case...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu