This has nothing to do with foreground and background processes; it only has to do with the currently running process. When the kernel has to answer the question “What does /proc/self point to?”, it simply picks the currently-scheduled pid, i.e. the currently running process (on the current logical CPU). The effect is that /proc/self always points to the asking program's pid; if you run

ls -l /proc/self

you'll see ls's pid, if you write code which uses /proc/self that code will see its own pid, etc.

/proc is a mount point for procfs (kind of tmpfs, lives in memory), which is an interface to the kernel's internal data structure. Whatever you see in /proc is directly populated by Linux and also maintained by the kernel itself.

/proc/self is a symlink to the /proc/<PID> directory, where <PID> is the Process ID of the process accessing /proc at that very instant. So while in bash if you do cd /proc/self, you will be cd-id into the /proc/<PID>/, where <PID> is the PID for that instance of bash, while if some other process, let's say for cat:

$ cat /proc/self/comm
cat

You should absolutely not change anything in /proc except if kernel provides some interface to change the values. For example, kernel provides the interface /proc/sys/ to change kernel parameters at runtime, although mostly you should use sysctl to change values under /proc/sys/ rather than directly editing any file. Mishandling of Kernel's internal data structure would result in an unusable system or even system crash.

$$ is a special bash variable that gets expanded to the pid of the shell.

/proc/self is a real symbolic link to the /proc/ subdirectory of the process that is making the call.

When you do ls /proc/$$ the shell expands it to ls /proc/pid-of-bash and that is what you see, the contents of the shell process.

But when you do ls /proc/self you see the contents of the short lived ls process.

The $$ is not limited to this usage, you can write echo $$ to see the bash pid; you can use it to kill yourself, etc.

The /proc tree is a window into the operating system which is dynamically generated. When a process refers to /proc/self, the kernel translates self using the caller's pid. So that saves the process from doing a pid-lookup on itself, but you could get that same node of information by doing /proc/{pid} if you know the pid already.

One of the beauties of Unix is how it unifies all these things under / a root namespace and makes them behave like files and directories, even if they're not real physical file systems.

And you can't echo $self because that's a different concept entirely: to do an echo $[varname] is a shell thing: your shell has "environment variables" that maintain state. That has nothing to do with the /proc filesystem.

http://lxr.linux.no/linux+v3.2.9/fs/proc/base.c#L2482 is the current implementation.

The proc filesystem is entirely virtual, and is implemented so the internal VFS readlink delegates to the right place for special symlinks. So, it calculates what self points to when it is read / traversed, not every context switch.