Shell command extension method based on go language

Abstract

The invention discloses a shell command extension method based on go language, belongs to the field of computer software technology, and includes: editing a first configuration file in a shell terminal, configuring command line parameters of a pre-built shell command extension tool; starting the shell command extension tool, parsing the first configuration file and the command line parameters to obtain the original shell command, the final target node information of executing the original shell command, and the to-be-executed operation of the shell command extension tool; connecting the corresponding final target node, and sending the original shell command to the final target node for execution; receiving and formatting the execution result returned by the final target node, and sending the formatted execution result to the shell terminal. The present application uses a shell command extension tool compiled based on go language to extend the original shell command, which not only realizes the standardized processing of the execution result, but also adds a streaming return mechanism and a timeout processing mechanism, which is convenient for users to troubleshoot problems, and improves system performance and user experience.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software, and in particular to a shell command expansion method based on the Go language. Background Art

[0002] In today's digital age, enterprise services generally rely on an efficient server operating environment. Among them, the Linux operating system has become the first choice for many enterprises due to its stability, open source characteristics and extensive community support. Linux servers not only carry the operation of the core business of enterprises, but also undertake many key tasks such as data processing, storage, and network communication. Therefore, it is crucial for system administrators, developers, and operation and maintenance teams to master and efficiently use shell commands that interact with the Linux operating system. Shell commands are the way users interact with the operating system or application through the command line interface (CLI).

[0003] However, in daily Linux server management and operation and maintenance work, the frequent use of shell commands exposes a series of pain points, which not only affect work efficiency, but also may lead to errors and unnecessary complex operations. Specifically, they include the following aspects:

[0004] 1. Lack of timeout mechanism: Traditional shell commands often do not have a built-in timeout control function when they are executed. This means that for some commands that may be suspended for a long time due to network delays, resource competition or misconfiguration, their execution cannot be automatically terminated and can only be manually intervened by the user, which is not only inefficient but may also cause a waste of system resources.

[0005] 2. Inconsistent output formats: Shell commands have various output formats, some are displayed in plain text, and some contain complex nested structures or special characters. This diversity poses an obstacle to information extraction for users who are not familiar with shell commands, and increases the difficulty of data processing and analysis.

[0006] 3. Insufficient error handling capabilities: Traditional shell scripts often rely on simple conditional judgments in error handling, and lack sufficient flexibility and robustness for complex error scenarios. This causes some potential errors to be ignored, which in turn triggers a chain reaction and affects the overall performance and stability of the system.

[0007] 4. Lack of usability and scalability: With the continuous expansion of enterprise business, the demand for shell commands is becoming increasingly diverse. However, the traditional shell command system has limitations in usability and scalability, making it difficult to meet the growing customization needs and limiting the improvement of work efficiency.

[0008] In view of the above problems, the market urgently needs a solution that can effectively solve the pain points in the use of shell commands. Summary of the invention

[0009] The purpose of the present invention is to provide a shell command extension method based on the Go language to solve the problems in the prior art that the shell command lacks a timeout mechanism, has an inconsistent output format, has insufficient error handling capabilities, and lacks ease of use and scalability.

[0010] To achieve the above objectives, this application adopts the following technical solutions:

[0011] The present application provides a shell command extension method based on the Go language, comprising the following steps:

[0012] Editing a first configuration file for storing initial target node information for executing the original shell command in a shell terminal, and configuring command line parameters of a pre-built shell command expansion tool, wherein the command line parameters include mandatory parameters for specifying the original shell command and several optional parameters for specifying operations to be executed by the shell command expansion tool;

[0013] Starting the shell command expansion tool to use the shell command expansion tool to parse the first configuration file and the command line parameters to obtain the original shell command, the final target node information for executing the original shell command, and the operations to be executed by the shell command expansion tool;

[0014] Connecting to the corresponding final target node according to the operation to be executed and the final target node information, and after the connection is successful, sending the original shell command to the final target node for execution;

[0015] The execution result returned by the final target node is received and formatted, and the formatted execution result is sent to the shell terminal.

[0016] Preferably, the initial target node information includes the Internet Protocol address, port number, user name and login password of the initial target remote node, or the name of the initial target pod node in the cluster and the storage path of the cluster configuration file;

[0017] The optional parameters include parameters for specifying a timeout for executing the original shell command, parameters for specifying a name of the initial target pod node, parameters for specifying an Internet Protocol address of the initial target remote node, parameters for testing connectivity of the initial target remote node, parameters for specifying an Internet Protocol address of the initial target remote node for encrypting plaintext information, and parameters for specifying the address of the first configuration file.

[0018] Preferably, before parsing the first configuration file and the command line parameters using the shell command expansion tool, the method further includes:

[0019] The shell command extension tool is used to verify whether the Internet Protocol address or the name of the initial target pod node in the first configuration file conforms to a preset format. If not, the verification fails and the user is prompted to re-edit the first configuration file.

[0020] Preferably, if the command line parameters are parsed to obtain the original shell command and the timeout period, the shell terminal is taken as the final target node, and a timer is constructed to start the timer when the shell terminal executes the original shell command. When the shell terminal does not return the execution result to the shell command expansion tool within the timeout period, a timeout prompt is actively sent to the shell terminal to end the command execution process.

[0021] Preferably, if the command line parameters are parsed to obtain the name of the initial target pod node, and the name of the initial target pod node is the same as that in the first configuration file, the initial target pod node is used as the final target node, and the original shell command is directly sent to the initial target pod node through a remote control command tool.

[0022] Preferably, if the Internet Protocol address of the initial target remote node is obtained by parsing the command line parameters and the connectivity of the initial target remote node is tested, and the Internet Protocol address of the initial target remote node is the same as that in the first configuration file, the initial target remote node is used as the final target node, and the connectivity of the initial target remote node is tested through the secure shell protocol tool in the go language library.

[0023] Preferably, if the Internet Protocol address of the initial target remote node of the encrypted plaintext information is also obtained by parsing the command line parameters and its address is the same as that in the first configuration file, the login password of the initial target remote node is encrypted using a custom encryption tool and the login password in the first configuration file is replaced with the encrypted result, so that the encrypted result can be decrypted using the custom encryption tool when the shell command expansion tool obtains the encrypted result.

[0024] Preferably, if the result obtained by parsing the command line parameters does not include the address of the first configuration file, the first configuration file is stored locally.

[0025] Preferably, the method further comprises:

[0026] When there are multiple final target nodes, the sync.waitGroup tool in the go language library is used to send the original shell command to each final target node for execution, and wait for all final target nodes to return the execution results.

[0027] Preferably, the formatting of the execution result returned by the final target node includes:

[0028] Use the exec tool in the go language library to obtain the execution result returned by the final target node, wherein the execution result includes a standard output stream, a standard error output stream, and a status code indicating whether the execution is successful or not;

[0029] Using the bufio tool in the go language library, read the content in the standard output stream and the standard error output stream line by line, and classify the read content into normal information or error information according to the status code;

[0030] The final return result is constructed according to the status code and the classification result, and the final return result includes normal information, error information and status code.

[0031] The present invention has the following beneficial effects:

[0032] The original shell command is extended by using a shell command extension tool compiled based on the go language. This not only realizes the standardized processing of execution results, but also adds a streaming return mechanism to facilitate user troubleshooting and improve user readability. At the same time, by adding a timeout processing mechanism, it can also ensure that the system completes the operation within the specified time, thereby effectively avoiding indefinite waiting, improving system performance and user experience, and simplifying the cross-node operation process through the configured command line parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0034] Figure 1 It is a flowchart of a shell command expansion method based on the go language provided in an embodiment of the present application;

[0035] Figure 2 This is a system architecture diagram of a shell command expansion method based on the Go language implemented in this application. DETAILED DESCRIPTION

[0036] To make the technical solution of the present application clearer, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. The terms "first", "second", etc. in the claims and specification of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances. This is only to describe the distinction method used when describing objects with the same attributes in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that a process, method, system, product or device containing a series of units is not necessarily limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or devices.

[0037] Example 1

[0038] like Figure 1 As shown, a shell command extension method based on the go language includes the following steps:

[0039] S110, editing a first configuration file for storing information of an initial target node for executing an original shell command in a shell terminal, and configuring command line parameters of a pre-built shell command expansion tool, wherein the command line parameters include mandatory parameters for specifying the original shell command and several optional parameters for specifying operations to be executed by the shell command expansion tool;

