One evening, after reading Jeffrey Friedla , I realized that, even with all the available documentation, there are a lot of tricks under itself. All people are too different. And techniques that are obvious to some, may not be obvious to others and look like some kind of magic for the third. By the way, I already described several such moments here .

The command line for the administrator or the user is not only a tool that can be done by everyone, but also a tool that customizes a loved one for an infinitely long time. Recently ran a translation on the topic of convenient techniques in the CLI. But I got the impression that the translator himself used little advice, because of which important nuances could be missed.

Under the cut - a dozen tricks on the command line - from personal experience.
Papay 27 october 2017, 15:07

Once upon a time, every programmer has written something like this here:
double div (double a, double b){
return a / b;

He was fully convinced that this function does exactly what he need - divides a by b. But sooner or later, it turned out to be next friend or teacher, who explained that this function makes one more important thing in the life of any program: it brings down it with the exception of dividing by zero, if b makes zero. After that, the future programmer had to understand the need of validation of input data. Someone decided that this issue is settled, and someone came to the conclusion that this is only half of the matter.

In fact, put verifications at every step are a common practice. This is taught in the university. But with the time comes the idea that something is not right:
  • Verification of different things takes a lot of space in a code. Because of verifications, this code stops to be visible.
  • Profiler shows that a significant portion of time is spent on the verifications. The program is slow and users complain about it.
  • The same verifications repeat for many times. If a certain class has functions that call each other and work with the same data - verifications are written to each of them and some of them trigger “run free”.
Pirat 8 september 2011, 11:51

The other day I debugged the driver, because when I was using it, at first glance appeared chaotic and some magic BSoDs. All function calls were correct; there were not any errors with zero pointers and other common problems. I did not figure out what could happen with this driver, I asked more experienced friend to see what's wrong. A few hours later he said that understood the reason for the bug. The result confused both of us.

It turned out that the cause of falling was the banal and simple: in the logic of the driver was used a stack extensively, often a function used 10 - 20 KB of memory on the stack under various buffers and arrays. MSDN says that the kernel stack is limited to three pages of memory (for 32-bit architecture is about 12KB), and therefore it is better to refrain from the multiple function calls and recursion.
Pirat 6 september 2011, 11:11