You can entirely avoid the need to quote using here documents. Note that setting the label in single/double quotes(as in "EOF" in the example below) disables variable and command evaluation within the text.
cat <<"EOF" >>~/globalLog.txt
cat file2.txt | sed 's/"//g' > file3.txt ## Step 2
EOF
If the author was trying to catch you out by talking about that literal string (without shell expansion) as a path, then it's a relative path (mkdir -p './~/Documents'). Otherwise:
It's an absolute path, because resolving it doesn't depend on the process's current working directory. Relative path always means relative to the process's working directory. Or in the case of symlink targets, relative to the location of the symlink. (gcc -> gcc-5.2 vs. gcc -> /usr/bin/gcc-5.2). This matters for NFS-mounts and other cases where you can get to the same symlink via different absolute paths. e.g.
/net/tesla/home/peter/foo -> bar # always works from other machines
/net/tesla/home/peter/foo -> /home/peter/bar # references my home dir on the local machine, not tesla.
Debian will sometimes install symlinks to ../../doc/whatever/whatever, instead of an absolute symlink target, so it works when NFS mounted somewhere else, or when looking at a chroot without chroot(8)ing into it.
Every Unix process has its own cwd. The pwd command exists just to print it.
see: http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html
for more about changing directories with POSIX system calls.
As everyone else has said, ~ is expanded by the shell before the path is used for anything. Using ~/bin/myprog in a shell script will make it work differently for different users. The difference between ~/bin/foo and /home/peter/bin/foo is that one of them has hard-coded the location, while the other has parameterized it. It's an error (IMO) to call the ~ version a relative path.
Talking about things being "relative to an environment variable" is just confusing. It's bad practice to use different English-language meanings of terms that have specific technical meanings in the context you're using them in.
On a broken system, with HOME=a/relative/path, ~/foo would expand to a relative path. This would not be a usable setup at all.
Best Answer
In many ways depending on context. Simple illustrations:
cdcommand for example like you saidLiterally, inside a pattern, for instance in the context of pathname expansionpatternto replace any single one character with a command likegrepConsider
man cd,man path_resolutionand this explanation on how the builtincdcommand works internally (man cdhere):and this, which is a step-by-step example of how the steps above seemingly apply to changing directory from
/home/userto../../boot/memtest86:By trimming dot components to the same extent as the working directory depth, inevitably this yields a path expressed from the root. The steps for a single dot case etc. were skipped since it concatenates like above, then removes
./which is very easy to imagine as we're in the current directory. So this illustrates how.and..referencing the current and parent directory is implemented in this command's context internally, which is not through "substitution" but rather something akin to stream editing...You can investigate pathname expansion and pattern matching in
bashIn a pattern for a pathname like this, any character other than
*,?and[...]matches itself. So this means a dot can match itself literally:...will expand to
..,.(because * includes also null) and accordingly will list current and parent directory and also any file or directory in the current directory which literally starts with a dot (.*) and is followed by something else of whatever length. As explained in the manual you have some level of control over the expansion behavior etc. (using *glob options tosetandshopt).Here is an example of the character being used in a pattern (as it's
grep pattern file1) to select any one character, and is of course unrelated to file or directory names:This prints the directory contents so it catches everything (
grep -v .is used to catch empty lines). Generally with patterns in such expressions and most certainly that is the case withgrep, a single dot matches any single character. Finally consider these special characters examples in the dot.section for a quick reminder of some of the different use cases.So a dot can be used in path resolution, as a literal character which is part of a pattern, it can replace a single character in an expression with
grepand it can be even be a bash builtin used to execute commands from a file etc. How it is used on the command line varies with context...1. This is of course about the syntax of a specific command. If a command accepts a file/path as an argument then using the dot in its stead, as others have shown, expands to the current working directory which is quite convenient.