[0040] S120, starting a shell command expansion tool to parse the first configuration file and command line parameters using the shell command expansion tool to obtain the original shell command, the final target node information for executing the original shell command, and the operations to be executed by the shell command expansion tool;

[0041] S130, connecting to the corresponding final target node according to the operation to be executed and the final target node information, and after the connection is successful, sending the original shell command to the final target node for execution;

[0042] S140: Receive and format the execution result returned by the final target node, and send the formatted execution result to the shell terminal.

[0043] like Figure 2As shown, the system architecture of this embodiment includes three parts: one is a shell terminal interface, the second is a pre-built shell command expansion tool, and the third is the final target node for executing the original shell command. Among them, the pre-built shell command expansion tool is essentially a binary file compiled in advance based on the go language. The binary file compiled based on the go language does not depend on the go compiler or other external libraries, can be directly run on the target platform, and also supports cross-platform compilation, that is, it can be compiled on one platform to generate binary files suitable for other platforms. For example, an application developed on the macOS operating system can be compiled to generate binary files suitable for the Linux operating system or the Windows operating system. Therefore, in this embodiment, only the compilation language of the shell command expansion tool is limited, and the specific compilation platform is not limited.

[0044] When users use the shell command expansion tool to expand shell commands, they must first configure the first configuration file (config.yml) in the shell terminal interface. The first configuration file is only used to save the initial target node information for executing the original shell command. The initial target node can be a remote node or a pod node in a Kubernetes (K8s for short) cluster. If more than one initial target node is set in the first config.yml, it can include both remote nodes and pod nodes, or only remote nodes or pod nodes.

[0045] When the initial target node is a remote node, the node information includes the Internet Protocol address, i.e., IP address (host), port number (port), user name (user), and login password (password); when the initial target node is a pod node in the K8s cluster, the node information includes the name of the pod node (podName) and the storage path of the K8s cluster configuration file (kubeconfig: / path).

[0046] Meanwhile, the initial target node may be the final target node or may not be the final target node, which is specifically determined by the command line parameters of the shell command expansion tool input by the user in the shell terminal interface.

[0047] The command line parameters include one mandatory parameter and multiple optional parameters. The mandatory parameter is --script (-s), which is used to specify the original shell command to be executed. The optional parameters are --timeout (-t), --pod (-p), --remoteExec (-rexec), --remotePing (-rp), --encryption (-et), and --configfile (-conf). Specifically, --timeout (-t) is used to specify the timeout for executing the original shell command in minutes. If it is not configured, it means there is no timeout limit; --pod (-p) is used to specify the name of the initial target pod node. If it is not configured, it means that even if the first config.yml is set Even if the initial target pod node information is set, the original shell command will not be sent to the initial target pod node; --remoteExec (-rexec) is used to specify the IP address of the initial target remote node. If it is not configured, it means that even if the initial target remote node information is set in the first config.yml, the original shell command will not be sent to the initial target remote node; --remotePing (-rp) is used to test the connectivity of the initial target remote node, and then determine the survivability of the initial target remote node; --encryption (-et) is used to specify the IP address of the initial target remote node of the encrypted plaintext information. The plaintext here actually refers to the login password. If it is not configured, it means that the login password in the first config.yml will not be encrypted; --configfile (-conf) is used to specify the address of the first configuration file. If it is not configured, the first config.yml is saved locally by default, and the information in it can be read directly.

[0048] It should also be noted that the optional parameters determine the operations to be performed by the shell command extension tool. At the same time, if --encryption (-et) is configured, --remoteExec (-rexec) and --remotePing (-rp) must also be configured; if any one or more of --pod (-p), --remoteExec (-rexec), --remotePing (-rp) and --encryption (-et) are configured, the initial target pod node name or initial target remote node IP address contained therein must also be the same as the corresponding content in the first config.yml.

[0049] The initial target node is the final target node only when the command line parameters entered by the user in the shell terminal interface include --pod (-p) or --remoteExec (-rexec), otherwise the local node, that is, the shell terminal, is the final target node.

[0050] After the configuration file and command line parameters are configured, start the shell command expansion tool. Specifically, first use the cd command in the shell terminal interface to enter the directory where the binary file compiled based on the go language is saved, then enter the binary file name, and then press Enter.

