31

Is there any sh code that is not syntactically valid bash code (won't barf on syntax)?

I am thinking of overwriting sh with bash for certain commands.

Improve this question
12
  • 1
    I guess by valid I meant syntactically valid, so it won't barf on syntax
    – Alexander Mills
    May 11, 2018 at 6:01
  • 2
    Different tokenizing? e.g. (( comes to mind.
    – ccorn
    May 11, 2018 at 16:00
  • 1
    For some distros /usr/bin/sh is just a sym-link to /usr/bin/bash (I'm using CentOS 7.3 and it is). You should check to see if sh is really bash for your distro.
    – Centimane
    May 11, 2018 at 16:41
  • 1
    A few years ago, my whole project broke when something was "upgraded" in bash. I had to change all my shebang lines from #!/bin/sh to #!/bin/bash. Then everything worked again, so you do really have to be careful. It may have happened when they started using dash instead of bash for sh.
    – Joe
    May 11, 2018 at 23:43
  • 2
    @Joe, that's the opposite of what the OP is asking for -- you had bash code that was mislabeled as being sh code but wasn't. The OP is asking if they can have (actual, not mislabeled) sh code that breaks when it runs with bash, not if they can have bash code that breaks when it runs with sh (which is obvious -- if bash extensions didn't have any effect on available language features, they wouldn't be extensions).
    – Charles Duffy
    May 12, 2018 at 20:01

2 Answers 2

Reset to default
48

Here is some code that does something different in POSIX sh and Bash:

hello &> world

Whether that is "invalid" for you I don't know.

In Bash, it redirects both standard output and standard error from hello into the file world. In POSIX sh, it runs hello in the background and then makes an empty redirection into world, truncating it (i.e. it's treated as & >).

There are plenty of other cases where Bash extensions will do their thing when run under bash, and would have different effects in a pure POSIX sh. For example, brace expansion is another, and it too operates the same under Bash's POSIX mode and not.

As far as static syntax errors go, Bash has both reserved words (like [[ and time) not specified by POSIX, such that [[ x is valid POSIX shell code but a Bash syntax error, and a history of various POSIX incompatibility bugs that may result in syntax errors, such as the one from this question:

x=$(cat <<'EOF'
`
EOF
)
bash: line 2: unexpected EOF while looking for matching ``'
bash: line 5: syntax error: unexpected end of file

Syntax-errors-only is a pretty dangerous definition of "invalid" for any circumstance where it matters, but there it is.

Improve this answer
9
16

A short example:

time()(:)

time in Bash is a reserved word, and behaves differently from the time program. It's quite likely you'll break some practical scripts trying to parse the result of time by using bash. But technically it is not a syntax error. Redefining time as a function would be rare but causes a syntax error as this question specifies.

A shorter example:

a():

Valid in dash, but not POSIX compliant.

Improve this answer
1
  • 3
    More generally, any word that is a nonstandard keyword or a builtin command in Bash will cause the same effect. In addition to time, there's stuff like declare, function, select, and coproc. Though some of those are explicitly marked as unspecified in the standard (keywords and builtins/utilities), but I can't see e.g. time or coproc in the list. And using --posix doesn't seem to help.
    – ilkkachu
    May 11, 2018 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .