Small confusion about redirection in Linux?

[Brief-Wishbone9091]

Chapter 18. I/O redirection

Note that the bash shell effectively removes the redirection from the command line before argument 0 is executed. This means that in the case of this command:

echo hello > greetings.txt

the shell only counts two arguments (echo = argument 0, hello = argument 1). The redirection is removed before the argument counting takes place.

I feel it's telling before counting the number of arguments, redirection operator is ignored.

But later it says how it affects output erasing file case.

While scanning the line, the shell will see the > sign and will clear the file! Since this happens before resolving argument 0, this means that even when the command fails, the file will have been cleared!

[paul@RHELv4u3 ~]$ cat winter.txt
It is cold today!
[paul@RHELv4u3 ~]$ zcho It is cold today! > winter.txt
-bash: zcho: command not found
[paul@RHELv4u3 ~]$ cat winter.txt
[paul@RHELv4u3 ~]$

So can you explain how zcho It is cold today! > winter.txt command processes internally?

My estimate

1) > is removed.

2) Number of arguments are count. There are 2 arguments "It is cold today!" and winter.txt

3) then what? i don't know.

 

[gvisoc]

The above example is more driven by the ">" than by the bash command line behaviour.

When Bash doesn't find a command it erases the standard output. So in your command, this is what happens:

1. Bash tries to run "zcho It is cold today!"
2. It can't. It writes "-bash: zcho: command not found" to standard error, and "" to standard output
3. ">" takes the standard output of the previous command and writes it into winter.txt, overwriting the previous content.
4. Your "winter.txt" is blank now.

If you try this command: "zho It is cold today! &> winter.txt" you'll see that, as both standard output and error are now redirected into winter.txt, the content will be as follows:

[gvisoc@vao Downloads]$ zcho It is cold today! &> winter.txt
[gvisoc@vao Downloads]$ cat winter.txt 
bash: zcho: command not found...
[gvisoc@vao Downloads]$

 

[Brief-Wishbone9091]

It's not clear to me. Could you simplify? In my opinion, bash first sees the > operator. Then it clears the file. Then other stuffs happen.

 

[camtaf]

Basically, the > creates a new file, whilst the >> adds to a file.

 

[Brief-Wishbone9091]

Basically, the > creates a new file, whilst the >> adds to a file.

That I know. I'm confused here about the order of execution. IMO when I type wrong command like zcho, file should not be cleared. There's where my confusion stems from. So I want to know the inner working of the command-line stuffs here.

 

[osprey]

It's not clear to me. Could you simplify? In my opinion, bash first sees the > operator. Then it clears the file. Then other stuffs happen.

I did smile at this

These things are generally not matters of opinion.

Consider the following:

[flip@flop ~]$ > newfile
[flip@flop ~]$ cat newfile
[flip@flop ~]$ echo hello > newfile
[flip@flop ~]$ cat newfile
hello

First, > creates a file called newfile.
Second, cat shows that newfile has no output so it is empty.
Third "hello" is echoed into newfile.
Fourth, after "hello" is echoed into newfile, cat shows that newfile holds the term: hello, as echoed.

It's clear here that bash in the third step, has operated by executing "echo hello" before it executes > since it has to write the "hello" into newfile.

If one runs the following:

[flip@flop ~]$ echo hello >
bash: syntax error near unexpected token `newline'

There is an error reported. This indicates that bash has read the whole line first before execution to determine if it is executable.

I guess one can distinguish the aspects of what bash "sees" and how bash "executes". It sees the whole command line first, but this does not mean that it sees > before it sees the echo command in the code above. Bash still reads the line from the first byte consecutively in order to the last. It doesn't jump to > to see that first.

 

[vs2-free-users]

Hi,

its simple in bash

>

resets or create a file if not exsists.

>>

attach to file create a file if not exsists

examples:

#myfile.txt not present
echo 'line 1' > myfile.txt
cat myfile.txt
line 1

#myfile.txt is present
echo 'line 2' > myfile.txt
cat myfile.txt
line 2

#myfile.txt not present
echo 'line 1' >> myfile.txt
cat myfile.txt
line 1

#myfile.txt is present
echo 'line 2' >> myfile.txt
cat myfile.txt
line 1
line 2

 

[sphen]

I wrote more than my share of programming guidelines documents and served as the "language lawyer" for various development teams.
-> In every case, the behavior of the code is the ultimate arbiter about what the code does or does not do.

Ignore the rest:

Where I worked, we were passionate about those subtleties, and often ginned up prototypes and proof-of-concept code to deal with those details. Sometimes you dug into the assembly code to see what was really going on. Half the time, we had to build small prototypes to send minimum-code, proof-of-concept bugs to partners and manufacturers whose products we used. ... and those prototypes had to be written in a way that did not expose sensitive or proprietary information. We found microprocessor bugs, compiler bugs, code library bugs, and much more. Here are two of the issues:

-> The code does not always behave the same between platforms.
Example: My primary desktop is still Mac. When I run a script or code that I see on Linux.org, the "Unix" terminal in the Mac does not always match a Linux terminal's behavior. It is the same "bash" (or zsh), but it is running on a different operating system with slight differences in the compiled commands and code behind it. Close, but not always the same.

-> The code does not always behave the same way each time you run it.

• Nearly all of the time, the code should run the same way no matter what. An image file must look the same every time it is decompressed and displayed, right? It does not always happen like that, as we all know.
• Double it for multi-threaded code.
• Double it again for realtime, event-driven code.
• Quadruple it if your product has distributed separate components that run on multiple independent devices which network together, which describes pretty much everything today.
• Confessions:
  • I swear that quantum mechanics is conspiring against me to randomize computer system behaviors that should be consistent. Yeah, just kidding.
  • This is what broke my heart from a lifetime of working with computers. When I was young, I lived in a world where every time you typed "run", the program would do precisely the same thing every time.
    -> Repeat after me, using your best droll "Inspector Clouseau French" accent:
    "Not any more!"

Example:
We found a bug where an "if" statement always took the branch. (It took us three weeks to get to that point.) When we finally looked at the assembly code, we saw that the compiler had generated the correct test instruction but no conditional jump after it, which explained the bug. Building a small, demonstrative test case that showed the bug was the only way to convince the compiler manufacturer that the bug was theirs to own.