[0051] Furthermore, a shell command extension tool is used to verify whether the Internet Protocol address or the name of the initial target pod node in the first configuration file conforms to a preset format. If not, the verification fails, and the user is prompted to re-edit the first configuration file.

[0052] After starting the shell command expansion tool, first use the shell command expansion tool to verify the legitimacy of the IP address or the initial target pod node name in the first config.yml. Preferably, extract the IP address or the initial target pod node name, and determine whether the format of the IP address meets the corresponding specification requirements, such as whether it consists of a network number and a host number, or determine whether the format of the initial target pod node name meets the corresponding specification requirements, such as whether it only contains lowercase letters, numbers and hyphens (-) and does not start or end with a hyphen (-). If the format does not meet the corresponding specification requirements, the verification fails, and the user is prompted to reconfigure the first config.yml.

[0053] If the verification is successful, the shell command expansion tool is used to parse the command line parameters and the first config.yml. The essence is to determine the configured command line parameters. When the configured command line parameters include any one or more of --pod(-p), --remoteExec(-rexec), --remotePing(-rp), and --encryption(-et), whether the initial target pod node name or the initial target remote node IP address contained therein is the same as the corresponding content configured in the first config.yml. If different, it is regarded as an error and the user is prompted to reconfigure the command line parameters. If the same, the original shell command to be executed is determined according to the required parameter --script(-s), and the information of the final target node and the operation to be performed by the shell command expansion tool are determined according to the configured optional parameters.

[0054] Then, the connection method of the final target node is determined according to the operations to be executed by the shell command expansion tool, and the final target node is connected by using the connection method combined with the information of the final target node. After the connection is successful, the original shell command is sent to the final target node, so that the original shell command is executed on the final target node. After the execution of the original shell command is completed, the final target node returns the execution result to the shell command expansion tool. If the connection fails, a failure message is returned.

[0055] It should also be noted here that the sync.waitGroup tool in the go language standard library is used in this embodiment to manage concurrent tasks, that is, when there is not only one final target node, but two or more, the sync.waitGroup tool is used to send the original shell command to each final target node in parallel, and execute the original shell command on each final target node respectively, and then wait for each final target node to return the execution result. The sync.waitGroup tool is a structure in the go language standard library, which is used to wait for a group of goroutines to complete. It is usually used in concurrent programming to ensure that the main coroutine will not continue to execute before all related coroutines complete their tasks.

[0056] Specifically, in this embodiment, a sync.WaitGroup instance is first created. This instance is used to track the number of concurrent tasks and ensure that the main program waits for all tasks to be completed before continuing execution. Then, a concurrent task is started for each final target node, and the Add(1) method of WaitGroup is called to increase the WaitGroup counter. Then, for each final target node, a new goroutine is started using the go keyword. This new goroutine is responsible for connecting to the final target node and executing the original shell command. Then, the original shell command is executed on the final target node. Once the execution is completed (whether successful or failed), the goroutine will call the Done method of WaitGroup to reduce the WaitGroup counter, which also indicates that the task on the goroutine has been completed. At the same time, the main program (or main goroutine) will call the Wait method of WaitGroup, which will block the execution of the main program until all tasks added by the Add method are completed by the Done method.

[0057] It should be noted here that if a task encounters an error or exception during execution, it should handle these errors appropriately, for example, logging, retrying commands, or reporting errors to the user, and it still needs to call the Done method to reduce the WaitGroup's counter to ensure that the Wait method does not block forever.

[0058] Therefore, the shell command expansion tool will return the execution result to the shell terminal only when the original shell commands on all final target nodes are executed (whether successfully or failed) and all related errors are properly handled.

[0059] Furthermore, the execution result returned by the final target node is formatted, including:

[0060] Use the exec tool in the go language library to obtain the execution result returned by the final target node. The execution result includes the standard output stream, the standard error output stream, and the status code indicating whether the execution is successful or not;

[0061] Use the bufio tool in the Go language library to read the contents of the standard output stream and the standard error output stream line by line, and classify the read contents into normal information or error information according to the status code;

[0062] The final return result is constructed based on the status code and classification result. The final return result includes normal information, error information and status code.

