1

I'm experiencing a strange behavior when I try to execute one of my scripts on a remote machine via ssh.

I prepend the path to my scripts dir to $PATH in my .profile. But when I run ssh kalle@Raspi foo, I get "command not found".

ssh kalle@Raspi 'echo $PATH' gives the default value, and with variables I set and export in .profile, the output is empty.

I put an echo foo in .profile, and of course, it is printed. Then I put set -vx in the first line and the order of the printed lines is weird; e. g. "foo" is printed before "+echo foo".

Can anyone figure out what's going on?

EDIT:

When I do ssh kalle@Raspi 'bash -lc "echo \$PATH"', I get my full path.

EDIT 2:

I'm sorry for the confusion, I was very tired when I wanted to run my remote script and now my memory was wrong, but I remember now what I did.

I tried with bash -lc after it didn't work with the mere command, but I missed the backslash! So I had ssh kalle@Raspi 'bash -lc "echo $PATH"' and as always when you give a command string to another command, the shell performs its various expansions on that command string.

So after quote removal, we have bash -lc "echo $PATH" which is passed to ssh as a single argument and executed on the remote machine, where the shell performs parameter substitution, i. e. $PATH is replaced by the default path before it is passed to bash -lc, making the latter useless.

And then I was stupid enough to forget that I was using bash -lc, so I thought ssh kalle@Raspi foo would cause .profile to be read because I saw the output of my echo command I had put in my .profile.

What a shame. I must have been really tired because when I wrote this question, it was absolutely natural to me that I have to protect the variable with a backslash; I didn't even have to think about it. But I still didn't realise what I realised now.

So the behavior is pretty clear and absolutely normal, but the problem remains.

I can use bash -lc as a workaround which – depending on the situation – can be a hassle with quoting and escaping, or I can put . .profile before the actual command.

Does anybody know a solution that is more elegant? Something I can adjust on the server so I can just use ssh kalle@Raspi foo?

Improve this question
7
  • 1
    The issue is that the remote shell started by SSH is a non-login shell, which doesn't read your .profile file. You can force Bash to start a login shell by passing the -l option to Bash, like this: ssh kalle@Raspi 'bash -lc "echo \$PATH"'. Alternatively, you can move your path modifications to the .bashrc file and make sure that your .bash_profile file sources your .bashrc file. Commented Apr 4, 2023 at 7:13
  • @kuspia: 1) But my .profile IS executed as my "echo" test has proven. However, it seems it isn't sourced. 2) My fried, I know that. You don't need to copy things from my question; I know what I've written ;) 3) I don't have a .bash_profile since it has no benefit over .profile if Bash is the only shell you use, as in my case. Read the section "INVOCATION" of the Bash manual. Commented Apr 4, 2023 at 15:06
  • @kuspia: I'm sorry, you're right. .profile is NOT executed. I just tested it. Commented Apr 4, 2023 at 15:43
  • 1
    @terdon, .bashrc is read by ssh user@host 'foo bar' (Bash startup files / Invoked by remote shell daemon) Commented Apr 4, 2023 at 17:22
  • @ilkkachu dammit, I keep forgetting that, thanks! But in many (most?) Linux systems, it will exit immediately because of the things explained in that question. So yes, you're right, it is read, but because of the [ -z "$PS1" ] && return or equivalent, anything that isn't at the very beginning of the file will not be read. This is why it's confusing if you add say echo foo to your ~/.bashrc and then ssh localhost hostname, you just get the host name and no foo. Commented Apr 4, 2023 at 17:35

1 Answer 1

Reset to default
0

Thanks to @ilkkachu, I found a solution.

I moved the variables stuff from .profile to a separate script which I source from within .profile.

Then, I modified the "If not running interactively, don't do anything" part in .bashrc as follows:

case $- in
    *i*) ;;
      *)
        # Not running interactively.
        # Check if we are the server of an SSH connection without a PTY.
        # If so, sshd is about to execute a command issued by some client,
        # in which case this script has been invoked directly by sshd, not
        # by .profile, so we need to set vars that are normally set in .profile
        # and that are important for my scripts (like $PATH) here before returning.
        # This way, I can call my scripts just via ‘ssh kalle@Raspi foo’ without
        # using ‘bash -lc’.
        #
        # References:
        # https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html
        # https://man.openbsd.org/ssh#ENVIRONMENT

        [[ $SSH_CONNECTION && -z $SSH_TTY ]] && . $HOME/scripts/bashrc-include/set-vars.sh
        return;;
esac

EDIT:

Not quite unimportant: Prove that it works without side effects.

I placed echoes at the head of .profile, .bashrc and set-vars.sh, and another echo after the case ... in ... esac above.

I should mention that I'm using the same .profile and .bashrc on all my machines.

So, let's test it:

When I open a terminal on the machine I'm writing this, I get:

.profile: Started.
set-vars.sh: Setting vars.
.bashrc: Started.
.bashrc: Interactive shell, proceeding.

When I ssh into my Raspi, I get exactly the same.

When I issue ssh kalle@Raspi 'echo $PATH', I get:

.bashrc: Started.
set-vars.sh: Setting vars.

and the correct $PATH.

EDIT 2:

A small script to switch the messages on and off:

#!/bin/bash

# Author: derkallevombau
# Created 2023-04-07 12:58:48

if [[ $1 =~ ^on|1|true$ ]]; then
    sedScript='"s/^#([\t ]*echo $(basename $f):.*)/\1/"'
elif [[ $1 =~ ^off|0|false$ ]]; then
    sedScript='"s/^([\t ]*echo $(basename $f):.*)/#\1/"'
else
    cat <<-END
        Unknown argument: '$1'.

        Invocation: bash-startup-messages-set (on|1|true)|(off|0|false)
    END

    exit
fi

for f in ~/.{profile,bashrc} /home/kalle/scripts/bashrc-include/set-vars.sh; do
    eval sed -Ei $sedScript $f
done
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.