Emacs Environment Variables

Emacs Environment Variables

[Phi]

Hi:

    I currently start emacs from bash shell and have a long list of
environment variables defined in
.bashrc . How do I have emacs environment aromatically inherit all the
variables from bash on startup?

Thanks!

Re: Emacs Environment Variables

[Barry Margolin]

In article 
<7e3068b0-defa-4b37-9092-182b521f5f50@e23g2000prf.googlegroups.com>,
 Phi <cyan.phi@gmail.com> wrote:

> Hi:
> 
>     I currently start emacs from bash shell and have a long list of
> environment variables defined in
> .bashrc . How do I have emacs environment aromatically inherit all the
> variables from bash on startup?

You shouldn't need to do anything special.  Environment variables are 
automatically ("aromatically"?) inherited by child processes.

Are you sure you're defining environment variables in your .bashrc, and 
not just shell variables?  To put variables into the environment, you 
need to use "export".

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: Emacs Environment Variables

[Peter Dyballa]

Am 23.11.2007 um 14:43 schrieb Phi:

>     I currently start emacs from bash shell and have a long list of
> environment variables defined in
> .bashrc . How do I have emacs environment aromatically inherit all the
> variables from bash on startup?


Do you start bash in a way that it executes your .bashrc?

To check whether GNU Emacs is aware of all these environment  
variables put into your *scratch* buffer

	(shell-command "env")

position the cursor at the closing parenthesis, and type C-j. In a  
new buffer, *Shell Command Output*, you'll see the variables and  
their values.

--
Greetings

   Pete

"America believes in education: the average professor earns more money
in a year than a professional athlete earns in a whole week." – Evan
Esar

Re: Emacs Environment Variables

[Ismael Valladolid Torres]

Peter Dyballa escribe:
> Do you start bash in a way that it executes your .bashrc?

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.

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.

Cordially, Ismael
-- 
Ismael Valladolid Torres            GnuPG key: DE721AF4
                                       Jabber: ivalladt@gmail.com
http://usuarios.lycos.es/ivalladt/      Skype: ivalladt

Re: Emacs Environment Variables

[Peter Dyballa]

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.

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

--
Greetings

   Pete                           <]
              o        __o         |__    o       HPV, the real
     ___o    /I       -\<,         |o \  -\),-%     high speed!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________

Re: Emacs Environment Variables

[Ismael Valladolid Torres]

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

Ubuntu people also thought this way. But I can't think of myself as
using another default shell than bash. :)

Cordially, Ismael
-- 
Ismael Valladolid Torres            GnuPG key: DE721AF4
                                       Jabber: ivalladt@gmail.com
http://usuarios.lycos.es/ivalladt/      Skype: ivalladt

Re: Emacs Environment Variables

[David Kastrup]

Ismael Valladolid Torres <ivalladt@ono.com> writes:

> Peter Dyballa escribe:
>> IMO bash is a bit too complicated to be used as a user's default shell.
>
> Ubuntu people also thought this way.

Huh?  I don't see that.  Ubuntu defaults to a different /bin/sh, but
that is the _scripting_ default shell, not the user default shell.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Tim X]

David Kastrup <dak@gnu.org> writes:

> Ismael Valladolid Torres <ivalladt@ono.com> writes:
>
>> Peter Dyballa escribe:
>>> IMO bash is a bit too complicated to be used as a user's default shell.
>>
>> Ubuntu people also thought this way.
>
> Huh?  I don't see that.  Ubuntu defaults to a different /bin/sh, but
> that is the _scripting_ default shell, not the user default shell.
>

On my debian system /bin/sh is just a symbolic link to /bin/bash. When you
invoke bash as sh, it reverts to 'traditional' sh behavior and disables
bash specific add-ons. 

the 'real' sh executables I've seen are usually light-weight stripped down
shells suitable for rescue disks etc, where you probably want statically
linked small footprint stuff - but its still the basic sh shell that I
believe you will find on every GNU Linux and from my limited experience
Unix system. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Emacs Environment Variables