[0063] The shell command expansion tool first uses the exec tool in the go language standard library to receive the execution result returned by the final target node. This execution result includes the standard output stream, the standard error output stream, and the status code indicating whether the execution is successful or not. Then, the bufio tool in the go language standard library is used to read the content in the standard output stream and the standard error output stream line by line, and the read content is divided into normal information or error information according to the status code. The status code is used to indicate whether the command is successfully executed. When the command is successfully executed and no errors are encountered, a status code indicating success is usually returned, such as 0, which also indicates that the corresponding content is a normal message. If the command encounters an error or exception during execution, a non-0 status code is returned, which indicates that the corresponding message is an error message. The specific value of this status code can be used to indicate the type or cause of the error. For example, some status codes may indicate that the command cannot be found, insufficient permissions, or parameter errors. Then, the final return result is constructed based on the division result and the status code. This final return result is in the form of a structure, which can contain normal information and status codes, or error information and status codes. Finally, the constructed final return result is sent to the shell terminal interface for display, so that users can easily identify error information.

[0064] This embodiment uses a shell command expansion tool compiled based on the go language to expand the original shell command, which not only realizes the standardized processing of the execution results, but also adds a streaming return mechanism to facilitate users to troubleshoot problems and improve user readability and user experience.

[0065] Example 2

[0066] On the basis of Example 1, a shell command expansion method based on the Go language also includes:

[0067] If the command line parameters are parsed to obtain the original shell command and timeout period, the shell terminal is used as the final target node, and a timer is constructed to start the timer when the shell terminal executes the original shell command. When the shell terminal does not return the execution result to the shell command expansion tool within the timeout period, a timeout prompt is actively sent to the shell terminal to end the command execution process.

[0068] When the shell command expansion tool parses the command line parameters and the first config.yml, it first parses the command line parameters. If the result of the analysis is the original shell command and the timeout period, that is, the configured command line parameters are only two --script (-s) and --timeout (-t), then the operation to be executed by the shell command expansion tool is the timeout processing mechanism. Specifically, a timer is constructed, and the shell terminal, that is, the local node, is used as the final target node. Then, the original shell command is sent to the local node for execution. When it is executed, the shell command expansion tool starts the timer. When the timeout period arrives, if the local node has not returned the execution result to the shell command expansion tool, it actively returns a timeout prompt to the local node to terminate the execution process of the original shell command. Then, the local node returns a "failed" execution result to the shell command expansion tool. The shell command expansion tool formats the execution result and returns the formatted execution result to the shell terminal interface.

[0069] This embodiment adds a timeout processing mechanism based on the original shell command to ensure that the system completes the operation within the specified time, which can effectively avoid indefinite waiting, improve system performance, and optimize user experience.

[0070] In some embodiments, --script (-s) can be configured independently. When it is configured independently, it means that there is no timeout limit. The shell command expansion tool only needs to wait for the execution result returned by the local node (whether successful or failed). After receiving the execution result, it formats the execution result and then returns the formatted execution result to the shell terminal interface.

[0071] Optionally, if the command line parameters are parsed to obtain the name of the initial target pod node, and the name of the initial target pod node is the same as that in the first configuration file, the initial target pod node is used as the final target node, and the original shell command is directly sent to the initial target pod node through the remote control command tool.

[0072] In an optional embodiment, if the result obtained by parsing also contains the name of the initial target pod node, that is, the configured command line parameters include --script (-s), --timeout (-t) and --pod (-p), and the name of the initial target pod node obtained by parsing is the same as the name of the initial target pod node configured in the first config.yml, then the to-be-executed operation of the shell command expansion tool is the timeout processing mechanism and the mechanism for the specific delivery of the original shell command to the pod node. Specifically, the shell command expansion tool uses the initial target pod node as the final target node and builds a timer, and then directly delivers the original shell command to the initial target pod node for execution through the remote control command (remotecommand) tool, and when it is executed, the timer is started and the timeout time is reached. If the initial target pod node has not returned the execution result to the shell command expansion tool, the shell command expansion tool will actively return a timeout prompt to the initial target pod node to terminate the execution process of the original shell command, wherein the remotecommand tool is a mechanism that allows users to remotely execute specific commands or operations. This embodiment simplifies the cross-node operation process.

