Does 1<filename have any meaning?Perhaps it means "keyboard -> stdout"?
- 27,473
- 9
- 58
- 102
- 43
- 7
-
5Can 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]
– 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 Answers
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.
- 133,243
- 15
- 236
- 397
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<&-
- 116
- 2
-
"We really shouldn't open a file on stdout." -- What does that even mean? Any time you write `somecmd > outputfile`, you're opening a file on that command's stdout. Surely that's not a bad thing? – ilkkachu Apr 05 '19 at 16:59
-
I meant that it will fail and block, thus leaving the program hanging. I certainly wasn't clear enough. – Guy Gastineau Apr 06 '19 at 04:33
-
-
-
Reproducing his situation makes a hanging script, and no shell errors are given. – Guy Gastineau Apr 06 '19 at 04:41