Rav
Rav

Reputation: 1387

.sh file cannot open file with "." command

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

enter image description here

-rwxrwxrwx 1 detail detail 2076 Aug 14 10:49 /home/detail/env3/bin/activate

Upvotes: 0

Views: 5042

Answers (2)

Jonathan Leffler
Jonathan Leffler

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

Mark Bramnik
Mark Bramnik

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

Related Questions