gnu.emacs.help
[Top] [All Lists]

Re: Emacs Environment Variables

Subject: Re: Emacs Environment Variables
From: Tim X
Date: Sun, 25 Nov 2007 17:18:37 +1100
Newsgroups: gnu.emacs.help

Peter Dyballa <Peter_Dyballa@xxxxxx> writes:

> Am 24.11.2007 um 13:48 schrieb Ismael Valladolid Torres:
>
>> I am afraid he means running emacs from an icon in its window manager
>> menu. Then it doesn't honor .bashrc, as it wasn't run from a bash
>> session.
>
> I did not understand the message this way, although I though of login  and
> non-login interactive sessions.
>
>>
>> If running Debian or Ubuntu he could move important env definitions
>> into /etc/environment. I am sure there are ways to do this on Fedora
>> or Mandriva systems.
>
>
> There is also /etc/profile which is read by bash if it's launched as  a
> login shell. If a user does not have ~/.profile, then a bash login  shell
> reads ~/.bash_login. When this file sets important environment  variables
> like LANG or LC_CTYPE, then the user's environment will  have set these
> values from login time at the login screen. All other  processes will
> inherit from this environment, including X, will which  pass this on to all
> clients launched via menu entries â and maybe  also via icons on the
> desktop or in the dock (but I am guessing, I'm  mostly on Mac OS X or
> Solaris with OpenWindows). ~/.bashrc would not  need to contain that many
> basic settings if it can "delegate" some to  ~/.bash_login or ~/.profile.
>

Problem is that Xsession is, by default, not run as a login shell and is
not an interactive shell, so basically, none of the normal init files are
sourced. 

> IMO bash is a bit too complicated to be used as a user's default shell.

Really? What would you recommend as a default user shell (and please don't
say csh!)? Having originally started with Bourne (sh), then a brief time
with csh, followed by ksh and then tcsh and zsh and finally just going with
the common default bash, I'd have to say I don't find bash any more
difficult than any of the other common shells and certainly not any morre
complicated.

(of course, all the shells have improved greatly from an end user
perspective. I still remember how pleased I was when shells started coming
with built-in support for meaningful promts that included the current
directory and hostname in them. I remember having to spend hours getting
the same behavior using the output from pwd and sed, together with some
other trickery I don't remember fully to get the prompt reset correctly
when you cd to another directory. Back then, you also needed to know at
least two shells - something reliable and straight-forward for scripting,
like sh and something with a few more bells/whistles, like csh/tcsh for end
user interaction because it seemed you couldn't get both. csh had some nice
bells, but crappy scripting syntax. sh had simple clear scripting syntax,
but no nice end-user bells. There were also a few inconsistencies with csh
yu had to watch out for)

these days, I seem to only do very trivial shell scripts. anything that is
at all complex or non-trivial and I'll probably use perl, ruby or maybe
even something lispy like rep, guile, lush or scsh. 

tim


-- 
tcross (at) rapttech dot com dot au

<Prev in Thread] Current Thread [Next in Thread>