a better "20. Randomize lines in file":
shuf file.txt
cat file.txt | sort -R
I looked at the source code for GNU sort and what they're doing is reading 16 bytes from the system CSPRNG and then initializing an MD5 digest object with those 16 bytes of input. Then the input lines are sorted according to the hash of each line with the 16 bytes prepended.
Although they should no longer use MD5 for this, I don't think we know anything about the structure of MD5 that would even allow an adversary to have any advantage above chance in distinguishing between output created this way and an output created via a different randomization method. (Edit: or distinguishing between the distribution of output created this way and the distribution of output created via another method!)
The output of sort -R is different on each output and ordinarily covers the whole range of possible permutations.
$ for i in $(seq 10000); do seq 6 | sort -R | sha256sum; done | sort -u | wc -l
720Eg `(seq 3; seq 3; seq 3) | sort -R`.
This is fantastic, a game changer for me.. I often give people a command like ls -lad /path /path/to /path/to/file
Thanks!
whatever < file.txt
cat file.txt | whatever
tar tf whatever.tgz
tar tf whatever.tar.bz2
tar tf whatever.txz
...
tar xf whatever.tar.gz
tar xf whatever.tar.Z
...
<file.txt grep foo | sorthttps://news.ycombinator.com/item?id=15249370
The shell (not the command) is the one expanding those metacharacters, so (within limits), in:
cmd < file
or
< file cmd
where you put that piece (< file) on the line does not matter, because the actual command cmd never sees the redirection at all - it is done [1] by the time the command starts. The cmd command will only see the command line arguments (other than redirections) and options (arguments that start with a dash). Even expansion of $ and other sigils (unless quoted) happens before the command starts.
[1] I.e. the shell and kernel set up the standard input of the command to be connected to the file opened for reading (in the case of < file).