[0073] In another optional embodiment, when the configured command line parameters include only --script (-s) and --pod (-p) but not --timeout (-t), the timeout processing mechanism in the previous optional embodiment is removed, and the rest of the process is the same.

[0074] Optionally, if the result obtained by parsing the command line parameters does not include the first configuration file address, the first configuration file is stored locally.

[0075] If the parsed result does not include the address of the first config.yml, that is, the configuration command line parameter does not contain --configfile (-conf), it means that the first config.yml is stored locally, and the first config.yml in the current directory can be read directly by default.

[0076] In another optional embodiment, if the result obtained by parsing includes the address of the first config.yml, it means that the first config.yml is not saved locally. At this time, the to-be-executed operations of the shell command extension tool also include a reading mechanism for the first config.yml. Specifically, the information in the first config.yml is read through the yml editor in the go language third party according to the address specified by --configfile (-conf), that is, the yml editor in the go language third party first reads the content of the first config.yml and parses it into a go data structure, then modifies the value in the data structure, and then encodes the modified data structure back into a string in YAML format, and writes it back to the YAML file, i.e., the first config.yml.

[0077] Example 3

[0078] On the basis of Example 2, a shell command expansion method based on the Go language also includes:

[0079] If the command line parameters are parsed to obtain the Internet Protocol address of the initial target remote node and the connectivity test is performed on the initial target remote node, and the Internet Protocol address of the initial target remote node is the same as that in the first configuration file, the initial target remote node is used as the final target node, and the connectivity of the initial target remote node is tested through the secure shell protocol tool in the go language library.

[0080] On the basis of Example 2, if the result obtained by parsing also includes the IP address of the initial target remote node, and the connectivity test of the initial target remote node, and the IP address of the initial target remote node is the same as the IP address of the initial target remote node in the first config.yml, at this time, the to-be-executed operation of the shell command expansion tool also includes a mechanism for sending the original shell command to the remote node. Specifically, the initial target remote node is used as the final target node, and the connectivity of the initial target remote node is tested through the secure shell protocol (ssh) tool in the go language third-party library. If the test passes, the original shell command is sent to the initial target remote node, wherein the secure shell protocol (ssh) tool in the go language third-party library allows the go program to communicate with the remote server through the SSH protocol.

[0081] Optionally, if the parsing of the command line parameters also obtains the Internet Protocol address of the initial target remote node of the encrypted plaintext information and its address is the same as that in the first configuration file, a custom encryption tool is used to encrypt the login password of the initial target remote node and the encrypted result is used to replace the login password in the first configuration file, so that the encrypted result can be decrypted using the custom encryption tool when the shell command expansion tool obtains the encrypted result.

[0082] In an optional embodiment, if the result obtained by parsing also includes the IP address of the initial target remote node of the encrypted plaintext information, and the IP address is the same as the IP address of the initial target remote node in the first config.yml, then the to-be-executed operation of the shell command expansion tool also includes encrypting and decrypting the login password of the initial target remote node in the first config.yml. Specifically, the initial target remote node is used as the final target node, and based on AdvancedEncryption Standard (AES, Advanced Encryption Standard) algorithm uses go language to customize an encryption tool, uses the customized encryption tool to encrypt the login password of the initial target remote node in the first config.yml, and replaces the login password in the first config.yml with the encrypted result. When the shell command expansion tool obtains the encrypted login password, the customized encryption tool is used to decrypt the encryption result to obtain the original login password, which can prevent the password leakage problem caused by the first config.yml being sent incorrectly. Among them, the encryption principle of the customized encryption tool is to first obtain the data size of the key and generate the original encryption block, and then divide the data to be encrypted, that is, the login password, according to the size of the original encryption block. The divided data that is less than the size of the original encryption block is filled with a sufficient number of spaces at the end, and finally NewCipher is called to create an AES encryptor, and the filled login password is encrypted with this AES encryptor.

[0083] It should also be noted here that, except that --script (-s) is a command line parameter that must be configured and --encryption (-et) must be configured together with --remoteExec (-rexec) and --remotePing (-rp), users can arbitrarily match other optional parameters according to actual needs. In this embodiment, all possible pending operations of the shell command expansion tool have been given. Other unlisted situations are to superimpose the pending operations of the shell command expansion tool. Therefore, they will not be repeated.

