`git clone` fails with error message

Help
1

git status/git log work. I can do most things with magit, which of course uses git under the hood.

I get this strange error with git clone alone out of all the things I’ve tried.

Cloning into '<reponame>'...
Shell "bash" is not executable: No such file or directory

Someone on SO said this could be the result of a broken symlink. I think I can check that with find -lname

sudo find -lname /nix/store/myb1cc4kn3n3rwqg44406wdsq8v2ihdq-git-2.38.3/bin/git didn’t return anything.

Any ideas what to try next?

2

Fyi I updated the channel and rebuilt. Same problem.

3

Are you using bash as your primary/login shell? Do you have it installed at all? Can you run bash regularly? What is your SHELL env variable?

4

Yes, I am executing all commands inside bash.

my user shell is bash. echo $SHELL returns bash. etc.

5

Does this repo have any kool kid hooks or shell scripts the run post/pre clone.

https://pre-commit.com/#automatically-enabling-pre-commit-on-repositories

double check, i got a feeling that there is some script running somewhere… and nix can’t find a shell to run it.

wild guess.

6

It shouldn’t say bash, it should say /run/current-system/sw/bin/bash or another absolute path.

You might also want to try git clone --verbose --progress …

Last but not least, never check environment variables using echo $var use printenv var instead! Shouldn’t make much of a difference here though.

In general I assume though, that the SHELL variable is not an issue here. After re-reading, I am wondering, does this happen for all repos or just some? If the latter, which? Do you use HTTPS or SSH? Have you tried another protocol?

edit:

I just ran the following, by default git clone doesn’t seem to do anything bash/shell/PATH related… (I added zsh just in case it picks my default shell by accident by other means)

strace git clone --verbose --progress git@github.com:NobbZ/nixos-config.git 2>&1 | rg 'PATH|bash|zsh|SHELL'

There was no meaningful output, that would somehow help us here…

7

no kool kid hooks or shell scripts that run post/pre clone afaik.

but you might be onto something: my private key is password encrypted, and I don’t see the prompt I would expect to enter the password.

8

I ran the command with strace + --verbose --progress.

https://pastebin.com/ZmjkM1HT

I forgot to mention that my private key is password encrypted, and I don’t see the prompt I would expect to enter my password.

9

So it might be SSH failing? Can you use that key to connect to the server as the git user?

Can you use HTTPS based URLs?

Do you have similar problems when pushing to already cloned repos using the same key?

Can you try to use an agent temporarily?

10

I tried cloning the HTTPS URL a minute ago and it failed to authenticate. :confused:

I did, however, receive the prompts I expected.

So it might be SSH failing? Can you use that key to connect to the server as the git user?

Good guess!!

$ ssh -T git@github.com
Shell "bash" is not executable: No such file or directory

Running strace on that command shows this


access("bash", X_OK)                    = -1 ENOENT (No such file or directory)
getpid()                                = 18868
write(2, "Shell \"bash\" is not executable: "..., 59Shell "bash" is not executable: No such file or directory
11

git appears to be unable to push or pull changes with repos I had previously cloned.

12

I’m still dealing with this issue. Not sure what to do.

13

Is there any way to force openssh to rebuild when I run sudo nixos-rebuild switch?

14

it looks like the problem is that ssh is trying to access bash without the full path e.g.

access("/run/current-system/sw/bin/bash", X_OK) = 0

I ran ssh -T git@github.com as root and it worked fine, and that’s why.

I wonder why ssh is not using the full path when I run as a normal user?

15

It looks like ssh uses the SHELL environment variable to execute bash. It appears that defaults to the absolute path of the bash symlink in nixos.

It was set like this in my .bashrc

SHELL="bash"

:grimacing:

16

As you did not further comment on this I assumed you just abbreviated…

Never do that! On no OS. SHELL should always reflect the shell that is also specified in /etc/passwd.

It should also always be an absolute path.

And it should always be pre-populated by the system.

1 Like
17

Never do that! On no OS.

Really? I added that line years ago and it just this week gave me problems.

I wish I could remember exactly why I did it. Maybe the fetch program looked subpar with the full path, or maybe it wasn’t being set correctly when using another shell (elvish).

Something along those lines.

18

`Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

Doug Gwyn, in Introducing Regular Expressions (2012) by Michael Fitzgerald`

19

I can live with that. I do stupid things all the time.

1 Like
20

,me too, but now i can roll back :wink: .