On 10/2/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
>
> --- 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'.
Thinking a bit more about this, it should be possible to automate this
completely.
function --on-variable DISPLAY check_universal_display
if set -qU DISPLAY
set -eg DISPLAY
end
end
If you add the above function to you ~/.fish file (autoloading won't
work for event handlers), then any global DISPLAY file should be
erased as soon as a universal DISPLAY file is defined.
>
> >
> > 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
>
--
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
