--- Martin Bähr <[EMAIL PROTECTED]>
skrev:

> On Sun, Oct 01, 2006 at 05:42:08PM +0200, Axel
> Liljencrantz wrote:
> > Hope the forwarding doesn't mess up the formating
> completely.
> 
> many extra line breaks unfortunately, makes the
> quotes hard to read.
> but thankfully your replies start with an empty line
> so that is easy
> enough to pick out.
> 
> > > But (1) is not a reason, as fishd proves: if the
> shell becomes a
> > > server, things like ``set`` and ``cd`` can be
> implemented as external
> > > commands!
> 
> for set i can see the use, but for cd? 
> that would always be something local to a process.

The only use is that you move more functionality out
of the shell proper. The code becomes more modular,
more extensible, easier to maintain, etc.

> 
> > Implementation-wise, you'd need to update fish a
> bit to do that.
> > Specifically, you can't currently change the value
> of a universal
> > variable in only one shell. You'd need to be able
> to do something like
> > 'set --universal --on-process [PARENT PID] CWD
> /usr'.  Adding this
> > makes sense to me. If one was to make 'set' an
> external command as
> > well, one would need to go even further, and allow
> the user to set
> > local and global variables through fishd, which
> has some rather nasty
> > implications for security and code obfuscation
> potential.
> 
> something i would like to see is the ability to
> force override global
> variables with a universal one:

This is a conflict between security and predictability
 vs. convenience. The downside of allowing overriding
universal variables is that you can never rely on the
value of a variable you just set, not even if you just
set it yourself. A hostile program can do bad things
to all the users running shell instances, which may
presumably include important scripts. I clearly see
the beneft you are after, but I think the
disadvantages are greater. 
> 
> that scenario is especially useful with screen
> inside X.
> when you log into X a DISPLAY variable is set. then
> screen is started
> and all shells inherit that variable as a global
> one.
> 
> next i log in from a different X server, and connect
> to screen. for the
> different X server i need a different value for
> DISPLAY. setting that as
> a universal variable should help. but unfortunately
> i have to unset the
> the global DISPLAY in each shell to get to the
> universal one.

You can probably get the same effect by using 'set -qU
DISPLAY' to occasionally check if there is a universal
DISPLAY variable defined, and if so erase the global
one with 'set -eg DISPLAY'.

> 
> although this could be solved in a different way
> too:
> mark all externaly inherited variables as special so
> that only when they
> are changed, their type is fixed to global or
> universal. (where set
> DISPLAY would make them into a global variable, and
> set -U makes it into
> a universal variable but behaves as if the variable
> has not existed before)
> 
> > For 'cd' I think this may be a good idea, I think
> the drawbacks for
> > 'set' are large enough that this is a bad idea.
> 
> why?
> i can already run a fish script that invokes set on
> universal variables
> from anywhere, thus treating set like an external
> command.
> the only question is whether set should be allowed
> to change anything
> other than universal variables for other fish
> processes.
> 
> being able to change the parent environment would be
> very helpful
> though. (see the discussion on other programs
> wanting to change the
> parent environment)

Yes, that would probably be one of the more common
usages of precess-specific universal variables.

> 
> greetings, martin.
> -- 
> cooperative communication with sTeam      -    
> caudium, pike, roxen and unix
> offering: programming, training and administration  
> -  anywhere in the world
> --
> pike programmer   travelling and working in europe  
>           open-steam.org
> unix system-      bahai.or.at                       
> iaeste.(tuwien.ac|or).at
> administrator     (caudium|gotpike).org             
>             is.schon.org
> Martin Bähr       http://www.iaeste.or.at/~mbaehr/
> 

-- 
Axel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users

Reply via email to