[David Kastrup]

Tim X <timx@nospam.dev.null> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Ismael Valladolid Torres <ivalladt@ono.com> writes:
>>
>>> Peter Dyballa escribe:
>>>> IMO bash is a bit too complicated to be used as a user's default shell.
>>>
>>> Ubuntu people also thought this way.
>>
>> Huh?  I don't see that.  Ubuntu defaults to a different /bin/sh, but
>> that is the _scripting_ default shell, not the user default shell.
>>
>
> On my debian system /bin/sh is just a symbolic link to /bin/bash.

On Ubuntu, /bin/sh is dash by default.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Phi]

Thanks for the quick replies. Yes, emacs does inherit the variables
automatically if I start it from a bash terminal. But if I start it
from say my ubuntu menu, then I need
to use the /etc/environment trick. Thanks again!

Re: Emacs Environment Variables

[Tim X]

Peter Dyballa <Peter_Dyballa@Web.DE> 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

Re: Emacs Environment Variables

[Peter Dyballa]

Am 25.11.2007 um 07:18 schrieb Tim X:

>> 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!)?


For interactive use I recommend tcsh to begin with. Tcsh makes no  
complicated difference between interactive and login shells, it  
confuses an user only when preferring an existing ~/.cshrc before  
~/.tcshrc.

Do you know why you are so prejudiced against csh?

--
Greetings

   Pete

"A mathematician is a machine that turns coffee into theorems."

Re: Emacs Environment Variables

[David Kastrup]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 25.11.2007 um 07:18 schrieb Tim X:
>
>>> 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!)?
>
>
> For interactive use I recommend tcsh to begin with. Tcsh makes no
> complicated difference between interactive and login shells, it
> confuses an user only when preferring an existing ~/.cshrc before
> ~/.tcshrc.
>
> Do you know why you are so prejudiced against csh?

Because it sucks for scripting and does not offer any advantage for
interactive work when compared to modern Bourne shells?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Harald Hanche-Olsen]

+ David Kastrup <dak@gnu.org>:

> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
>
>> Do you know why you are so prejudiced against csh?
>
> Because it sucks for scripting and does not offer any advantage for
> interactive work when compared to modern Bourne shells?

Time to blow the dust off an old classic?

  http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: Emacs Environment Variables

[Peter Dyballa]

Am 25.11.2007 um 12:36 schrieb Harald Hanche-Olsen:

> Time to blow the dust off an old classic?
>
>   http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

I know, since some years or decades.

--
Greetings

   Pete

"I love deadlines. I love the whooshing noise they make as they go by."
                                            (Douglas Adams)

Re: Emacs Environment Variables

[David Kastrup]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 25.11.2007 um 12:36 schrieb Harald Hanche-Olsen:
>
>> Time to blow the dust off an old classic?
>>
>>   http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
>
> I know, since some years or decades.

"man csh" verifies that csh is still unsuitable for redirecting stdout
and stderr to different locations.

After years and decades, yes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Peter Dyballa]

Am 25.11.2007 um 14:55 schrieb David Kastrup:

> "man csh" verifies that csh is still unsuitable for redirecting stdout
> and stderr to different locations.

I am proud to report that I have experience in not boiling my eggs  
with my hammer!

How often do you need to separate stdout and stderr in some shell?  
Maybe I have bad habits so that it does not happen that often to me  
that I could remember.

--
Mit friedvollen Grüßen

   Pete

There is no national science just as there is no national  
multiplication table; what is national is no longer science.
                                       -- Anton Checov

Re: Emacs Environment Variables

[David Kastrup]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 25.11.2007 um 14:55 schrieb David Kastrup:
>
>> "man csh" verifies that csh is still unsuitable for redirecting stdout
>> and stderr to different locations.
>
> I am proud to report that I have experience in not boiling my eggs
> with my hammer!
>
> How often do you need to separate stdout and stderr in some shell?

