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 is 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. https://plus.google.com/+RalphCorderoy _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers