To find out what commands are masked by aliases, do something like this:
alias | sed 's/^[^ ]* *\|=.*$//g' | while read a; do
printf "%20.20s : %s\n" $a "$(type -ta $a | tr '\n' ' ')"
done | awk -F: '$2 ~ /file/'
Explanation
alias
alone lists defined aliases and sed
extracts their name. The while loop runs type -ta
on each of them and awk
prints the lines that both contain alias and file.
The answer is "Probably yes, but it depends on the filesystem type, and timing."
None of those three examples will overwrite the physical data blocks of old_file or existing_file, except by chance.
mv new_file old_file
. This will unlink old_file. If there are additional hard links to old_file, the blocks will remain unchanged in those remaining links. Otherwise, the blocks will generally (it depends on the filesystem type) be placed on a free list. Then, if the mv
requires copying (a opposed to just moving directory entries), new blocks will be allocated as mv
writes.
These newly-allocated blocks may or may not be the same ones that were just freed. On filesystems like UFS, blocks are allocated, if possible, from the same cylinder group as the directory the file was created in. So there's a chance that unlinking a file from a directory and creating a file in that same directory will re-use (and overwrite) some of the same blocks that were just freed. This is why the standard advice to people who accidentally remove a file is to not write any new data to files in their directory tree (and preferably not to the entire filesystem) until someone can attempt file recovery.
cp new_file old_file
will do the following (you can use strace
to see the system calls):
open("old_file", O_WRONLY|O_TRUNC) = 4
The O_TRUNC flag will cause all the data blocks to be freed, just like mv
did above. And as above, they will generally be added to a free list, and may or may not get reused by the subsequent writes done by the cp
command.
vi existing_file
. If vi
is actually vim
, the :x
command does the following:
unlink("existing_file~") = -1 ENOENT (No such file or directory)
rename("existing_file", "existing_file~") = 0
open("existing_file", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3
So it doesn't even remove the old data; the data is preserved in a backup file.
On FreeBSD, vi
does open("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664)
, which will have the same semantics as cp
, above.
You can recover some or all of the data without special programs; all you need is grep
and dd
, and access to the raw device.
For small text files, the single grep
command in the answer from @Steven D in the question you linked to is the easiest way:
grep -i -a -B100 -A100 'text in the deleted file' /dev/sda1
But for larger files that may be in multiple non-contiguous blocks, I do this:
grep -a -b "text in the deleted file" /dev/sda1
13813610612:this is some text in the deleted file
which will give you the offset in bytes of the matching line. Follow this with a series of dd
commands, starting with
dd if=/dev/sda1 count=1 skip=$(expr 13813610612 / 512)
You'd also want to read some blocks before and after that block. On UFS, file blocks are usually 8KB and are usually allocated fairly contiguously, a single file's blocks being interleaved alternately with 8KB blocks from other files or free space. The tail of a file on UFS is up to 7 1KB fragments, which may or may not be contiguous.
Of course, on file systems that compress or encrypt data, recovery might not be this straightforward.
There are actually very few utilities in Unix that will overwrite an existing file's data blocks. One that comes to mind is dd conv=notrunc
. Another is shred
.
Best Answer
alias
without parameter outputs the definitions of currently defined aliases.declare -f
outputs the definitions of currently defined functions.export -p
outputs the definitions of currently defined variables.All those commands output definitions ready to be reused, you can redirect their outputs directly to a new
~/.bashrc
.All lists will contain a lot of elements defined elsewhere, for example
/etc/profile
and/etc/bash_completion
. So you will have to clean up the list manually.