I recommend reading a book on unix or Linux shell and command line usage, in order to learn basic usage and get a feeling for some advanced features. Then you can turn to reference documentation.
The usage of specific commands is described in their manual. man cat will show the manual of the cat command on your system. Manual pages are usually references, not tutorials, though they often contain examples. On Linux, cat --help shows a terse usage message (meant for quick perusal when you already know the fundamentals and want to find an option for a specific task).
The POSIX standard specifies a minimum set of commands, options and shell features that every unix system is supposed to support. Most current systems by and large support POSIX:2004 (also known as Single UNIX version 3 and the Open Group Base Specifications issue 6). GNU software (the utilities found on Linux) often have many extensions to this minimum set.
There are common conventions for command-line arguments. POSIX specifies utility conventions that most utilities follow, in particular:
- Options consist of
- followed by a single letter; -ab is shorthand for -a -b.
-- signifies the end of options. For example, in rm -- -a, -a is not an option but an operand, i.e. a file to act upon, so this commands removes the file called -a.- A lone
- stands for standard input, where an input file is expected. It stands for standard output where an output file is expected.
GNU utilities and others also support “long options” of the form --name. Some utilities go against the general convention and take multi-letter options with a single leading dash: -name.
Redirection is a shell feature, so you'll find it in your shell's manual. <<< to use a string as standard input is a ksh extension, also supported by bash and zsh. As long as the shell supports it, it can be used on any command.
eval does not read its command string from stdin.
eval "$(cat file.txt)"
# or easier, in ksh/bash/zsh
eval "$(<file.txt)"
# usually you cannot be sure that a command ends at the end of line 5
eval "$(head -n 5 file.txt)"
Instead of eval you can use standard . or bash/zsh/ksh source if the commands are in a file anyway:
source ./file
(note that it's important to add that ./. Otherwise source looks for file in $PATH before considering the file in the current directory. If in POSIX mode, bash would not even consider the file in the current directory, even if not found in $PATH).
That does not work with choosing a part of the file, of course. That could be done by:
head -n 5 file.txt >commands.tmp
source ./commands.tmp
Or (with ksh93, zsh, bash):
source <(head -n 5 file.txt)
Best Answer
mknodwas originally used to create the character and block devices that populate/dev/. Nowadays software likeudevautomatically creates and removes device nodes on the virtual filesystem when the corresponding hardware is detected by the kernel, but originally/devwas just a directory in/that was populated during install.So yes, in case of a near complete disaster causing the
/devvirtual filesystem not to load and/orudevfailing spectacularly, usingmknodto painstakingly repopulate at least a rudimentary device tree to get something back up can be done... But yeah, that's sysadmin horror story time. Personally, I recommend a rescue USB stick or CD.Aside from creating named pipes, I can't think of a single possible day-to-day use for it that an end user would need to concern themselves with -- and even that is stretching the definition of 'day to day use'.