[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3

From: Ralph Corderoy
Subject: Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3
Date: Sat, 26 Aug 2017 10:18:26 +0100

Hi Kevin,

>     % printenv SHELL
>     /bin/tcsh
>     % $SHELL -c "cd&&pwd"
>     localuser:kevinc being removed from access control list /home/kevinc
>     %

The xhost(1) command is modifying the X server it connects to.  Doesn't
that mean it can be done just once, in ~/.xinitrc, or similar, rather
than be a per shell thing?

And then if it must remain per shell, there's login shells and non-login
shells.  Your tcsh(1) takes `-l' to tell it it's a login shell, or it
looks at the first character of argv[0] when it's execve(2)'d to see if
it's a `-', e.g. it's run as `-tcsh'.  Both of these will show up in `ps
ww' output.  Things like xterm(1) can be configured to kick off a login
shell for each terminal window.

If tcsh is a login shell then ~/.login is source'd, and that's where you
say the xhost command is, but Ken's `$SHELL -c' above shouldn't be a
login shell, and thus .login isn't source'd and xhost shouldn't be run.
Unless, you're manually source-ing .login from ~/.tcshrc, or ~/.cshrc if
you don't have the tcsh-specific one.  Don't do that.  :-)  They're
different for a reason.

If you have strace(1) then one way to see what files are being accessed

    strace -fe open,execve $SHELL -c /bin/true

Most of them will be shared libraries loaded as part of starting the
executable, tcsh or true.  Or, you can start monitoring activity on
files of interest that exist with

    ls /etc/csh.cshrc /etc/csh.login ~/.tcshrc ~/.cshrc ~/.history \
        ~/.login ~/.cshdirs 2>/dev/null |
    xargs -r inotifywait -m

That's sh, you might need to join lines for tcsh.  Whilst that's
running, do `$SHELL -c /bin/true' elsewhere.

Cheers, Ralph.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]