Per man definition, this command gets the input from a file.
$ command -r FILENAME
Suppose that FILENAME
is a file containing a list of filenames, as it was generated using ls > FILENAME
.
How can I, instead, feed the command with the result of ls
directly? In my head something like this should be possible:
$ ls | command -r
But it doesn't, the output of ls
doesn't get hooked as an argument. Output:
Usage: command -r FILENAME
error: -r option requires an argument
How could I obtain the desired effect?
Best Answer
This is dependent on the command. Some commands that read from a file expect that the file be a regular file, whose size is known in advance, and which can be read from any position and rewinded. This is unlikely if the contents of the file is a list of file names: then the command will probably be content with a pipe which it will just read sequentially from start to finish. There are several ways to feed data via a pipe to a command that expects a file name.
Many commands treat
-
as a special name, meaning to read from standard input rather than opening a file. This is a convention, not an obligation.Many unix variants provide special files in
/dev
that designate the standard descriptors. If/dev/stdin
exists, opening it and reading from it is equivalent to reading from standard input; likewise/dev/fd/0
if it exists.If your shell is ksh, bash or zsh, you can make the shell deal with the business of allocating some file descriptor. The main advantage of this method is that it's not tied to standard input, so you can use standard input for something else, and you can use it more than once.
If the command expects the name to have a particular form (typically a particular extension), you can try to fool it with a symbolic link.
Or you can use a named pipe.
Note that generating a list of files with
ls
is problematic becausels
tends to mangle file names when they contain unprintable characters.printf '%s\n' *
is more reliable — it'll print every byte literally in file names. File names containing newlines will still cause trouble, but that's unavoidable if the command expects a list of file names separated by newlines.