Re: follow up on bs/del
On Wed, 15 May 1996, Craig Sanders wrote: try my script and see if it makes any difference. Maybe the variables DO have to be explicitly exported. They do. Otherwise they're only seen in the shell and not in any program or subshell. The environment is the same whether you exec or run fvwm. Guy
Re: follow up on bs/del
On Thu, 16 May 1996, Craig Sanders wrote: yeah, but isn't CFLAGS=-O2 make the same as export CFLAGS=-O2 ; make as far as make is concerned? yes. Carlos' script should have worked because that was basically what he was doing. Oh, sorry, I didn't see the '\'s. Guy
Re: follow up on bs/del
On Wed, 15 May 1996, Guy Maor wrote: On Wed, 15 May 1996, Craig Sanders wrote: try my script and see if it makes any difference. Maybe the variables DO have to be explicitly exported. They do. Otherwise they're only seen in the shell and not in any program or subshell. The environment is the same whether you exec or run fvwm. yeah, but isn't CFLAGS=-O2 make the same as export CFLAGS=-O2 ; make as far as make is concerned? Carlos' script should have worked because that was basically what he was doing. Craig
Re: follow up on bs/del
On Wed, 15 May 1996, Guy Maor wrote: On Thu, 16 May 1996, Craig Sanders wrote: yeah, but isn't CFLAGS=-O2 make the same as export CFLAGS=-O2 ; make as far as make is concerned? yes. Carlos' script should have worked because that was basically what he was doing. Oh, sorry, I didn't see the '\'s. either did i at first, that's why i jumped to the same conclusion you did :-) Craig
Re: follow up on bs/del
On Fri, 10 May 1996, Carlos Carvalho wrote: I've just tested netscape without the overriding translations and it works fine, with just keycode 22 = BackSpace. However, this is only true if I invoke it from the shell. If it's invoked from fvwm backspace doesn't work, with or without the translations. Here's what I use to call netscape (I don't use the debian package): #!/bin/sh XNLSPATH=/usr/local/netscape112/nls \ XKEYSYMDB=/usr/local/netscape112/XKeysymDB \ /usr/local/netscape112/netscape $* two solutions: 1. Make sure the XNLSPATH and XKEYSYMDB env vars are set and exported BEFORE fvwm is run (i.e. before you startx). This way, fvwm will inherit the environment vars from the parent shell, and everything that fvwm forks will inherit them too. If you export the env vars from ~/bash_profile then it will work only for you, or if you export them from /etc/profile, then it will work for every account on the system...must be root to edit /etc/profile 2. make fvwm run your script rather than netscape. Edit your .fvwmrc and put in the full pathname to your netscape script. BTW, that script should read: #! /bin/bash export XNLSPATH=/usr/local/netscape112/nls export XKEYSYMDB=/usr/local/netscape112/XKeysymDB exec /usr/local/netscape112/netscape $@ The environment variables must be exported, otherwise they are only local to the shell script...they are not passed on to child processes. I use 'exec netscape' because the shell isn't needed any more after netscape loads...may as well get rid of immediately.
Re: follow up on bs/del
Craig Sanders ([EMAIL PROTECTED]) wrote on 14 May 1996 19:00: On Fri, 10 May 1996, Carlos Carvalho wrote: I've just tested netscape without the overriding translations and it works fine, with just keycode 22 = BackSpace. However, this is only true if I invoke it from the shell. If it's invoked from fvwm backspace doesn't work, with or without the translations. Here's what I use to call netscape (I don't use the debian package): #!/bin/sh XNLSPATH=/usr/local/netscape112/nls \ XKEYSYMDB=/usr/local/netscape112/XKeysymDB \ /usr/local/netscape112/netscape $* two solutions: 2. make fvwm run your script rather than netscape. Edit your .fvwmrc and put in the full pathname to your netscape script. That's what I did. BTW, that script should read: #! /bin/bash I used sh, it's the same in debian. export XNLSPATH=/usr/local/netscape112/nls export XKEYSYMDB=/usr/local/netscape112/XKeysymDB exec /usr/local/netscape112/netscape $@ The environment variables must be exported, otherwise they are only local to the shell script...they are not passed on to child processes. My script does exactly the same; it puts the variables in the environment of the command only, not on the user environment. I use 'exec netscape' because the shell isn't needed any more after netscape loads...may as well get rid of immediately. Correct. However in this case you don't need to export the vars, do you? 1. Make sure the XNLSPATH and XKEYSYMDB env vars are set and exported BEFORE fvwm is run (i.e. before you startx). This way, fvwm will inherit the environment vars from the parent shell, and everything that fvwm forks will inherit them too. As before, they're exported to the netscape process, which should be enough. Carlos
Re: follow up on bs/del
On Tue, 14 May 1996, Carlos Carvalho wrote: 2. make fvwm run your script rather than netscape. Edit your .fvwmrc and put in the full pathname to your netscape script. That's what I did. Strange. It should work then. #! /bin/bash I used sh, it's the same in debian. True. I have a habit of explicitly using /bin/bash when i write shell scripts...i also use non-linux, non-gnu machines and sh can't always run bash scripts. bash isn't sh...it's an enhanced sh. My script does exactly the same; it puts the variables in the environment of the command only, not on the user environment. I use 'exec netscape' because the shell isn't needed any more after netscape loads...may as well get rid of immediately. Correct. However in this case you don't need to export the vars, do you? 1. Make sure the XNLSPATH and XKEYSYMDB env vars are set and exported BEFORE fvwm is run (i.e. before you startx). This way, fvwm will inherit the environment vars from the parent shell, and everything that fvwm forks will inherit them too. As before, they're exported to the netscape process, which should be enough. oh yeah. I see what you were doing now. Yep, that should work. try my script and see if it makes any difference. Maybe the variables DO have to be explicitly exported. It won't hurt to have the vars exported to your global environment anyway...and will actually be of use if you use other motif apps. Can't see why anyone would want to unless they had bought a motif dev package and could use shared libs rather than bloated static libs though...IMO motif just isn't nice enough to be worth sacrificing dynamic libs for. Also IMO, companies who make motif libs for linux should make the shared libs (but not the headers) freely distributable under a these may only be used for pre-compiled binaries license. Then there'd be more linux people willing to use motif apps, and more people would develop for it...who wants to distribute a bloated static linked binary which is 2 or 4 times bigger than it needs to be? Can't wait for the free lesstif clone... :-) Then I'll start exploring motif in greater depth...until then I don't trust it because I have to depend on somebody else to compile the binaries, which means I have to trust them not to sneak in a trojan. Craig
