Command not Found & Proper way to cwd

[ascorbic-acid]

hello thanks for this tool i just started with it, i want know what is the best way to start in a specific dir like other tools "cwd",

now im doing like this in a helper function "run_cmd":

run(f"cd {cwd}; {cmd}")
run(f"cd {cwd}; bash -c '{cmd}'")  # or this

also one command "yarn" which is installed using nvm -> npm . i tried doing the following but same issue (maybe other profile need to be sourced?) but i dont know the issue since when i login with ssh via terminal it work:

    cmd = await run_cmd("source ~/.bashrc; source ~/.profile; yarn")

which yarn
 /home/ubuntu/.nvm/versions/node/v20.19.0/bin/yarn

[ronf]

You're on the right track here -- AsyncSSH and other implementations like OpenSSH don't really know or care at all about current working directory on a remote system, at least not when starting a shell or exec session. About the only time the working directory impacts SSH is when running SFTP. If you're running commands, it all comes down to telling the remote shell that's launched to change directory and then execute whatever command you want to run. If things get more complicated, you can always build all of this into a shell script that you place on the remote system and have your SSH command just execute that shell script. That lets you do things like conditionals or other multi-line gestures more easily.

As for what startup files get run when starting a remote shell, that tends to vary based on the shell you are using and whether you ask SSH to launch an interactive shell or execute a command. Since you're doing the latter here and you mention bash, my experience is that bash will automatically source your ~/.bashrc in that case, but only source ~/.bash_profile (and NOT .bashrc) when starting an interactive shell. This is why you'll sometime see ~/.bash_profile end with sourcing ~/.bashrc itself.

If you need something from a startup file other than ~/.bashrc, you will probably need to source it yourself before running the command (like you show above).

[ascorbic-acid]

thansk for your answer glad to know that im on right track, about the command not found issue for packages of nvm npm the following solve it for now since sourcing bashrc or profile did not work> thanks again

   # this allow you to run any npm cli package
    cmd = await run_cmd("source ~/.nvm/nvm.sh; yarn --version")  # 1.22.22

[ronf]

Glad you figured out the issue...

Does your ~/.bash_profile happen to contain a "source ~/.nvm/nvm.sh" command in it? If so, that would explain things. When running commands over SSH, ~/.bash_profile won't be automatically sourced, and so that'll also fail to source anything it runs or set any environment variables it sets. However, if you were to SSH to the machine without specifying a command, that would drop you into an interactive bash where ~/.bash_profile WAS sourced.

[ascorbic-acid]

thanks for your follow up, In my system Ubuntu 24.04 i dont have .bash_profile but just two files .bashrc and .profile.
The strange thing is when i ssh to the remote server i can use yarn command and when i comment the following from bashrc yarn stop working which confirm that bashrc is the one responsible however even doing "source ~/.bashrc; source ~/.profile; yarn" with asyncssh did not work.

# this is .bashrc file
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Later i found solution in this link , it is about disabling interactive shell which did work for me however i will just use the first workaround for now since i dont know the consequences of commenting out that part from my bashrc

# top of .bashrc file

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Reference:
nvm-sh/nvm#2847 (comment)

[ronf]

Yeah - I was going to suggest looking for early "return" statements. That's a common pattern in shell startup scripts.

Just as it's often wise to use full pathnames when running remote commands (to avoid depending on what's in PATH), it doesn't hurt to also explicitly set other environment variables you need, or source scripts like this that do that for you. That way, future changes to your .bashrc are less likely to break things.

The other option to consider is to move the NVM-specific parts of what's in your .bashrc to run earlier, before the "return at the top of your .bashrc, making it sure it always runs. You'd just want to double-check that in the interactive case it doesn't end up somehow setting things twice.