[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: redirection / process substitution fails to read a file descriptor
From: |
Robert Elz |
Subject: |
Re: redirection / process substitution fails to read a file descriptor |
Date: |
Mon, 18 Nov 2024 06:25:31 +0700 |
Date: Sun, 17 Nov 2024 12:16:40 -0600
From: Mike Peters <mike@texaspeters.com>
Message-ID: <ca572657-4ad5-496d-b22f-96b4466de360@texaspeters.com>
| * (Although I have yet to determine any purpose or significance of
| these redirections in the manual, other than simply not causing an error,
| as it "do[es] not affect the current shell environment", and there is
| "no command name", so what is there remaining to affect?)
The short answer is side effects. This is more obvious in the >file
case, as that causes file to be created (if needed) and truncated (if
it didn't need to be created) or >>file which causes file to be created
if needed (but not truncated).
The use for testing for errors is also occasionally useful - a redirection
error will cause the shell to exit (non-interactive shell) so <file can
be a kind of shortcut for
test -r file || { printf >&2 message; exit 2; }
(or similar) (and output directions test that the file either exists or
can be created, and is writeable).
Most of the time commands with nothing but redirections aren't useful,
but occasionally they can be (>file is faster than cp /dev/null file,
so if a script is wanting to make large numbers of empty files, just
using redirections to do it can be useful).
kre