Huh?

dd if=something of=something 2>>logfile | tar xf -

Stuff like that is completely common for scripting.  Or even just

echo "This is an error." >&2

You know, there is a reason that both stdout and stderr exist.

> Maybe I have bad habits so that it does not happen that often to me
> that I could remember.

Maybe you just don't use csh for scripting.  

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Peter Dyballa]

Am 25.11.2007 um 16:19 schrieb David Kastrup:

> Maybe you just don't use csh for scripting.

Yes. Meaning: right. And I never recommended to no-one to use (t)csh  
for scripting.

--
Mit friedvollen Grüßen

   Pete

Encryption:  A powerful algorithmic encoding technique employed in  
the creation
                      of computer manuals.

Re: Emacs Environment Variables

[Sven Utcke]

David Kastrup <dak@gnu.org> writes:

> Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> > How often do you need to separate stdout and stderr in some shell?
> 
> Huh?
> 
> dd if=something of=something 2>>logfile | tar xf -

So what?

(dd if=something of=something | tar xf - ) >& logfile

> Stuff like that is completely common for scripting.  Or even just
> 
> echo "This is an error." >&2

echo "This is an error." > /dev/stderr

> You know, there is a reason that both stdout and stderr exist.

Yes, and tcsh doesn't handle this too well.  But just like Peter I'm
bitten by this _much_ more rarely than by the absence of a "find last
command starting with" functionality in Bash...

Maybe our usage-patterns are different?

Sven
-- 
  ___ _  _____ ___   Dr.-Ing. Sven Utcke                    ___  ___ _____   __
 / __| |/ / __| __|  phone: +49 40 8998-5317               |   \| __/ __\ \ / /
| (_ | ' <\__ \__ \  fax  : +49 40 8994-5317 (NEW)         | |) | _|\__ \\ V / 
 \___|_|\_\___|___/  http://www.desy.de/~utcke    (to come)|___/|___|___/ |_|

Re: Emacs Environment Variables

[David Kastrup]

Sven Utcke <utcke+news@informatik.uni-hamburg.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
>
>> > How often do you need to separate stdout and stderr in some shell?
>> 
>> Huh?
>> 
>> dd if=something of=something 2>>logfile | tar xf -
>
> So what?
>
> (dd if=something of=something | tar xf - ) >& logfile

Depends on tar not outputting anything...

>> Stuff like that is completely common for scripting.  Or even just
>> 
>> echo "This is an error." >&2
>
> echo "This is an error." > /dev/stderr

Unportable even between tcsh and tcsh since it relies on the existence
of a non-standard device.

>> You know, there is a reason that both stdout and stderr exist.
>
> Yes, and tcsh doesn't handle this too well.  But just like Peter I'm
> bitten by this _much_ more rarely than by the absence of a "find last
> command starting with" functionality in Bash...

C-r works pretty well here.

> Maybe our usage-patterns are different?

More likely our understanding of the context.  I tell people that csh
sucks for scripting, and they tell me that I am wrong since they don't
care about scripting.

Somewhat surreal.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Sven Utcke]

David Kastrup <dak@gnu.org> writes:

> > Maybe our usage-patterns are different?
> 
> More likely our understanding of the context.  I tell people that csh
> sucks for scripting, and they tell me that I am wrong since they don't
> care about scripting.

Strange.  Viewed from this side it looked as if people told you that,
yes, tcsh sucks for scripting (and never, ever, even think about using
csh), but is lovely for interactive use.  To which you seemed to
answer "But what about scripting?"...

So maybe we could agree on

a) [t]csh sucks for any serious scripting (anything containing more
   than maybe a foreach loop, some if's, and some simple variable
   substitutions), in which case bash would be a much better choice.
b) tcsh is just fine (and, depending on taste, maybe even superior to
   bash) for light interactive use...