[0084] The above-mentioned embodiments only express several implementation methods of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A shell command expansion method based on go language, characterized in that: The following steps are involved: Editing a first configuration file for storing information of an initial target node for executing an original shell command in a shell terminal, and configuring command line parameters of a pre-built shell command expansion tool, wherein the command line parameters include a required parameter --script for specifying the original shell command and several optional parameters for specifying operations to be performed by the shell command expansion tool, wherein the several optional parameters include a parameter for specifying a timeout for executing the original shell command, a parameter for specifying a name of the initial target pod node, a parameter for specifying an Internet Protocol address of an initial target remote node, a parameter for testing connectivity of the initial target remote node, a parameter for specifying an Internet Protocol address of an initial target remote node for encrypting plaintext information, and a parameter for specifying the address of the first configuration file; Starting the shell command expansion tool to use the shell command expansion tool to parse the first configuration file and the command line parameters to obtain the original shell command, the final target node information for executing the original shell command, and the operations to be executed by the shell command expansion tool; Connecting to the corresponding final target node according to the operation to be executed and the final target node information, and sending the original shell command to the final target node for execution after the connection is successful; Receive and format the execution result returned by the final target node, and send the formatted execution result to the shell terminal; Among them, if the command line parameters are parsed to obtain the original shell command and timeout period, the shell terminal is taken as the final target node, and a timer is constructed to start the timer when the shell terminal executes the original shell command. When the shell terminal does not return the execution result to the shell command expansion tool within the timeout period, a timeout prompt is actively sent to the shell terminal to end the command execution process.

2. A shell command expansion method based on go language according to claim 1, characterized in that: The initial target node information includes the Internet Protocol address, port number, user name and login password of the initial target remote node, or the name of the initial target pod node in the cluster and the storage path of the cluster configuration file.

3. A shell command expansion method based on go language according to claim 2, characterized in that: Before parsing the first configuration file and the command line parameter using the shell command expansion tool, the method further includes: The shell command extension tool is used to verify whether the Internet Protocol address or the name of the initial target pod node in the first configuration file conforms to a preset format. If not, the verification fails and the user is prompted to re-edit the first configuration file.

4. A shell command expansion method based on go language according to claim 3, characterized in that: If the command line parameters are parsed to obtain the name of the initial target pod node, and the name of the initial target pod node is the same as that in the first configuration file, the initial target pod node is used as the final target node, and the original shell command is directly sent to the initial target pod node through the remote control command tool.

5. A shell command expansion method based on go language according to any one of claims 3 or 4, characterized in that: If the Internet Protocol address of the initial target remote node is obtained by parsing the command line parameters and the connectivity test is performed on the initial target remote node, and the Internet Protocol address of the initial target remote node is the same as that in the first configuration file, the initial target remote node is used as the final target node, and the connectivity of the initial target remote node is tested through the secure shell protocol tool in the go language library.

6. A shell command expansion method based on go language according to claim 5, characterized in that: If the Internet Protocol address of the initial target remote node of the encrypted plaintext information is also obtained by parsing the command line parameters and its address is the same as that in the first configuration file, the login password of the initial target remote node is encrypted using a custom encryption tool and the login password in the first configuration file is replaced with the encryption result, so that the encryption result can be decrypted using the custom encryption tool when the shell command expansion tool obtains the encryption result.

7. A shell command expansion method based on go language according to any one of claims 3, 4 or 6, characterized in that: If the result obtained by parsing the command line parameters does not include the first configuration file address, the first configuration file is stored locally.

8. The shell command expansion method based on go language according to claim 1, characterized in that: The method further comprises: When there are multiple final target nodes, the sync.waitGroup tool in the go language library is used to send the original shell command to each final target node for execution, and wait for all final target nodes to return the execution results.

9. The shell command expansion method based on go language according to claim 1, characterized in that: The formatting of the execution result returned by the final target node includes: Use the exec tool in the go language library to obtain the execution result returned by the final target node, wherein the execution result includes a standard output stream, a standard error output stream, and a status code indicating whether the execution is successful or not; Using the bufio tool in the go language library, read the content in the standard output stream and the standard error output stream line by line, and classify the read content into normal information or error information according to the status code; The final returned result is constructed according to the status code and the classification result, and the final returned result includes normal information, error information and status code.

Images