Return to Answer

As suggested by @ilkkachu, you could also add an option to take input from stdin or from an arbitrary file so the user can decide when and when not to read stdin.

Another option is to use xargs which is the tool to convert an input stream into a list of arguments. For instance, with GNU xargs:

xargs -d '\n' -a filelist.txt myscript -x -st -i file1 file2

Would call myscript with file1, file2 and the contents of each line of filelist.txt as arguments. Beware though that if the list is bing, it may be broken down into several invocations of myscript each taking a subset of the lines in filelist.txt, but each of them also getting file1 and file2 each time.

Above, we only ready from stdin if no non-option argument is passed on the command line.

If you want to allow input to be provided both via arguments or stdin, you'd have to always read from stdin:

Above, we only ready from stdin if no non-option argument is passed on the command line. That's what most text utilities do. For example grep -e regexp -- file1 file2 searches for the regexp in those files, but grep -e regexp searches in stdin.

If you wanted to allow input to be provided both via arguments or stdin, you'd have to always read from stdin:

You might be tempted to do:

if [ -t 0 ]; then
  args=()
else
  readarray -t args
fi
args+=("$@")

To only read stdin if it's not a tty device, but I'd argue it's a bad idea as then; users would easily lose sight of the fact the script may consume stdin, which would create probem when they use it in a context where stdin is redirected to a file other than /dev/null, such as in things like while IFS= read -r...; do myscript ...; done < some-file.