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. > 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: 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. 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) 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/ ------------------------------------------------------------------------- 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
