0

Regularly, I have seen the following syntax:

awk 'stuff' <file
sort <file

The thing is, I usually write:

awk 'stuff' file
sort file

And things work perfectly. So if both syntaxes are roughly equivalent (or are they?), is there any benefit from using <file syntax ?

EDIT

Existing threads cover some of my interrogations (using < implies that the shell opens the file first and then passes it as standard input to the command), but I feel that some remain:

  • POSIX compliancy ?
  • Is it to dissipate any ambiguity concerning the nature of file argument ?
  • Is it specific to a certain type of shell ?
  • Is it considered deprecated ?
  • Performance-wise, is there a notable difference ?
  • Any example where you would use one against the other is welcome.
  • The links you provided do hold some answers, (notably that both syntaxes do not behave the same), but my particular question covers a larger scope I think. Should I still accept duplicate status and close it ? – Valentin B. Oct 25 '16 at 14:28
  • I have edited the question to enlarge the scope. – Valentin B. Oct 25 '16 at 14:33

1 Answers1

0

Either will work if the command supports reading from standard input (the command <file form) or from a named file in the argument list. Even tcsh supports command <file so that syntax is fairly portable; whether a given command can read a file in the argument list (or standard input) depends on the command; ed(1) for instance reads commands from standard input, so cannot read a file from standard input.

At the C level, a command that reads from standard input or a named file will be doing something like

#include <err.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
    FILE *fhandle;

    // option processing here ...

    if (argc == 0 || strncmp(*argv, "-", (size_t) 2) == 0) {
        fhandle = stdin;
    } else {
        if ((fhandle = fopen(*argv, "r")) == NULL)
            err(1, "could not open '%s'", *argv);
    }

    // read from fhandle here, which is either from stdin or a file ...
}

Some commands demand the command - form to indicate a read from standard input, others will do so automatically (as in the abovesaid code) when the argument list is empty. Otherwise, the code in either case will be dealing with fhandle, and does not care where the input is coming from (unless an error message needs to include the filename, but that can be stuck into an additional variable).

thrig
  • 34,938
  • Does that mean that the file is read twice when using input redirection ? – Valentin B. Oct 25 '16 at 14:40
  • some commands that handles filename arguments sometimes treat those arguments specially. like awk and the filename foo=bar, awk – llua Oct 25 '16 at 14:45
  • Also yes I am aware some commands cannot take files as arguments, hence redirection through < is the only available option, but the question is more about why would you use redirection on commands that do not need it because they handle files natively ? – Valentin B. Oct 25 '16 at 14:51
  • @ValentinB. what gave you the idea the file was read twice? It is not. – thrig Oct 25 '16 at 14:54
  • I am not very knowledgeable in these matters, but I was under the impression that for the file to be accessible in stdin it had to be read. This is most probably a rookie misconception on my part. – Valentin B. Oct 25 '16 at 15:01
  • @ValentinB. the stdin and fhandle variables are pointers to a file; the read of the contents will happen subsequent to the figuring out of whether the input is from stdin or a named file. This is not shown in my code, as the read is exactly the same in either the standard input or named file case. – thrig Oct 25 '16 at 15:25
  • Ok thanks for clearing that up. That sounds pretty logical now that you say it. – Valentin B. Oct 25 '16 at 15:47