So I just executed "< ./somefile.txt" in linux shell,
dash, and similar shells, that do not execute a command. That merely assigns
somefile.txt to stdin. This goes nowhere because stdin is not used unless you supply a command.
To use stdin for something try, for example,
cat echoes stdin to stdout, you will see the file displayed in the terminal.
On the other hand, it you do want to execute the script, you can do that in a subshell as follows:
Or, if (a)
somefile.txt has its executable bit set (
chmod +x somfile.txt) and (b) it is either plain
sh compatible or has a proper shebang for the first line, such as
Or, to execute it in the current shell (i.e. source it), run:
Usually, one sources a script if one wants it to change the current working directory and other aspects of the current shell's environment. If you don't such side-effects, then don't source it; execute it in a subshell.
@StéphaneChazelas points out that
<./somefile.txt is useful as a test of whether file
./somefile.txt is readable. For example, to exit with code 1 if
./somefile.txt is not readable:
<./somefile.txt || exit 2
This works because the shell can only assign
./somefile.txt to stdin if it is readable. If it isn't, the shell displays an error message and returns code 1. That code triggers the "or (
||) clause which, in this case, would case the script to exit with code 2. The more standard and portable approach for the same test would be:
[ -r "./somefile.txt" ] || exit 2