0

You can use the . command to execute commands from a shell script as if they were in the calling shell script itself.

If I use the dot command in my shell scripts, will it behave similarly across different shell interpreters?

PLEASE Note: I'm not asking about the difference between the . command and the source command. If that's what you want to learn, please see this other question: Using dot or "source" while calling another script - what is the difference?

Elifarley
  • 1,310
  • 3
  • 16
  • 23
  • See also: [Unix.SE: Source vs . why different behaviour?](https://unix.stackexchange.com/questions/309768/source-vs-why-different-behaviour) – John Kugelman Jul 16 '21 at 11:56
  • 1
    See also: [What is the difference between '.' and 'source' in shells?](https://unix.stackexchange.com/questions/58514/what-is-the-difference-between-and-source-in-shells). This one has the most comprehensive answer, by the always exhaustive Stéphane Chazelas. – John Kugelman Jul 16 '21 at 11:59
  • 1
    It will behave similarly across all shells that conform to whatever standard defines the expected behavior. A commonly accepted standard is that defined at https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_18. Many shells do not conform to that standard unless you provide specific directions. (eg `bash --posix`, or invoking bash with the name `sh`). – William Pursell Jul 16 '21 at 12:23
  • Personally, I find the "look in PATH for not-necessarily-executable files" is surprising behaviour (even [just this morning](https://unix.stackexchange.com/q/658671/4667)) but that's specified by POSIX, and at least dash, bash, ksh and zsh all work that way – glenn jackman Jul 16 '21 at 13:06

1 Answers1

0

Under certain simple shells, the dot operator doesn't behave as expected:

$ /bin/sh --help
BusyBox v1.32.1 () multi-call binary.

$ cat /tmp/dot-sh.sh
#!/bin/sh
. xxx || echo "dot worked as expected"

$ /tmp/dot-sh.sh
/tmp/dot-sh.sh: 2: .: xxx: not found

To test the example above, you can:

docker run --rm -it alpine sh

But under /bin/bash, the dot operator does behave as expected:

$ cat /tmp/dot-bash.sh
#!/bin/bash
. xxx || echo "dot worked as expected"

$ /tmp/dot-bash.sh
/tmp/dot-bash.sh: line 2: xxx: No such file or directory
dot worked as expected
Elifarley
  • 1,310
  • 3
  • 16
  • 23
  • Could you elaborate on what the difference is exactly and why bash's behavior is expected? – John Kugelman Jul 16 '21 at 12:07
  • I disagree. Aborting is the expected behavior. Bash's behavior is non-standard, unexpected, and bizarre. – William Pursell Jul 16 '21 at 12:18
  • 2
    The [POSIX spec](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot) says "If no readable file is found, a non-interactive shell shall abort; an interactive shell shall write a diagnostic message to standard error, but this condition shall not be considered a syntax error." -- `bash --posix dot-bash.sh` does indeed abort. – glenn jackman Jul 16 '21 at 13:02
  • 1
    I'm not sure I would consider `bash` bizarre, but it's definitely non-standard. (I didn't expect the shell to abort, but I was unaware of the distinction that POSIX `.` makes between interactive and non-interactive shells.) – chepner Jul 16 '21 at 14:02