Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.development.system > #437

Re: shell init files

Path csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups comp.os.linux.development.system
Subject Re: shell init files
Date Wed, 06 Jun 2012 21:17:51 +0100
Lines 63
Message-ID <871ulschzk.fsf@sapphire.mobileactivedefense.com> (permalink)
References <8bb99d54-c1e4-4c96-9c48-d0cd3d6eeb50@6g2000vbv.googlegroups.com> <87lik8ebbd.fsf@sapphire.mobileactivedefense.com> <slrnjsfp8t.rk7.grahn+nntp@frailea.sa.invalid> <alpine.DEB.2.00.1206010108020.20490@login01.caesar.elte.hu> <87y5o7hxl8.fsf@sapphire.mobileactivedefense.com> <slrnjsq9pf.rk7.grahn+nntp@frailea.sa.invalid> <alpine.DEB.2.00.1206050025070.29285@login01.caesar.elte.hu> <slrnjsrbai.rk7.grahn+nntp@frailea.sa.invalid> <87wr3lvote.fsf@sapphire.mobileactivedefense.com> <slrnjstvpe.rk7.grahn+nntp@frailea.sa.invalid> <alpine.DEB.2.00.1206061817180.24575@login01.caesar.elte.hu> <87aa0gcpr3.fsf_-_@sapphire.mobileactivedefense.com> <alpine.DEB.2.00.1206062111380.30955@login01.caesar.elte.hu>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Trace individual.net sjrCKqaFjoIxvtG0N4DbzwVpTXe9YWuX+uNMXYo0CvX7jud9SSQKkdHMx9Qj9D4VE=
Cancel-Lock sha1:AoWskFXz0lODqk1f8umIhnCW3RE= sha1:hDt9kNuvKM0wZSCd5MRGd1nKzSs=
User-Agent Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref csiph.com comp.os.linux.development.system:437

Show key headers only | View raw


"Ersek, Laszlo" <lacos@caesar.elte.hu> writes:
> On Wed, 6 Jun 2012, Rainer Weikusat wrote:
>
>> "Ersek, Laszlo" <lacos@caesar.elte.hu> writes:
>>> On Wed, 6 Jun 2012, Jorgen Grahn wrote:
>>>>  ssh user@host simulator args ...
>>>
>>> What I have to keep in mind for commands like this is to modify
>>> ~/.bashrc, not ~/.bash_profile, on the remote end.
>>
>> Considering way this is meant to be used, that's exactly the wrong
>> choice. The profile-file is supposed to be used for per-session
>> settings which need to be configured once and will then be inherited
>> by all future processes created from this shell and 'resource limits'
>> are parameters with this property. The purpose of .bashrc, OTOH, is
>> to configure an interactive shell environment according to the
>> preferences of some user, eg, to define aliases or special prompts.
>
> http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html
> http://www.gnu.org/software/bash/manual/html_node/What-is-an-Interactive-Shell_003f.html
>
> I care about the following use cases:
>
> (1) Interactive login shell. Covers "ssh user@host".
>
> Bash runs ~/.bash_profile, which, following the docs linked above, on
> both Debian and RHEL, includes ~/.bashrc.
>
> (2) Interactive non-login shell. Covers starting an xterm from my
> window manager, for example.
>
> Bash reads ~/.bashrc.

*If* there is no parent login shell, the one started by the terminal
 emulator should be one, eg, using the xterm -ls option.

> (3) Invoked by remote shell daemon. Coves "ssh user@host command".
>
> Bash reads ~/.bashrc.

It shouldn't, however, since it isn't interactive, according to its
own documentation (it was invoked with a non-option argument and its
input and error output are not connected to a tty).

> Putting my stuff (like extending PATH with something under $HOME) in
> ~/.bashrc just works.

That's besides the point.

[...]

> (2) breaks, because there may be no interactive login shell between
> init - 
> X display manager - X window manager - xterm. There's simply no
> process to inherit those settings from. Normally one has to hack xdm
> config files (a pain) or .desktop files for gdm (utter pain).

Another easy way to get around this is to log into a VT and start X
'on demand' (if there is a demand).

NB: I didn't claim that the originally intended division of concerns
would be pratically useful on 'really existing systems', actually, I
wrote that it likely wouldn't.

Back to comp.os.linux.development.system | Previous | NextPrevious in thread | Find similar


Thread

Starting an application from GDB prompt Hari Prasath <gehariprasath@gmail.com> - 2012-05-30 15:55 -0700
  Re: Starting an application from GDB prompt Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-05-31 14:20 +0100
    Core dumps (was Re: Starting an application from GDB prompt) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-31 21:39 +0000
      Re: Core dumps (was Re: Starting an application from GDB prompt) "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-06-01 01:14 +0200
        Re: Core dumps (was Re: Starting an application from GDB prompt) "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-06-01 01:44 +0200
        Re: Core dumps Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-06-01 16:16 +0100
          Re: Core dumps Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-04 21:22 +0000
            Re: Core dumps "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-06-05 00:29 +0200
              Re: Core dumps Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-05 06:55 +0000
                Re: Core dumps Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-06-05 15:03 +0100
                Re: Core dumps Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-06 06:56 +0000
                Re: Core dumps "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-06-06 18:25 +0200
                shell init files (was: Core dumps) Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-06-06 18:30 +0100
                Re: shell init files (was: Core dumps) "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-06-06 21:45 +0200
                Re: shell init files Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-06-06 21:17 +0100

csiph-web