My apologies, I didn't realize this error until after sending. $ echo $(cat file.txt) > file.txt $ cat file.txt <no output>
SHOULD BE $ echo $(cat file.txt) > file.txt $ cat file.txt hi And that seems to be it. On Wed, Mar 27, 2019 at 11:48 AM Sean Lum <seanjk...@gmail.com> wrote: > Hi, > > My name is Sean Lum. I've run into something on my Linux systems (Debian, > Fedora, and Arch, occurring both in bash and sh on all three, and all the > machines are up to date at the time of testing), and it involves shell > input/output redirects and the cat command. I am not completely sure on how > the cat command handles shell redirects, but similar behavior is also > present in the less command. I am unsure if this is a bash command or cat > command issue or a less command issue. > > The issue is as such, when the input file is the output file, in a > truncating redirect, the file is truncated, and no content written to the > file by the redirect. This behavior is the same on the less command, using > the ">" operator, but has differing behavior on the ">>" operator. > > $ echo "hi" > file.txt > $ cat file.txt > hi > $ cat file.txt > file.txt > $ cat file.txt > <no output> > $ echo "hi" > file.txt > $ cat file.txt >| file.txt > <no output> > $ echo "hi" > file.txt > $ echo $(cat file.txt) > file.txt > $ cat file.txt > <no output> > $ cat file.txt >> file.txt > cat: file.txt: input file is output file > > In bash(1) under Redirecting Output. I notice that: > "If the file does not exist it is created; if it does exist it is > truncated to zero size." > ... > "If the redirection operator is >, and the noclobber option to the set > builtin has been enabled, the redirection will fail if the file whose name > results from the expansion of word exists and is a regular file. If the > redirection operator is >|, or the redirection operator is > and the > noclobber option to the set builtin command is not enabled, the redirection > is attempted even if the file named by word exists." > > My question is, even with the noclobber operator set, why is the content > of the file truncated and not overwritten with the same file content if the > input file is also an output file? Similar behavior occurs in the less > command as well (file truncated with ">", file contents appended after file > contents with ">>"). I'm still confused, is this defined or undefined > behavior? Is there an explanation for this? > > My thoughts on possibilities: > 1. I am not understanding the way bash works with the cat command, and > this is expected behavior. > 2. Fencing issues with memory access, the input file and output file are > the same, and a file descriptor related error arises? Or a read/write error > arises? > 3. A race condition in the order of processing in the bash script causing > the file to be truncated after the file contents are written? > 4. Could be something else, I haven't quite gotten to the point of > inspecting source code yet. > > Thank you, and I hope you have a great day, > - Sean Lum >