david wrote:
[]
To continue the example with rsync, if I do something like this:
% #rsync -avz --inplace --progress --stats --rsh=ssh /directory
2nd.local:/directory
then the rsync used on 2nd is /usr/bin/rsync rather than /sw/bin/rsync.
On the other hand, if I manually invoke rsync on 2nd, since /sw/bin is
before /usr/bin in the $PATH, /sw/bin/rsync is used.
So this is now a question on how ssh executes remote commands; quite
another can of worms.
As far as I can tell the reason for this is that when I use rsync from
1st it invokes a non-interactive shell on 2nd. Furthermore, I don't use
No, it runs rsync as a remote command through ssh. This command is run
inside an interactive shell, but with its own ssh-homegrown login
substitute. If you want to "fix" only this use of rsync, you can put
--rsync-path=/sw/bin/rsync
on the command line.
bash, I use tcsh (however, I am slowly moving to zsh but that is another
The present discussion was about bash, because this is the default now
(I myself am actually using tcsh and a very similar setup to yours).
There are big differences here between the bash setup and the tcsh one.
discussion) and tcsh reads its startup scripts in this order (if they
exist):
a. ~/.tcshrc
b. /usr/share/tcsh/examples/rc
c. /usr/share/tcsh/examples/tcsh.defaults
d. /usr/share/tcsh/examples/environment
e. ~/Library/init/tcsh/environment.mine
f. ~/Library/init/tcsh/rc.mine
g. /usr/share/tcsh/examples/aliases
h. ~/Library/init/tcsh/aliases.mine
i. /usr/share/tcsh/examples/completions
j. ~/Library/init/tcsh/completions.mine
1. ~/.login
2. /usr/share/tcsh/login
3. ~/Library/init/tcsh/path
4. ~/Library/init/tcsh/login.mine
5. /sw/bin/init.csh
everything from ~/.login and below is not read for non-interactive
...make this "non-login". Tcsh doesn't distinguish between interactive
and non-interactive as far as startup scripts are concerned.
shells. Fine, let's source /sw/bin/init.csh from e.g., (e)
environment.mine - however this breaks login-/interactive-shells because
in (2) login the following clause is included:
set path = ( \
~/bin \
/usr/local/bin /usr/bin /bin \
/usr/local/sbin /usr/sbin /sbin \
)
Actually, all the stuff in /usr/share/tcsh and in ~/Library/init is your
own private configuration (if you are on OSX 10.2 or later). By default,
tcsh reads only ~/.* and /etc/csh.*. And by default, Fink writes its
"source /sw/bin/init.csh" into ~/.cshrc or ~/.tcshrc, which would make
your rsync example work as you think it should.
The fact that in your case it doesn't work is that you (or whoever set
up your startup scripts) thought (as I do) that PATH should be set in
login shells. When Fink runs its pathsetup script, it runs a login shell
and looks whether the PATH is already set up (which is the case for
you). I then does nothing. The idea is that if you configure your own
stuff by hand, then you know what you are doing. This is a big
assumption, but the only one that conforms with Fink's non-interference
policy.
If you never fiddled with any shell startup scripts yourself, then
Fink's pathsetup script will write (for tcsh users) into ~/.tcshrc or
~/.cshrc, and this will then be executed for any shell, login or not,
and your rsync example will use /sw/bin/rsync. So Fink's default
behavior for default tcsh users is exactly what you think it should be.
For bash users, this is different, because there is no startup script
that is executed in all cases: Bash either executes /etc/bashrc and
~/.bashrc if it is interactive non-login, or (exclusive or) /etc/profile
and one of ~/.profile, ~/.bash_login, ~/.bash_profile if it is login, or
none at all if it is non-interactive non-login. If bash is used by ssh
to run a remote command, it executes /etc/bashrc and ~/.bashrc. If bash
users want the same experience as tcsh users, they can for example make
a symlink between ~/.profile and ~/.bashrc or do something equivalent as
Alex is doing by sourcing one of the two from the other one.
This has been discussed many times, and I know that some people are not
convinced, but I still think it is wrong to source /sw/bin/init.sh
automatically in every subshell. After all, you start your subshell
always inside an interactive environment, and environment variables like
PATH are meant to be transmitted to subshells, so it is sufficient to
run /sw/bin/init.sh once at startup (hence "login") of the interactive
environment in which your non-login shell is started. If you need a
different environment in your subshell, then define it there.
Do you have a link to such a discussion? I have been unable to find
them. Maybe an addition to the FAQ would be motivated?
There is even an item on the bug tracker. But for the FAQ, what would be
the question? The only one that is similar to yours and has come up
several times is about X11, and this is mentioned in item 5.16.
Anyway, how do you recommend that I set up my startup scripts so that
the right version of e.g., rsync is used in situations as the one I
described above?
There are many possibilities, but they depend on your individual setup,
and none of them could be done by Fink automatically. For example, you
can put
source ~/Library/init/tcsh/path
into your ~/.tcshrc, before you source /usr/share/tcsh/examples/rc. You
have to make sure that ~/Library/init/tcsh/path allows to be eventually
sourced twice in case of a login shell. It doesn't hurt when
/sw/bin/init.csh is called twice.
--
Martin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Fink-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-users
