Bash: Difference Between "Export K=1" VS. "K=1"

BASH: difference between export k=1 vs. k=1

Every process, even on Windows, has a block of memory known as the environment block, this contains environment variables. When a new process is created, by default, the environment block of the parent process is copied to the child, so environment variables are a simple way of passing text data to a child process.

The export command creates an environment variable, or converts an ordinary local variable into an environment variable. In the C-shell, one of its few redeeming features is that it uses a different syntax for environment variables (setenv) to local variables (set). Bourne shell derivatives, like Bash and Korn shell, hide all that.

Currently, only simple values can be passed, so items like arrays are not supported (it just exports the first element). Variable attributes, set using define, are also not exported unless the child process is a shell of the same type, i.e. another instance of bash. This also applies to exported functions, although it is possible to sometimes hack this between shells of different types (using eval).

In Bash (and others) there is a shell setting called allexport which means all variables are environment variables - probably a bad idea to se generally. You can supply a different environemnt block from languages like C using execve, but from the shell you need a program like env, see man env for details.

Defining a variable with or without export

export makes the variable available to sub-processes.

That is,

export name=value

means that the variable name is available to any process you run from that shell process. If you want a process to make use of this variable, use export, and run the process from that shell.

name=value

means the variable scope is restricted to the shell, and is not available to any other process. You would use this for (say) loop variables, temporary variables etc.

It's important to note that exporting a variable doesn't make it available to parent processes. That is, specifying and exporting a variable in a spawned process doesn't make it available in the process that launched it.

What's the difference of the command output after inputting the command env, export, set under Bash Shell in Solaris?

The env and export commands yield the same information, but not in the same format. And bash's export produces a very radically different output from the output of ksh or (Bourne) shell's version. Note that set and export are shell built-in commands, but env is an external command that has other uses than just listing the content of the environment (though that is one of its uses).

The set command lists the variables you've created. This includes environment variables, regular (non-environment) variables, and function definitions (which we'll ignore here).

Consider:

x1=abc
x2=def; export x2
export x3=ghi

There are two exported variables (x2 and x3), and one regular (non-exported) variable. The set command will list all three; export and env will only list the exported ones.

The output of the env command is mandated by the POSIX standard. This is simply the variable name and value followed by a newline:

name=value

Classically, the Bourne shell simply listed variables the same way for both set and export.

Korn shell encloses values in quotes if the value contains spaces or other characters that need protection, but otherwise uses the name=value notation.

The set command in bash generates assignments with the value protected in quotes. However, the output for export is a declare -x var=value with quote protection. The general idea is presumably that you can use export > file followed by source file to reset the environment variables to the values that were in the environment at the time you did the export.

---

Summary

1. Not all shell variables are environment variables.
2. The set command lists all shell variables and may list functions too.
3. The export command lists environment variables.
4. The set and export commands are built into the shell.
5. The env command with no arguments lists the environment it inherited from the process that executed it.

Bash export in a script; To next script?

you could source your script like...

 #source ./env1.sh; echo Next command:$TEST
 . ./env1.sh; echo Next command:$TEST

As @Jonathon pointed out in the comments Using the . in place of source is more portable.

In fact, if you use this method you don't even need to export the variable.

Just be careful with your variable names when doing this. Even though this is what you want, you are polluting your environment.

I'm not sure what the purpose of the script is, but I tend to avoid eval if ever possible. This modified script would achieve the same result, but again, I don't know what you are trying to do with this.

#!/bin/bash

#myExports="TEST='Value 1';export TEST;";

echo Before eval: $TEST
echo '***'

TEST='Value 1'; export TEST
#eval $myExports

echo After eval: $TEST
echo '***'

What does the 'export' command do?

export in sh and related shells (such as Bash), marks an environment variable to be exported to child-processes, so that the child inherits them.

export is defined in POSIX:

The shell shall give the export attribute to the variables corresponding to the specified names, which shall cause them to be in the environment of subsequently executed commands. If the name of a variable is followed by = word, then the value of that variable shall be set to word.

Sorting two files that have the same column gives different sorting

Add spaces:

$ sort -k 1,1 /tmp/2
rs1010735 C
rs10108  C
rs1010805 T
rs1010863 T
rs1010891 T
rs1010910 A
rs1011124 A
$ sort -k 1,1 /tmp/1
rs1010735   224915429
rs10108     114516330
rs1010805   38189142
rs1010863   185432942
rs1010891   110712154
rs1010910   61212213
rs1011124   7533164

What does export do in shell programming?

Exported variables such as $HOME and $PATH are available to (inherited by) other programs run by the shell that exports them (and the programs run by those other programs, and so on) as environment variables. Regular (non-exported) variables are not available to other programs.

$ env | grep '^variable='
$                                 # No environment variable called variable
$ variable=Hello                  # Create local (non-exported) variable with value
$ env | grep '^variable='
$                                 # Still no environment variable called variable
$ export variable                 # Mark variable for export to child processes
$ env | grep '^variable='
variable=Hello
$
$ export other_variable=Goodbye   # create and initialize exported variable
$ env | grep '^other_variable='
other_variable=Goodbye
$

For more information, see the entry for the export builtin in the GNU Bash manual, and also the sections on command execution environment and environment.

Note that non-exported variables will be available to subshells run via ( ... ) and similar notations because those subshells are direct clones of the main shell:

$ othervar=present
$ (echo $othervar; echo $variable; variable=elephant; echo $variable)
present
Hello
elephant
$ echo $variable
Hello
$

The subshell can change its own copy of any variable, exported or not, and may affect the values seen by the processes it runs, but the subshell's changes cannot affect the variable in the parent shell, of course.

Some information about subshells can be found under command grouping and command execution environment in the Bash manual.

---

Related Topics