Why first set a variable and then export it instead of setting and exporting in one command?

Question

If gpg-agent is executed, it outputs data that can be processed by a shell directly, e.g.:

SSH_AUTH_SOCK=/tmp/ssh-apeOFqMF3292/agent.3292; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3293; export SSH_AGENT_PID;
echo Agent pid 3293;

Why is gpg-agent doing this? I've seen more programs doing it. Did shells in the past not support export var=val? Which shells do not support this alternative shell built-in?

I'm working with bash in Kubuntu.

Just a guess but this is probably something bash supports but sh doesn't. — LawrenceC, Jun 30 '11 at 21:58
@ultra: /bin/sh is a symlink to /bin/dash on my system which supports export var=val too. What shell are you talking about? — Lekensteyn, Jun 30 '11 at 22:09

score 12 · Accepted Answer · answered Jun 30 '11 at 21:57

The traditional Bourne shell didn't support combining them (although the System V one let you omit the ;; the 4.2BSD / SunOS shell didn't). It was added by the Korn shell (crossing the Bourne shell's export with csh's setenv) and subsequently adopted by other shells and by POSIX.2. Many commercial Unixes still ship the System V variant of the Bourne shell as /bin/sh, so retaining compatibility is a good idea for portability.

score 0 · Answer 2 · answered Feb 16 '24 at 13:00

It doesn’t apply to constant strings, but a reason to get in the habit of doing this as two separate commands is that export FOO=$(mycmd) masks the exit status from mycmd — it will report success even if mycmd fails. See How is the return status of a variable assignment determined? and the ShellCheck Wiki.

Why first set a variable and then export it instead of setting and exporting in one command?

2 Answers2