When running the command sed -e "s/a/b/" /tmp/file >/tmp/file While /tmp/file contains data, why is /tmp/file empty afterwards?

The file order is generally `command input_file > output_file`, and the issue stems from the shell's handling of redirection, not an incorrect argument order for `sed` itself.

Even if `sed` did not match anything, it would typically pass the original input lines to stdout, but the core problem is that `sed` receives no input because the file is truncated first.

When the shell establishes output redirection using `>` to `/tmp/file`, it opens `/tmp/file` for writing and truncates its contents to zero size immediately. By the time `sed` attempts to read its input from `/tmp/file`, the file is already empty, resulting in `sed` processing no data and thus producing no output, leaving `/tmp/file` empty.

The `>` character is the correct and standard shell operator for redirecting standard output to a file, but its execution timing is critical in this scenario.