-2

Does 1<filename have any meaning?Perhaps it means "keyboard -> stdout"?

  • 5
    Can you flesh out your Question a bit? My first interpretation of the command in the body was: "run the command named 1 and provide the contents of filename as its stdin". But perhaps you meant it as a redirection in part of an overall command? And your title - what does n~0 mean? n=0 or n != 0 or n "is near" 0? – Jeff Schaller Apr 04 '19 at 15:15
  • heres the bash manual:Redirection of output causes the file whose name results from the expansion of word to be opened for writing on file descriptor n, or the standard output (file descriptor 1) if n is not specified. If the file does not exist it is created; if it does exist it is truncated to zero size.[n]<word@JeffSchaller – Jack Walter Apr 04 '19 at 15:29
  • This is unclear, but I don't see how this would be a duplicate of the linked question, since that one has the <& operator to clone/duplicate an existing redirection. – ilkkachu Apr 05 '19 at 16:52
  • @ilkkachu it alsho has [n]<... for n != 0. – muru Apr 06 '19 at 07:27

2 Answers2

2

1<filename is a redirection, it tells the shell to open the file filename for reading, and make it available on file descriptor 1 for the command being run (or for the whole shell process, if you use the redirection with exec). This is as it usually works for all redirections: < marks an input redirection, and the optional number at the front specifies a file descriptor number.

What's unusual about that redirection is that fd 1 is reserved for the standard output stream, so programs generally assume it can be written to. If it's opened by an input redirection, this assumption will fail.

$ touch filename
$ ls 1<filename
ls: write error: Bad file descriptor

The same would happen if you'd open fd 2 (stderr) for input, or fd 0 (stdin) for output.

$ cat 0> filename
cat: -: Bad file descriptor

Of course, if stderr can't be written to, you won't get an error message. You will, probably get a falsy nonzero exit status.

ilkkachu
  • 138,973
0

We really shouldn't open an input file on stdout. (You need exec before that redirection for it to work. But it will probably still fail and block) If you want to open a file with an fd just use 3 or something.

exec 3<filename
# do something with fd 3
exec 3<&-

It is possible to redirect to fd 0 (stdin), but if you exec fd 0 to point somewhere else, then you should save it first.

exec 3<&0
exec < filename
# do something with the file on fd 0
# restore stdin, free fd3
exec 0<&3 3<&-