Ubuntu – What does grep do

When running a shell or most programs in a shell anything you type is echo'd back to the user's terminal by the kernel's tty subsystem. There's other special handling, too, for erase characters, Ctrl+R, Ctrl+Z, and so on.

Certain programs, (editors in particular) that run from a command line don't need or want this. For this reason they signal the kernel with an IOCTL call against the tty (terminal) device that they don't want this behaviour. They don't want special characters to do special things, either. Instead they ask the kernel for a "raw" mode. In particular, editor's like vim turn off various "echo settings". All this applies to real tty terminals on a computer's serial lines, or the virtual terminals at Alt+Ctrl+F4, or the really virtual terminals you get when you run something like gnome-terminal under a GUI.

Such programs are supposed to reset any modes they change on the virtual tty they are using before they quit, either by entering a quit editor command or by taking a signal (from Ctrl+C) for example.

If they fail to do this properly the tty is left in the funny state you have discovered. Since programs can fail to reset the terminal, the reset command was written to allow the user to recover.

I assume the interrupt is messing with the python software you are running. I'd guess that that program isn't getting a chance to reset the terminal, or is simply failing to do so.

In the vim case, when I run your example I get the same behaviour you describe. I also see a message "Vim: Warning: Input is not from a terminal" (It goes away when you reset). This is because vim isn't started normally from the shell. Instead the 'grep' and 'xargs' commands have been using the standard input, normally occupied by the tty, for purposes of passing the file names from grep tto xargs.

In your posted output from stty -a we can see "-echo", also confirming that this is the problem. If you were to kill vim in such a way that it couldn't handle the signal gracefully you would probably see the same problem.

The problem is described elsewhere at https://stackoverflow.com/questions/3852616/xargs-with-command-that-open-editor-leaves-shell-in-weird-state.

A solution for the vim case is avoid xargs and use instead:

vim $(grep foo * -l)

Here the list of files is constructed by the shell, as it had been by xargs, but the shell is calling vim, which is directly connected to the tty. There is warning message sent to the error output file, and vim sets and resets the tty settings correctly.

An alternative to reset that doesn't clear the screen is stty sane .

More references here, and another interesting one here. Another interesting solution is given in an answer to https://stackoverflow.com/questions/8228831/why-does-locate-filename-xargs-vim-cause-strange-terminal-behaviour.

You are getting these Permission denied errors because there are some python files that your user does not have permission to read, so grep is not working for those files (you can't search them).

You want to "get rid of" the Permission denied errors.

1. You can add 2>/dev/null to the end of your command like this:

   grep -rn --include="*.py" "search-pattern" 2>/dev/null
   

   This suppresses all error messages, so you won't see the Permission denied errors popping up. But this obviously still means that grep is not searching those files, so if they do contain your search-pattern, you won't see them in the output.

   Explanation:
   In Linux, there are three things called file descriptors: stdin, stdout, stderr. If you run a command and it gives you an error, the error is written to the file descriptor stderr. By default, stderr outputs the errors to the terminal. So what we can do is redirect the errors, i.e. we redirect stderr somewhere else instead of the terminal. We redirect stuff in Linux by using the > sign. So where are we going to redirect stderr? To /dev/null. /dev/null is a special file; think of it as a black hole. Anything you redirect to it gets thrown away. Finally, we refer to stderr as simply the number 2. So 2>/dev/null tells Linux to redirect 2 to /dev/null. 1 means stdout (which is the normal output of a command, i.e. not errors). So, for example, if you wanted to save the actual output of your grep command to a file rather than have it displayed in the terminal, you can use 1>/path/to/filename, which will redirect stdout to that file.

2. Use sudo with your command, assuming that you have the privileges:

   sudo grep -rn --include="*.py" "search-pattern"
   

   If your username has root privileges (i.e. if you're an administrator on the machine), using sudo before a command runs it as the root user, so you will never get the Permission denied errors and grep will search those files and output the search-pattern if it finds it inside them.