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.

  • 1
    I guess by valid I meant syntactically valid, so it won't barf on syntax – Alexander Mills May 11 '18 at 6:01
  • 2
    Different tokenizing? e.g. (( comes to mind. – ccorn May 11 '18 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 '18 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 '18 at 23:43
  • 1
    @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 '18 at 20:01
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 | |
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 | |
  • 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 '18 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.