On Thu, May 28, 2009 at 19:11, Martin Bähr <[email protected]> wrote: > On Thu, May 28, 2009 at 06:24:42PM +0300, Beni Cherniavsky wrote: >> Finally, changing the scope of an existing variable is confusing. >> Frequently I set a variable but forget to export it, or later decide I >> want it universal. > > actually, i don't think you can even change the scope of a variable, but > when you set a variable of a different scope you get a new one, leaving > the old one untouched. > > in other words, each scope seems to have its own namespace. > but this is the way most programming languages work. > Touché! I should have understood that (it's the only way local variables can work). Still, I didn't think of that at all.
=> Scrap my "var" proposal for now, it needs to be re-thought, and after several days of thinking I'm still not sure how I'd like it to be. At the very least, we need clear documentation on this area. And an obvious way to see a variable's status (with its value in each scope it exists in!). > like when i find that my screen terminals have the wrong DISPLAY set and > i want to change it i usually set an universal variable since i want to > change it for all terminals, > > so i do> set -Ux DISPLAY :1.0 > > but then i discover that $DISPLAY still has the old value because the > universal variable is masked by the local one. > > so i also need to do> set -e DISPLAY; > > and only now $DISPLAY shows the right value. > > and really there is no easy way to solve that because even if you have a > universal variable you need a way to override it in a specific shell. > Perhaps a note/warning for any non-obvious set in interactive mode? Does fish have a way to easily distinguish > what might be nice is to have all vaiables that exist before fish is > started be universal to begin with, which should work right in most > cases because you can set a new value in every shell and you'd have to > specifically change the universal variable. > > at least, i can't think of a case where this would cause problems. > I'm not sure I'm following. Making all inherited envvars universal would: 1. Prevent 2 fishes from inheriting different values. E.g. running fish in 2 different terminals would break TERM for one of them. You can fix it manually, but this is not how envvars are supposed to work. 2. Make any variable once inherited persistent for future runs. > apart from that, the very existance of universal variables (including > history) is one of the main reasons for using fish for me. > Ah, sure. set -U LIKE_UNIVERSAL_VARS yes Now we all like them ;-) -- Beni <[email protected]> P.S. thank to martin for catching me forgetting "reply to all" for the 10th time. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
