Reputation: 1387
I have this following shell script (test.sh)
#!/bin/bash
. /home/detail/env3/bin/activate
But when I execute it via sh test.sh
, it returns an error:
test.sh: 2: .: Can't open /home/detail/env3/bin/activate
All permissions are set to 777. Can anyone help — what's wrong?
Result of ls -l /home/detail/env3/bin/activate
-rwxrwxrwx 1 detail detail 2076 Aug 14 10:49 /home/detail/env3/bin/activate
Upvotes: 0
Views: 5042
Reputation: 755044
On an (antique) RHEL 5 Linux box, I created a file xyz.sh
with a CRLF line ending on the only line;
0x0000: 2E 20 70 71 72 2E 73 68 0D 0A . pqr.sh..
0x000A:
I created a file pqr.sh
with regular Unix line endings:
echo $0 at work
I tried to run the first script with sh
:
$ sh xyz.sh
: No such file or directory
$ bash xyz.sh
xyz.sh: line 1: .: $'pqr.sh\r': file not found
$
When I run that through a hex dump program, I get:
$ sh xyz.sh 2>&1 | xxd -g 1
0000000: 78 79 7a 2e 73 68 3a 20 6c 69 6e 65 20 31 3a 20 xyz.sh: line 1:
0000010: 70 71 72 2e 73 68 0d 3a 20 4e 6f 20 73 75 63 68 pqr.sh.: No such
0000020: 20 66 69 6c 65 20 6f 72 20 64 69 72 65 63 74 6f file or directo
0000030: 72 79 0a ry.
$
When I eliminate the CR from xyz.sh
and run it, I get:
$ sh xyz.sh
xyz.sh at work
$
Given this experimentation, I deduce that the problem in the question probably arises because the file test.sh
has CRLF line endings, so when the shell processes it, it is trying to open a file $'/home/detail/env3/bin/activate\r'
in the Bash notation. The error message also suggests that the shell in /bin/sh
is not actually Bash (or Bash has changed its error messages over time). Running sh --version
might or might not be informative.
You could prove the CRLF problem with:
$ file xyz.sh
xyz.sh: ASCII text, with CRLF line terminators
$
except you'd specify test.sh
. You can convert the file to Unix line endings using vim
and :set fileformat=unix
before writing the file back to disk:
$ file xyz.sh
xyz.sh: ASCII text
$
This testing says nothing about whether the file in /home/detail
has CRLF (DOS-style) line endings; the shell isn't getting as far as reading that file yet.
FWIW: dash
0.5.9 running on a Mac (running macOS Mojave 10.14.6) produces yet another error message:
$ dash xyz.sh
: not found.: pqr.sh
$ dash xyz.sh 2>&1 | xxd -g 1
00000000: 78 79 7a 2e 73 68 3a 20 31 3a 20 2e 3a 20 70 71 xyz.sh: 1: .: pq
00000010: 72 2e 73 68 0d 3a 20 6e 6f 74 20 66 6f 75 6e 64 r.sh.: not found
00000020: 0a
$
Similarly, ksh
produces:
$ ksh xyz.sh
: cannot open [No such file or directory]
$ ksh xyz.sh 2>&1 | xxd -g 1
00000000: 78 79 7a 2e 73 68 5b 31 5d 3a 20 2e 3a 20 70 71 xyz.sh[1]: .: pq
00000010: 72 2e 73 68 0d 3a 20 63 61 6e 6e 6f 74 20 6f 70 r.sh.: cannot op
00000020: 65 6e 20 5b 4e 6f 20 73 75 63 68 20 66 69 6c 65 en [No such file
00000030: 20 6f 72 20 64 69 72 65 63 74 6f 72 79 5d 0a or directory].
$
All this suggests that the shell in /bin/sh
on the OP's machine is not Bash, Dash or Ksh.
Upvotes: 2
Reputation: 42541
On my linux machine I've created two files in /tmp/test1 folder to simulate your situation:
// hello.sh
#!/bin/bash
echo 'hello'
and
#!/bin/bash
. /tmp/test1/hello.sh
I've done chmod 755
on both files and run test.sh
:
mark@whatever@/tmp/test1# ./test.sh
I do see that it outputs hello
so the possible reason is:
Lack of permissions. On one of folders /home
, /home/detail
, /home/detail/env3
...
Upvotes: 0