[Erl_question18] instructor! I also found a magic function in Erlang shell.

People always want to improve efficiency, create more value, and get more choices. However, a person's energy and time are limited. It is especially important to reduce repetitive or meaningless work! You either know how to authorize or give repetitive work to machines. Reality: Americans prefer to outsource unimportant development to other countries and focus on their own: not all superiors distribute what they think is not worth doing to their subordinates. Do they leave their energy to think about more important things? However, I had to try my best to let the machine do it. So the most useful part of my work debugging is shell. It is necessary to repeat C. erl this module, read the document is really a "sharpening" good method, pick a few very cool functions to try. C. erl is a command interface module. The functions in ERL are only used in shell, and sometimes the module name can be omitted when called. For example, C: PID (A, B, C) -----> PID (A, B, C ). 1.

bt(Pid) -> ok | undefined

It is the short version of Erlang: process_display (PID, backtrace). You can view the stack call relationship of the PID process. 2.

c(File) -> {ok, Module} | errorc(File, Options) -> {ok, Module} | error

C/1/2 compilation, and then add the module to the Code server. options is [] by default. equivalent to: compile: file (file, options ++ [report_errors, report_warnings]) 3.

cd(Dir) -> ok

Change working directory

 > cd("../erlang")./home/ron/erlang 

4.

flush() -> ok

Refresh all received messages to the shell to display (this is very familiar to everyone, Uncle Joe has been using it for teaching). 5.

help() -> ok

Show all help information and all function information available in this module. 6.

i() -> okni() -> ok

I/0 displays information about the local system and will give you an overview of all processes. ni/0 is also the case, but information about all nodes connected 7.

i(X, Y, Z) -> [{atom(), term()}] Types:X = Y = Z = integer() >= 0

Display the information of the specified process, which is equivalent to process_info (PID (x, y, z). 8.

l(Module) -> code:load_ret()

Eliminate the old Code and update the latest code. If you want to use this function in function level, use code: purge (module), Code: load_file (Module). 9.

lc(Files) -> ok Types:Files = [File]File = file:filename()

Use compile: file (file, [report_errors, report_warnings]) to compile all files. 10.

ls() -> ok 

Like the LS command in Linux: list all files in the current folder. 11.

m() -> ok

Displays information about all loaded modules, including their header files. 12.

m(Module) -> ok

Displays information about the module. You can check whether the module you want to load has been updated successfully.

nc(File) -> {ok, Module} | errornc(File, Options) -> {ok, Module} | error Types:File = file:name()Options = [Option] | OptionOption = compile:option()Module = module()

Compile: file (file, options ++ [report_errors, report_warnings]) and load it to all nodes !!! 14.

nl(Module) -> abcast | error

Load the specified module to all connected nodes. 15.

regs() -> oknregs() -> ok

Regs/0 displays the information of all registered processes on the current node. The same is true for NREGS/0, but only for all nodes. I have used most of the above functions, but the biggest gains of this study are: I didn't know the two functions, NC/1 and NL/1! It's so powerful that you can't grasp it!Recently, a scenario can be used: Scenario: 1. test to stream a bug to you; 2. you have modified it locally. 3. enable Erlang shell compilation for hot loading; 4. test it locally. Submit it after the test, and repeat the three processes on the tested server. This is still the case. When it comes to complexity: You have clearly passed the test locally, I tried to test the server, but I was sure that the code was not synchronized in the second place. Now I still need to find the file that was not synchronized. This is a time-consuming and thankless job. To put it bluntly, the code used for testing is consistent with your local code! You can load both the local server and the test server in the loading 3 !!!, In this way, there will be no inconsistency communication issues: encapsulate the following in user_default.erl:

Nc_my (File)-> net_kernel: connect_node ('test server node'), NC (file ).

After using this, I feel much better.
If you find any magical functions, please share them here!
Even if your feet are shorter, you have to go over the mountains with your reference ~~~~~~~~