Which, incidentally, would be how I use the two :-)

Sven
-- 
  ___ _  _____ ___   Dr.-Ing. Sven Utcke                    ___  ___ _____   __
 / __| |/ / __| __|  phone: +49 40 8998-5317               |   \| __/ __\ \ / /
| (_ | ' <\__ \__ \  fax  : +49 40 8994-5317 (NEW)         | |) | _|\__ \\ V / 
 \___|_|\_\___|___/  http://www.desy.de/~utcke    (to come)|___/|___|___/ |_|

Re: Emacs Environment Variables

[Johan Bockgård]

Sven Utcke <utcke+news@informatik.uni-hamburg.de> writes:

> I'm bitten by this _much_ more rarely than by the absence of a "find
> last command starting with" functionality in Bash...

history-search-backward

-- 
Johan Bockgård

Re: Emacs Environment Variables

[Sven Utcke]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Sven Utcke <utcke+news@informatik.uni-hamburg.de> writes:
> 
> > I'm bitten by this _much_ more rarely than by the absence of a "find
> > last command starting with" functionality in Bash...
> 
> history-search-backward

Thanks.  How do I get this bound to a key?  And does it only search
for lines _starting_ with the search-string (man doesn't say, and so I
assume it doesn't, which then would be just as useless as
reverse-search-history

Sven
-- 
  ___ _  _____ ___   Dr.-Ing. Sven Utcke                    ___  ___ _____   __
 / __| |/ / __| __|  phone: +49 40 8998-5317               |   \| __/ __\ \ / /
| (_ | ' <\__ \__ \  fax  : +49 40 8994-5317 (NEW)         | |) | _|\__ \\ V / 
 \___|_|\_\___|___/  http://www.desy.de/~utcke    (to come)|___/|___|___/ |_|

Re: Emacs Environment Variables

[Johan Bockgård]

Sven Utcke <utcke+news@informatik.uni-hamburg.de> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>
>> history-search-backward
>
> Thanks.  How do I get this bound to a key?

    # M-p
    "\ep": history-search-backward

in a readline config file*, or

    bind '"\ep": history-search-backward'

in a bash config file.

> And does it only search for lines _starting_ with the search-string

Yes.


[*] ~/.inputrc
    (info "(bashref) Sample Init File")
    bash man page, READLINE section

-- 
Johan Bockgård

Re: Emacs Environment Variables

[Peter Dyballa]

Am 30.11.2007 um 14:32 schrieb Johan Bockgård:

>     # M-p
>     "\ep": history-search-backward
>
> in a readline config file*, or
>
>     bind '"\ep": history-search-backward'
>
> in a bash config file.


Isn't this binding by default active?

--
Greetings

   Pete

A morning without coffee is like something without something else.

Re: Emacs Environment Variables

[Sven Utcke]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Sven Utcke <utcke+news@informatik.uni-hamburg.de> writes:
> 
> > bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
> >
> >> history-search-backward
> >
> > Thanks.  How do I get this bound to a key?
> 
>     # M-p
>     "\ep": history-search-backward
> 
> in a readline config file*, or

This didn't work with my bash at home, but does work with the one at work.

>     bind '"\ep": history-search-backward'
> 
> in a bash config file.

This works in both bash.  Thank you VERY MUCH!  It doesn't actually
mean that I will abandon tcsh as my interactive shell, but will mean
that in those cases where I find myself in a bash life will be a lot
less miserable (not so much because ESC-p is a must, but because it is
hardcoded into my fingers and causes grief everytime I press it.

I actually tried this before, but got the syntax wrong, using "M-p"
instead of "\ep" --- which, presumably, makes this post on topic again
:-)

THANKS

Sven
-- 
  ___ _  _____ ___   Dr.-Ing. Sven Utcke                    ___  ___ _____   __
 / __| |/ / __| __|  phone: +49 40 8998-5317               |   \| __/ __\ \ / /
| (_ | ' <\__ \__ \  fax  : +49 40 8994-5317 (NEW)         | |) | _|\__ \\ V / 
 \___|_|\_\___|___/  http://www.desy.de/~utcke    (to come)|___/|___|___/ |_|

Re: Emacs Environment Variables

[Sven Utcke]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 30.11.2007 um 14:32 schrieb Johan Bockgård:
> 
> >     # M-p
> >     "\ep": history-search-backward
> >
> > in a readline config file*, or
> >
> >     bind '"\ep": history-search-backward'
> >
> > in a bash config file.
> 
> Isn't this binding by default active?

No, by default M-p (Oh.  So that's why I got it wrong, trying M-p
rather than \ep) is bound to non-incremental-reverse-search-history

Sven
-- 
  ___ _  _____ ___   Dr.-Ing. Sven Utcke                    ___  ___ _____   __
 / __| |/ / __| __|  phone: +49 40 8998-5317               |   \| __/ __\ \ / /
| (_ | ' <\__ \__ \  fax  : +49 40 8994-5317 (NEW)         | |) | _|\__ \\ V / 
 \___|_|\_\___|___/  http://www.desy.de/~utcke    (to come)|___/|___|___/ |_|

Re: Emacs Environment Variables

[Sven Utcke]

David Kastrup <dak@gnu.org> writes:

> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
> 
> > Am 25.11.2007 um 12:36 schrieb Harald Hanche-Olsen:
> >
> >> Time to blow the dust off an old classic?
> >>
> >>   http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
> >
> > I know, since some years or decades.
> 
> "man csh" verifies that csh is still unsuitable for redirecting stdout
> and stderr to different locations.

What about "man tcsh"?

Ok, I'll admit that separating stderr from stdout is _not_ one of
tcsh's strong points either.  That nonwithstanding, I, like this
subthread's OP, use tcsh as my interactive shell and bash for
scripting, mostly because I haven't yet found a good replacement for
ESC-p (previous command starting with the substring already typed).
Bash's C-r does nearly the same, only I find it much more painful too
use.

Of course, if I were as self-confident as some others, I could simply
use !-notation, but for me this tends to run the wrong command more
often than not :-)

Sven
-- 
  ___ _  _____ ___   Dr.-Ing. Sven Utcke                    ___  ___ _____   __
 / __| |/ / __| __|  phone: +49 40 8998-5317               |   \| __/ __\ \ / /
| (_ | ' <\__ \__ \  fax  : +49 40 8994-5317 (NEW)         | |) | _|\__ \\ V / 
 \___|_|\_\___|___/  http://www.desy.de/~utcke    (to come)|___/|___|___/ |_|

Re: Emacs Environment Variables

[Peter Dyballa]

Am 25.11.2007 um 12:36 schrieb Harald Hanche-Olsen:

> Time to blow the dust off an old classic?
>
>   http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/


Is this also known?

	http://www.grymoire.com/Unix/CshTop10.txt

--
Greetings

   Pete

"America believes in education: the average professor earns more money
in a year than a professional athlete earns in a whole week." – Evan
Esar

Re: Emacs Environment Variables

[Peter Dyballa]

Am 25.11.2007 um 11:44 schrieb David Kastrup:

>> Do you know why you are so prejudiced against csh?
>
> Because it sucks for scripting and does not offer any advantage for
> interactive work when compared to modern Bourne shells?

Where can I find a Bourne shell, in which old museum?

--
Mit friedvollen Grüßen

   Pete

Diese Nachricht wurde mit einer Taschenlampe ins offene Ende eines  
Glasfaserkabels gemorst.

Re: Emacs Environment Variables

[Tim X]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 25.11.2007 um 07:18 schrieb Tim X:
>
>>> 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!)?
>
>
> For interactive use I recommend tcsh to begin with. Tcsh makes no
> complicated difference between interactive and login shells, it  confuses
> an user only when preferring an existing ~/.cshrc before  ~/.tcshrc.
>
> Do you know why you are so prejudiced against csh?
>

A shell usually has two purposes, provide an interactive
environment/interface to the system and for writing shell scripts. Csh
added some 'nice' features for interactive work, but sacrificed
considerable power in scripting. Worse yet, its behavior in some situations
is/was 'unexpected' and the ability to handle redirection was totally
crippled. Back in the late 80s/early 90s, csh had some nice features that
most other shells didn't have. These days, there is nothing in csh you
don't get in most modern shells, yet you still have the limitations and
inconsistencies when it comes to scripting that it always had (some of them
have been fixed, but some can't because of basic design issues). 

I don't want to have to know two shells, one for interactive work and one
for scripting. I want one shell thats good for both and behaves
consistently and doesn't add constraints to how I solve problems. 

All shells seem to have their own idiosyncratic bits, but csh was the worst
I've seen. I've also found that generally, when I've had issues with a
shell script I didn't write, opening it often reveals it is csh. Back when
I was learning shell scripting, I made the mistake of using csh at
first. Once I'd been stung a few times and once I saw other solutions that
were better than mine because they didn't have the same limitations, I
stopped usinig it and stuck with sh. 

The other advantage of sh is that it has high compatibility and
portability. Pretty much any sh based script will run on systems that
support sh. Many systems don't even have csh or tcsh installed. 

Many years ago, there were a couple of articles/posts concerning csh
scripting being 'hazardous' for your health. A google will probably find a
copy somewhere. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Emacs Environment Variables

[Peter Dyballa]

Am 27.11.2007 um 09:03 schrieb Tim X:

> I don't want to have to know two shells, one for interactive work  
> and one
> for scripting.


So you're boiling your eggs with a hammer?

For me it's not that complicated to write in German, English, Perl,  
awk, Bourne sh, tcsh, ksh. ELisp and French are a bit more  
complicated, I admit. A bit too complicated is definitely Bash with  
its too many modes of operation. Before I start thinking in which  
circumstances a Bash script might be used and how I could prevent  
failure, I better switch to another language that is failsafe.

--
Greetings

   Pete

Make it simple, as simple as possible but no simpler.
                               Albert Einstein

Re: Emacs Environment Variables

[David Kastrup]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 27.11.2007 um 09:03 schrieb Tim X:
>
>> I don't want to have to know two shells, one for interactive work and
>> one for scripting.
>
> So you're boiling your eggs with a hammer?
>
> For me it's not that complicated to write in German, English,

[...]

Your English writing could make do with fewer non-sequiturs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Environment Variables

[Joel J. Adamson]

David Kastrup <dak@gnu.org> writes:

> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
>
>> Am 27.11.2007 um 09:03 schrieb Tim X:
>>
>>> I don't want to have to know two shells, one for interactive work and
>>> one for scripting.
>>
>> So you're boiling your eggs with a hammer?
>>
>> For me it's not that complicated to write in German, English,
>
> [...]
>
> Your English writing could make do with fewer non-sequiturs.

One shell might be better for scripting and one for interactive use.

I switched to Z Shell because of its interactive features (it's "more
pretty"), and started scripting at the same time; now that I use Dired,
I have very limited interactive shell usage, but I still use zsh for
scripting.  Of course I use bash for any system-wide scripts or things
meant to run as root.

Joel

-- 
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA  02114
(617) 643-1432
(303) 880-3109

Re: Emacs Environment Variables

[Tim X]

jadamson@partners.org (Joel J. Adamson) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
>>
>>> Am 27.11.2007 um 09:03 schrieb Tim X:
>>>
>>>> I don't want to have to know two shells, one for interactive work and
>>>> one for scripting.
>>>
>>> So you're boiling your eggs with a hammer?
>>>
>>> For me it's not that complicated to write in German, English,
>>
>> [...]
>>
>> Your English writing could make do with fewer non-sequiturs.
>
> One shell might be better for scripting and one for interactive use.
>
> I switched to Z Shell because of its interactive features (it's "more
> pretty"), and started scripting at the same time; now that I use Dired,
> I have very limited interactive shell usage, but I still use zsh for
> scripting.  Of course I use bash for any system-wide scripts or things
> meant to run as root.

I used zsh some years back, mainly because at the time, it was thought it
would be the best shell for parallel processing environments and because
the researcher I was working with in parallel processing was also actively
contributing to its development. Its been a long time since I used it, but
back then, it was definitely one of the nicest interactive shell
environments and it had good consistency between interactive and
non-interactive (scripting) use (unlike csh).

I've thought about going back to it, but I just don't use interactive
shells that much (dired and eshell more often than not) and I've been
enjoying moving my environment to a more lisp like one, using rep, guile,
scsh and lush instead. 

Still, zsh is a shell I remember as being pleasant to use and unless the
project has gone in some weird new direction, its probably still a good
shell. Of course, I still use (ba)sh for my system scripts as I know it
will exist.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Emacs Environment Variables

[David Combs]

In article <87ejebu014.fsf@W0053328.mgh.harvard.edu>,
Joel J. Adamson <jadamson@partners.org> wrote:
...
>
>I switched to Z Shell because of its interactive features (it's "more
>pretty"), and started scripting at the same time; now that I use Dired,
>I have very limited interactive shell usage, but I still use zsh for
>scripting.  Of course I use bash for any system-wide scripts or things
>meant to run as root.

Please explain "now that I use Dired, ..."

What's it have to do with doing or not doing scripting?

Thanks!

David

Re: Emacs Environment Variables

[Tim X]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 27.11.2007 um 09:03 schrieb Tim X:
>
>> I don't want to have to know two shells, one for interactive work  and
>> one
>> for scripting.
>
>
> So you're boiling your eggs with a hammer?
>

No . Of all the cliches you possibly could have used, that one makes the
least sense of all. maybe its a language/translation issue?

> For me it's not that complicated to write in German, English, Perl,  awk,
> Bourne sh, tcsh, ksh. ELisp and French are a bit more  complicated, I
> admit. 

Well maybe your just smarter than me. I find it takes me a bit of time to
adjust when the languages don't differ significantly. I have no problems
moving from sh to perl because they are so different, but remembering
idiosyncratic differences in quoting, redirection alias definitions and
command substitution in two languages that only differ in syntactic sugar
is a pain. then again, you say you find elisp to be one of the harder ones,
yet I find lisp style languages really easy because they have such simple
and consistent syntax (knowing all the available functions is a bit harder,
but you can look those up. Inconsistencies in syntax, like do-done vs if-fi
or export-setenv are more irritating).

However, the real point is possibly better explained this
way....

I live in a world where everyone speaks english. There are also some other
languages, but everyone who speaks these other languages also speaks fluent
english. (substitute whatever language you like for 'english', it doesn't matter
as long as everyone knows it)

sometimes, I just want to communicate really simple things - "Barman, can I
have a beer" and as I know he speaks english and don't know what other
language he speaks, it makes sense for me to ask him in english. I return
to my table of friends. We are discussing the pros and cons of Marxism and
debating if he was right or wrong. All of my friends are from various parts
of the world and some of them speak other languages, but they also all
speak english and therefore I use english to communicate some of the more
complex abstract concepts and ideas I want to express. This is not a
problem - I have the necessary expressive power.

In this world, why would I want'need to learn another language. I might do
it for fun, but I certanly don't need to. Substitute bash for english and
the same holds. If I want to be really certain I'm understood, I'll stick
to sh, which is available on every Unix/Gnu Linux system I've ever
seen. I don't want to learn a language just for fun - they are
just my tools that allow me to do what I need/want to do, so I'm not
interested in learning another language - particularly one that is nearly
the same as the one I already know and doesn't provide me with any
additional expressive power (or worse, is likely to be confusing or
inconsistent because its almost the same, but not quite i.e. csh).

A bit too complicated is definitely Bash with  its too many modes of
> operation. Before I start thinking in which  circumstances a Bash script
> might be used and how I could prevent  failure, I better switch to another
> language that is failsafe.

I don't see this compicated maze of operation modes you seem to think exist
and will make your scripts break or fragile. Care to provide an example?
In fact, I'm even confused by what you mean by too many
modes. Essentially, bash has two modes - call it as 'sh' and it behaves
like the traditional bourne shell. Call it as /bin/bash and you get the
more recent or additional functionality that it has.

Are the 'modes' you refer to the distinction (ba)sh makes between
login, interactive and non-interactive shells? If so, I think your seeing
complexity where none exists. furthermore, most shells (including csh and
tcsh) also make a distinction, though it could be argued that (ba)sh goes
one step further by making a clearer distinction between login interactive
and just interactive shells. all of these shells have files that are
sourced for every shell (bashrc, cshrc etc) and login shells (bash_profile
and csh.login). It may be that the manual confuses things because the shell
has slightly different initialisation files depending on whether it is
called as sh or bash, but thats no more complex than tcsh behavior with
respect to .cshrc, .tcshrc  and .login. 

I would agree that the distinction between interactive and non-interactive
or login interactive and interactive are less important these days than
they use to be when processors were slower and memory was expensive. Back
then, you really didn't want your shell being slowed down by initialising
environment variables that were irrelevant, such as setting the prompt
variables for non-interactive shells or using up valuable scarce resources
such as memory to hold env vars you didn't need. These days, this is less
important. Whatever the case, you pretty much have only two real types,
interactive and on-interactive. In 20 years of writing shell scripts, I've
not run into any complications in this area using sh or bash.

Lets see some examples of these problems you refer to that arise from this
complexity of modes and maybe an explination of what these modes are you
refer to.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Emacs Environment Variables

[Tim X]

Ismael Valladolid Torres <ivalladt@ono.com> writes:

> Peter Dyballa escribe:
>> Do you start bash in a way that it executes your .bashrc?
>
> 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.
>

Actually, I think the issue isn't so much that its not run from a bash/sh
session, but rather the parent process was not a login session and running
from a menu option isn't interpreted as an interactive bash shell. 

> 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.
>

However, you need to keep a couple of things in mind when adding
environment variables to /etc/environment. 

1. This file is sourced by *all* processes when they start, not just a
specific users processes. If you put something like

HOME=/path/to/my/home/directory

this could cause all sorts of problems for other users or system processes
that have/expect $HOME to point somewhere else (or at least somewhere the
process has access to.

2. This file is sourced before any login or shell init files, which means
anything set here may be over written, possibly a good thing or a bad thing
and definitely a possible gotcha when trying to debug a problem. 

I think its a good idea only to put things in this file which are common to
all processes - possibly things like locale settings. 

There are a number of ways to resolve the issue of programs started from a
wm menu inheriting user environment variables. One of the simplest is to
just change your Xsession to run as a login shell. As this is the parent
session, all exported environment variables will be inherited by all
processes you start while in X regardless of whether they are from a wm
menu, an xterm or some other 'launcher'. How you do this depends on the
way you start X. I have my system boot into X and run gdm. For me, it would
be as easy as changing /etc/gdm/Xsession to be a login shell rather than a
non-interactive sh shell (I'm on Debian). 

some window managers allow you to tick a box when defining a menu entry
that essentially makes the process that will execute the menu item source
the users init files, such as .bash_profile or .profile. If you can't do
this with your wm, you can just make a simple wrapper script that sources
your init files and then exec's emacs. Finally, you can create your own
.xsession file and just have it source your init files. 

HTH

Tim





-- 
tcross (at) rapttech dot com dot au