Bash – Removing redirection operator does not change output. Why

bashcommand lineioio-redirectionshell

I saw this usage of redirection somewhere, and thought it was a typo:

grep root < /etc/passwd

But after I run it, I saw that it gives the same output with
grep root /etc/passwd:

$ grep root < /etc/passwd
root:x:0:0:root:/root:/bin/bash

$ grep root   /etc/passwd
root:x:0:0:root:/root:/bin/bash

The same thing happens with

cat < /etc/passwd
cat   /etc/passwd

However, redirection is ignored when used with ls:

ls < /etc/passwd

does not print the same output with

ls  /etc/passwd

What is happening?

Best Answer

Many utilities which work with files will accept stdin (standard input) as streamed input, or accept the file-name as a parameter.. Your < file examples are redirecting the output of the file to the utility. The file was opened by the shell and passed on to your utility via stdin ..

On the other hand, with cat file, cat is handling the opening and reading of file, and no redirection is involved.

ls never reads a file, therefore it does not take a file name as a parameter with a view to opening and reading the file.. (it accepts file-name masks) ... For ls, the redirection action is, in effect, ignored because nothing in the process reads the shell-opened file...

To determine how any utility behaves, just type man utility-name in the terminal... man is a contraction of manual ... eg. man cat presents you with cat's manual

Related Solutions

Bash shell launched by forkpty() spawns child processes that ignore SIGINT. Why and how to ensure SIGINT is not ignored

This outcome cannot be due to the code block you showed in your question. There must be something else in other parts of your overall setup.

Given only the usage scenario you described, the most likely reason is that you actually set SIGINT to be ignored in your code somewhere before the forkpty, or before the execve in forkpty’s child.

This would yield the outcome you describe because then your forkpty’ed bash -i would inherit such SIGINT-ignored setup, and while it would set it otherwise for its own internal purposes (thus not ignoring SIGINT) it would also reset it to the inherited ignored state for each and every command it would spawn.

This is documented Bash’s behavior, see Bash’s man-page at “COMMAND EXECUTION ENVIRONMENT” chapter, specifically the paragraph saying:

When a simple command other than a builtin or shell function is to be executed, it is invoked in a separate execution environment that consists of the following. [...]

[...]

o traps caught by the shell are reset to the values inherited from the shell's parent, and traps ignored by the shell are ignored

HTH

Shell – Two files with a common field – is it possible to sort one based on the other

Join the files, sort the combined file, and strip out the columns you don't want.

In this case, field 1 of /etc/passwd is to be joined with field 1 of /etc/shadow, with : as the field separator.

join -t : -1 1 -2 1 /etc/passwd /etc/shadow |
sort -t : -k 3,3n |
cut -d : -f 1,8-

Best Answer

Related Solutions

Bash shell launched by forkpty() spawns child processes that ignore SIGINT. Why and how to ensure SIGINT is not ignored

Shell – Two files with a common field – is it possible to sort one based on the other

Related Question