More

How to invoke a WFS service from command line?

How to invoke a WFS service from command line?


I've the following WFS GetFeature request…

http://map.sitr.regione.sicilia.it/ArcGIS/services/CART_2000/Numeri_Civici/GeoDataServer/WFSServer?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=CART_2000:NumeriCivici_88006_Modica&SRSNAME=EPSG:3004&

… and the response (that you can try… ), give me a GML response that I can use in a GIS Desktop.

I need to invoke this, and several other services like it, from command line and save the responses in files: any suggestions (curl? wget? other?) and samples on how to do it?


To save this response in agmlfile you can do the following:

curl http://map.sitr.regione.sicilia.it… -o ~/Desktop/test.gml

(I was not able to get your url to work)


Adam the Automator

IT professionals rarely work just on our local computer. Using the PowerShell Invoke-Command cmdlet, we don’t have to! This cmdlet allows us to seamlessly write code as if we were working on our local computer.

By using the PowerShell Remoting feature, The Invoke-Command cmdlet is a commonly used PowerShell cmdlet that allows the user to execute code inside of a PSSession. This PSSession can either be one created previously with the New-PSSession cmdlet or it can quickly create and tear down a temporary session as well.

Think of Invoke-Command as the PowerShell psexec. Though they are implemented differently, the concept is the same. Take a bit code or command and run it “locally” on the remote computer.

For Invoke-Command to work though, you must have PowerShell Remoting enabled and available on the remote computer. By default, all Windows Server 2012 R2 or later machines do have it enabled along with the appropriate firewall exceptions. If you’re unfortunate enough to still have Server 2008 machines, there are multiple ways to set up Remoting but an easy way is by running winrm quickconfig or Enable-PSRemoting on the remote machine.

To demonstrate how Invoke-Command works with an “ad-hoc command” meaning one that doesn’t require a new PSSession to be created, let’s say you’ve got a remote Windows Server 2012 R2 or later domain-joined computer. Things get a little messy when working on workgroup computers. I’ll open up my PowerShell console, type Invoke-Command and hit Enter.

I’m immediately asked to provide a scriptblock. The scriptblock is the code that we’re going to run on the remote computer.

So that we can prove that the code inside of the scriptblock is executed on the remote computer, let’s just run the hostname command. This command will return the hostname of the computer it is running on. Running hostname on my local computer yields, it’s name.

Let’s now pass a scriptblock with that same code inside of a scriptblock to Invoke-Command . Before we do that though, we’re forgetting a required parameter: ComputerName . We have to tell Invoke-Command what remote computer to run this command on.

Notice that the output of hostname is now the name of the remote computer WEBSRV1 . You’ve run some code on WEBSRV1. Running simple code inside of a scriptblock and passing to a single remote machine is the easiest application of Invoke-Command but it can do so much more.


1 Answer 1

You are correct in that sc won't manipulate these settings. These settings are stored in the "FailureActions" REG_BINARY value, which is mostly opaque in nature. Your best bet would be to set the value as you want it on a test service then export the registry value. You would just import it after you use sc to create the service in your deployment script.

The API to manipulate these settings is ChangeServiceConfig2, and it's conceivable that you could code something to manipulate the values as you desire if you need flexibility.


Parameters

Allows redirection of this connection to an alternate Uniform Resource Identifier (URI).

When you use the ConnectionURI parameter, the remote destination can return an instruction to redirect to a different URI. By default, PowerShell doesn't redirect connections, but you can use this parameter to allow it to redirect the connection.

You can also limit the number of times the connection is redirected by changing the MaximumConnectionRedirectionCount session option value. Use the MaximumRedirection parameter of the New-PSSessionOption cmdlet or set the MaximumConnectionRedirectionCount property of the $PSSessionOption preference variable. The default value is 5.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies the application name segment of the connection URI. Use this parameter to specify the application name when you aren't using the ConnectionURI parameter in the command.

The default value is the value of the $PSSessionApplicationName preference variable on the local computer. If this preference variable isn't defined, the default value is WSMAN. This value is appropriate for most uses. For more information, see about_Preference_Variables.

The WinRM service uses the application name to select a listener to service the connection request. The value of this parameter should match the value of the URLPrefix property of a listener on the remote computer.

Type:String
Position:Named
Default value:$PSSessionApplicationName if set on the local computer, otherwise WSMAN
Accept pipeline input:True
Accept wildcard characters:False

Supplies the values of local variables in the command. The variables in the command are replaced by these values before the command is run on the remote computer. Enter the values in a comma-separated list. Values are associated with variables in the order that they're listed. The alias for ArgumentList is Args.

The values in the ArgumentList parameter can be actual values, such as 1024, or they can be references to local variables, such as $max .

To use local variables in a command, use the following command format:

The param keyword lists the local variables that are used in the command. ArgumentList supplies the values of the variables, in the order that they're listed. For more information about the behavior of ArgumentList, see about_Splatting.

Type:Object [ ]
Aliases:Args
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Indicates that this cmdlet runs the command as a background job on a remote computer. Use this parameter to run commands that take an extensive time to finish.

When you use the AsJob parameter, the command returns an object that represents the job, and then displays the command prompt. You can continue to work in the session while the job finishes. To manage the job, use the *-Job cmdlets. To get the job results, use the Receive-Job cmdlet.

The AsJob parameter resembles using the Invoke-Command cmdlet to run a Start-Job cmdlet remotely. However, with AsJob, the job is created on the local computer, even though the job runs on a remote computer. The results of the remote job are automatically returned to the local computer.

For more information about PowerShell background jobs, see about_Jobs and about_Remote_Jobs.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies the mechanism that's used to authenticate the user's credentials. CredSSP authentication is available only in Windows Vista, Windows Server 2008, and later versions of the Windows operating system.

The acceptable values for this parameter are as follows:

  • Default
  • Basic
  • Credssp
  • Digest
  • Kerberos
  • Negotiate
  • NegotiateWithImplicitCredential

The default value is Default.

For more information about the values of this parameter, see AuthenticationMechanism Enumeration.

Credential Security Support Provider (CredSSP) authentication, in which the user's credentials are passed to a remote computer to be authenticated, is designed for commands that require authentication on more than one resource, such as accessing a remote network share. This mechanism increases the security risk of the remote operation. If the remote computer is compromised, the credentials that are passed to it can be used to control the network session. For more information, see Credential Security Support Provider.

Type:AuthenticationMechanism
Accepted values:Basic, Default, Credssp, Digest, Kerberos, Negotiate, NegotiateWithImplicitCredential
Position:Named
Default value:Default
Accept pipeline input:False
Accept wildcard characters:False

Specifies the digital public key certificate (X509) of a user account that has permission to connect to the disconnected session. Enter the certificate thumbprint of the certificate.

Certificates are used in client certificate-based authentication. They can be mapped only to local user accounts and they don't work with domain accounts.

To get a certificate thumbprint, use a Get-Item or Get-ChildItem command in the PowerShell Cert: drive.

Type:String
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Specifies the computers on which the command runs. The default is the local computer.

When you use the ComputerName parameter, PowerShell creates a temporary connection that's used only to run the specified command and is then closed. If you need a persistent connection, use the Session parameter.

Type the NETBIOS name, IP address, or fully qualified domain name of one or more computers in a comma-separated list. To specify the local computer, type the computer name, localhost, or a dot ( . ).

To use an IP address in the value of ComputerName, the command must include the Credential parameter. The computer must be configured for the HTTPS transport or the IP address of the remote computer must be included in the local computer's WinRM TrustedHosts list. For instructions to add a computer name to the TrustedHosts list, see How to Add a Computer to the Trusted Host List.

On Windows Vista and later versions of the Windows operating system, to include the local computer in the value of ComputerName, you must run PowerShell using the Run as administrator option.

Type:String [ ]
Aliases:Cn
Position:0
Default value:Local computer
Accept pipeline input:False
Accept wildcard characters:False

Specifies the session configuration that is used for the new PSSession.

Enter a configuration name or the fully qualified resource URI for a session configuration. If you specify only the configuration name, the following schema URI is prepended: http://schemas.microsoft.com/PowerShell .

When used with SSH, this parameter specifies the subsystem to use on the target as defined in sshd_config . The default value for SSH is the powershell subsystem.

The session configuration for a session is located on the remote computer. If the specified session configuration doesn't exist on the remote computer, the command fails.

The default value is the value of the $PSSessionConfigurationName preference variable on the local computer. If this preference variable isn't set, the default is Microsoft.PowerShell. For more information, see about_Preference_Variables.

Type:String
Position:Named
Default value:$PSSessionConfigurationName if set on the local computer, otherwise Microsoft.PowerShell
Accept pipeline input:True
Accept wildcard characters:False

Specifies a Uniform Resource Identifier (URI) that defines the connection endpoint of the session. The URI must be fully qualified.

The format of this string is as follows:

The default value is as follows:

If you don't specify a connection URI, you can use the UseSSL and Port parameters to specify the connection URI values.

Valid values for the Transport segment of the URI are HTTP and HTTPS. If you specify a connection URI with a Transport segment, but don't specify a port, the session is created with the standards ports: 80 for HTTP and 443 for HTTPS. To use the default ports for PowerShell remoting, specify port 5985 for HTTP or 5986 for HTTPS.

If the destination computer redirects the connection to a different URI, PowerShell prevents the redirection unless you use the AllowRedirection parameter in the command.

Type:Uri [ ]
Aliases:URI, CU
Position:0
Default value:http://localhost:5985/WSMAN
Accept pipeline input:False
Accept wildcard characters:False

Specifies an array of container IDs.

Type:String [ ]
Position:Named
Default value:None
Accept pipeline input:True
Accept wildcard characters:False

Specifies a user account that has permission to perform this action. The default is the current user.

Type a user name, such as User01 or Domain01User01, or enter a PSCredential object generated by the Get-Credential cmdlet. If you type a user name, you're prompted to enter the password.

Credentials are stored in a PSCredential object and the password is stored as a SecureString.

For more information about SecureString data protection, see How secure is SecureString?.

Type:PSCredential
Position:Named
Default value:Current user
Accept pipeline input:True
Accept wildcard characters:False

Indicates that this cmdlet adds an interactive security token to loopback sessions. The interactive token lets you run commands in the loopback session that get data from other computers. For example, you can run a command in the session that copies XML files from a remote computer to the local computer.

A loopback session is a PSSession that originates and ends on the same computer. To create a loopback session, omit the ComputerName parameter or set its value to dot ( . ), localhost, or the name of the local computer.

By default, loopback sessions are created using a network token, which might not provide sufficient permission to authenticate to remote computers.

The EnableNetworkAccess parameter is effective only in loopback sessions. If you use EnableNetworkAccess when you create a session on a remote computer, the command succeeds, but the parameter is ignored.

You can allow remote access in a loopback session using the CredSSP value of the Authentication parameter, which delegates the session credentials to other computers.

To protect the computer from malicious access, disconnected loopback sessions that have interactive tokens, which are those created using EnableNetworkAccess, can be reconnected only from the computer on which the session was created. Disconnected sessions that use CredSSP authentication can be reconnected from other computers. For more information, see Disconnect-PSSession .

This parameter was introduced in PowerShell 3.0.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies a local script that this cmdlet runs on one or more remote computers. Enter the path and filename of the script, or pipe a script path to Invoke-Command . The script must exist on the local computer or in a directory that the local computer can access. Use ArgumentList to specify the values of parameters in the script.

When you use this parameter, PowerShell converts the contents of the specified script file to a script block, transmits the script block to the remote computer, and runs it on the remote computer.

Type:String
Aliases:PSPath
Position:1
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Indicates that this cmdlet omits the computer name of each object from the output display. By default, the name of the computer that generated the object appears in the display.

This parameter affects only the output display. It doesn't change the object.

Type:SwitchParameter
Aliases:HCN
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies an array of computer names for a Secure Shell (SSH) based connection. This is similar to the ComputerName parameter except that the connection to the remote computer is made using SSH rather than Windows WinRM.

This parameter was introduced in PowerShell 6.0.

Type:String [ ]
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Indicates that this cmdlet runs a command or script in a disconnected session.

When you use the InDisconnectedSession parameter, Invoke-Command creates a persistent session on each remote computer, starts the command specified by the ScriptBlock or FilePath parameter, and then disconnects from the session. The commands continue to run in the disconnected sessions. InDisconnectedSession enables you to run commands without maintaining a connection to the remote sessions. And, because the session is disconnected before any results are returned, InDisconnectedSession makes sure that all command results are returned to the reconnected session, instead of being split between sessions.

You can't use InDisconnectedSession with the Session parameter or the AsJob parameter.

Commands that use InDisconnectedSession return a PSSession object that represents the disconnected session. They don't return the command output. To connect to the disconnected session, use the Connect-PSSession or Receive-PSSession cmdlets. To get the results of commands that ran in the session, use the Receive-PSSession cmdlet. To run commands that generate output in a disconnected session, set the value of the OutputBufferingMode session option to Drop. If you intend to connect to the disconnected session, set the idle time-out in the session so that it provides sufficient time for you to connect before deleting the session.

You can set the output buffering mode and idle time-out in the SessionOption parameter or in the $PSSessionOption preference variable. For more information about session options, see New-PSSessionOption and about_Preference_Variables.

For more information about the Disconnected Sessions feature, see about_Remote_Disconnected_Sessions.

This parameter was introduced in PowerShell 3.0.

Type:SwitchParameter
Aliases:Disconnected
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies input to the command. Enter a variable that contains the objects or type a command or expression that gets the objects.

When using the InputObject parameter, use the $Input automatic variable in the value of the ScriptBlock parameter to represent the input objects.

Type:PSObject
Position:Named
Default value:None
Accept pipeline input:True
Accept wildcard characters:False

Specifies a friendly name for the background job. By default, jobs are named Job<n> , where <n> is an ordinal number.

If you use the JobName parameter in a command, the command is run as a job, and Invoke-Command returns a job object, even if you don't include AsJob in the command.

For more information about PowerShell background jobs, see about_Jobs.

Type:String
Position:Named
Default value:Job<n>
Accept pipeline input:False
Accept wildcard characters:False

Specifies a key file path used by Secure Shell (SSH) to authenticate a user on a remote computer.

SSH allows user authentication to be performed via private and public keys as an alternative to basic password authentication. If the remote computer is configured for key authentication, then this parameter can be used to provide the key that identifies the user.

This parameter was introduced in PowerShell 6.0.

Type:String
Aliases:IdentityFilePath
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Indicates that this cmdlet runs the specified command in the current scope. By default, Invoke-Command runs commands in their own scope.

This parameter is valid only in commands that are run in the current session, that is, commands that omit both the ComputerName and Session parameters.

This parameter was introduced in PowerShell 3.0.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies the network port on the remote computer that is used for this command. To connect to a remote computer, the remote computer must be listening on the port that the connection uses. The default ports are 5985 (WinRM port for HTTP) and 5986 (WinRM port for HTTPS).

Before using an alternate port, configure the WinRM listener on the remote computer to listen at that port. To configure the listener, type the following two commands at the PowerShell prompt:

Remove-Item -Path WSMan:Localhostlistenerlistener* -Recurse

New-Item -Path WSMan:Localhostlistener -Transport http -Address * -Port <port-number>

Don't use the Port parameter unless you must. The port that is set in the command applies to all computers or sessions on which the command runs. An alternate port setting might prevent the command from running on all computers.

Type:Int32
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Used to run the invoked command in debug mode in the remote PowerShell session.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Indicates that this cmdlet invokes a command as an Administrator.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies the commands to run. Enclose the commands in curly braces < >to create a script block. This parameter is required.

By default, any variables in the command are evaluated on the remote computer. To include local variables in the command, use ArgumentList.

Type:ScriptBlock
Aliases:Command
Position:0
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Specifies an array of sessions in which this cmdlet runs the command. Enter a variable that contains PSSession objects or a command that creates or gets the PSSession objects, such as a New-PSSession or Get-PSSession command.

When you create a PSSession, PowerShell establishes a persistent connection to the remote computer. Use a PSSession to run a series of related commands that share data. To run a single command or a series of unrelated commands, use the ComputerName parameter. For more information, see about_PSSessions.

Type:PSSession [ ]
Position:0
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Specifies a friendly name for a disconnected session. You can use the name to refer to the session in subsequent commands, such as a Get-PSSession command. This parameter is valid only with the InDisconnectedSession parameter.

This parameter was introduced in PowerShell 3.0.

Type:String [ ]
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Specifies advanced options for the session. Enter a SessionOption object, such as one that you create using the New-PSSessionOption cmdlet, or a hash table in which the keys are session option names and the values are session option values.

The default values for the options are determined by the value of the $PSSessionOption preference variable, if it's set. Otherwise, the default values are established by options set in the session configuration.

The session option values take precedence over default values for sessions set in the $PSSessionOption preference variable and in the session configuration. However, they don't take precedence over maximum values, quotas, or limits set in the session configuration.

For a description of the session options that includes the default values, see New-PSSessionOption . For information about the $PSSessionOption preference variable, see about_Preference_Variables. For more information about session configurations, see about_Session_Configurations.

Type:PSSessionOption
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

This parameter takes an array of hash tables where each hash table contains one or more connection parameters needed to establish a Secure Shell (SSH) connection. The SSHConnection parameter is useful for creating multiple sessions where each session requires different connection information.

The hashtable has the following members:

  • ComputerName (or HostName)
  • Port
  • UserName
  • KeyFilePath (or IdentityFilePath)

ComputerName (or HostName) is the only key-value pair that is required.

This parameter was introduced in PowerShell 6.0.

Type:Hashtable [ ]
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Indicates that the remote connection is established using Secure Shell (SSH).

By default PowerShell uses Windows WinRM to connect to a remote computer. This switch forces PowerShell to use the HostName parameter for establishing an SSH based remote connection.

This parameter was introduced in PowerShell 6.0.

Type:SwitchParameter
Accepted values:true
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies the SSH subsystem used for the new PSSession.

This specifies the subsystem to use on the target as defined in sshd_config. The subsystem starts a specific version of PowerShell with predefined parameters. If the specified subsystem does not exist on the remote computer, the command fails.

If this parameter is not used, the default is the 'powershell' subsystem.

Type:String
Position:Named
Default value:powershell
Accept pipeline input:True
Accept wildcard characters:False

Specifies the maximum number of concurrent connections that can be established to run this command. If you omit this parameter or enter a value of 0, the default value, 32, is used.

The throttle limit applies only to the current command, not to the session or to the computer.

Type:Int32
Position:Named
Default value:32
Accept pipeline input:False
Accept wildcard characters:False

Specifies the username for the account used to run a command on the remote computer. The user authentication method depends on how Secure Shell (SSH) is configured on the remote computer.

If SSH is configured for basic password authentication, then you'll be prompted for the user password.

If SSH is configured for key-based user authentication then a key file path can be provided via the KeyFilePath parameter and no password prompt occurs. If the client user key file is located in an SSH known location, then the KeyFilePath parameter isn't needed for key-based authentication, and user authentication occurs automatically based on the username. For more information, see your platform's SSH documentation about key-based user authentication.

This isn't a required parameter. If the UserName parameter isn't specified, then the current logged on username is used for the connection.

This parameter was introduced in PowerShell 6.0.

Type:String
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Indicates that this cmdlet uses the Secure Sockets Layer (SSL) protocol to establish a connection to the remote computer. By default, SSL isn't used.

WS-Management encrypts all PowerShell content transmitted over the network. The UseSSL parameter is an additional protection that sends the data across an HTTPS, instead of HTTP.

If you use this parameter, but SSL isn't available on the port that's used for the command, the command fails.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

Specifies an array of IDs of virtual machines.

Type:Guid [ ]
Aliases:VMGuid
Position:0
Default value:None
Accept pipeline input:True
Accept wildcard characters:False

Specifies an array of names of virtual machines.

Type:String [ ]
Position:Named
Default value:None
Accept pipeline input:True
Accept wildcard characters:False


2 Answers 2

. I've come across a great, universal tool: command-line fuzzy finder.

It primarily allows you to “fuzzy-find” files (check the rich gif animation by the link above), but it also allows to feed arbitrary text data to it and filter this data. So, the shortcuts idea is simple: all we need is to maintain a file with paths (which are shortcuts), and fuzzy-filter this file. Here's how it looks: we type cdg command (from “cd global”, if you like), get a list of our bookmarks, pick the needed one in just a few keystrokes, and press Enter. Working directory is changed to the picked item:

It is extremely fast and convenient: usually I just type 3-4 letters of the needed item, and all others are already filtered out.

It may not be what you're looking for, but the Vim editor with the CtrlP plugin can be used for this:

You'll need to install one of vim , vim-nox , vim-gnome , vim-gtk or vim-athena for this to work. Installation instructions for CtrlP are provided in its website:

  1. Clone the plugin into a separate directory:

  2. Add to your

If you have never used Vim before, it can be a bit intimidating. Run vimtutor to get an idea of it.


pstree gives me processes as below,

With this, I think, it can be decided.

I'm not completely sure, but since runit uses a supervisor, you should be able to recognize it from looking at the process tree, i.e. from the output of ps faux or, if it's installed, pstree .

You could also just ask runit , i.e. run sv status nginx .

Note however that if all you did was install runit , possibly nothing got switched to use it instead of "plain" init . You can examine /proc/cmdline for an occurrence of init=/sbin/runit-init .

If you need your services to have a common control interface, it may be better to mimic init.d script behavior with sv command. If sv is called as a /etc/init.d/NAME command , it automatically translates this to sv command NAME .

If you run some service (let's say ssh) under runit supervisor, you can do the following:

Rename current init script:

Create symlink with the same name:

Now you can manage your service with familiar commands like this:

Having symlink will cause some complaints about LSB-headers, though. So it's even better not to have symlink, but to create a wrapper script like this:

This way you can manage services the same way, whether they're being under runit or not.


Developer command file locations

If you prefer to set the build environment in an existing command prompt window, you can use one of the command files created by the installer. We recommend you set the environment in a new command prompt window. We don't recommend you later switch environments in the same command window.

The command file location depends on the version of Visual Studio you installed, and on choices you made during installation. For Visual Studio 2019, the typical installation location on a 64-bit system is in Program Files (x86)Microsoft Visual Studio2019edition. Edition may be Community, Professional, Enterprise, BuildTools, or another nickname you supplied.

The command file location depends on the version of Visual Studio you installed, and on choices you made during installation. For Visual Studio 2017, the typical installation location on a 64-bit system is in Program Files (x86)Microsoft Visual Studio2017edition. Edition may be Community, Professional, Enterprise, BuildTools, or another nickname you supplied.

The command file location depends on the Visual Studio version, and the installation directory. For Visual Studio 2015, the typical installation location is in Program Files (x86)Microsoft Visual Studio 14.0.

The primary developer command prompt command file, VsDevCmd.bat , is located in the Common7Tools subdirectory. When no parameters are specified, it sets the environment to use the x86-native tools to build 32-bit x86 code.

More command files are available to set up specific build architectures. The command files available depend on the Visual Studio workloads and options you've installed. In Visual Studio 2017 and Visual Studio 2019, you'll find them in the VCAuxiliaryBuild subdirectory.

More command files are available to set up specific build architectures. The command files available depend on the Visual Studio workloads and options you've installed. In Visual Studio 2015, they're located in the VC, VCin, or VCinarchitecture subdirectories, where architecture is one of the native or cross-compiler options.

These command files set default parameters and call VsDevCmd.bat to set up the specified build architecture environment. A typical installation may include these command files:

Command File Host and Target architectures
vcvars32.bat Use the 32-bit x86-native tools to build 32-bit x86 code.
vcvars64.bat Use the 64-bit x64-native tools to build 64-bit x64 code.
vcvarsx86_amd64.bat Use the 32-bit x86-native cross tools to build 64-bit x64 code.
vcvarsamd64_x86.bat Use the 64-bit x64-native cross tools to build 32-bit x86 code.
vcvarsx86_arm.bat Use the 32-bit x86-native cross tools to build ARM code.
vcvarsamd64_arm.bat Use the 64-bit x64-native cross tools to build ARM code.
vcvarsx86_arm64.bat Use the 32-bit x86-native cross tools to build ARM64 code.
vcvarsamd64_arm64.bat Use the 64-bit x64-native cross tools to build ARM64 code.
vcvarsall.bat Use parameters to specify the host and target architectures, Windows SDK, and platform choices. For a list of supported options, call by using a /help parameter.

The vcvarsall.bat file and other Visual Studio command files can vary from computer to computer. Do not replace a missing or damaged vcvarsall.bat file by using a file from another computer. Rerun the Visual Studio installer to replace the missing file.

The vcvarsall.bat file also varies from version to version. If the current version of Visual Studio is installed on a computer that also has an earlier version of Visual Studio, do not run vcvarsall.bat or another Visual Studio command file from different versions in the same command prompt window.


4 Answers 4

The "pattern" is given by the shell's grammar. In simple cases, it's a command (or rather, a utility), followed by arguments. Arguments may be options, and options may have option arguments. After the options there may be other operands.

ls is the command, -l is an option (with no option argument), and dir is an operand. We know that dir is not an option argument to the -l option since we have read the ls manual in which the synopsis section describes the calling sequence of the utility.

git is the command and since there are no options immediately following the command name, the rest is treated as operands. It's up to the git command to interpret this. You may want to call the commit operand a "sub command" if you wish, and -p an "option" to this sub command.

Here, cc is the command and both -o and -Wall are options. The -o option takes code.o as an option argument. Depending on the cc command, the -Wall option may in fact be parsed as -W all , i.e. as an option with an option argument (one-letter options do not require a space before their option arguments). code.c is an operand as it occurs after all options.

The words "argument", "option" and "option argument" are the ones used by the POSIX standard. The standard uses the word "utility" rather than "command" as a command may be simple, a list, compound, pipeline etc. For example, ls -l dir is one (simple) command using the utility ls , and < head -n 20 | tail -n 5 >>file is a compound command containing a pipeline and two simple commands.

Arguably, all utility invocations are "actions". Saying killall myprog means "start the utility killall with the operand myprog ". The effect thereof will be that the utility, in this case, sends a signal to a process.

Likewise, service restart nginx is the action of invoking the service utility with restart and nginx as the two operands. The effect thereof will be that the nginx service is restarted.

Likewise, nano somedoc is the action of invoking the nano editor, etc. etc.

Of the potential patterns you listed, this is the only one that actually exists:

name of program > additional parameters

First a few word definitions:

  • a program or an application: basically a file that can be executed
  • a process: an instance of a program that is currently running
  • a daemon: a program or process that is doing something independently of any user's login session usually something that is or can be started automatically at boot time, and runs until the system is shut down things like remote access protocol server (e.g. sshd ), web server (Apache), network connections manager ( NetworkManager , ModemManager ).
  • a service: something that is typically started at boot time can be a daemon or just a script that sets up something and ends, and may do the corresponding tear-down actions when the system is being shut down. In some contexts, may also refer to the arrangement to make a program start at boot as a daemon.

service started its life as a simple wrapper for SysVinit-style startup/shutdown scripts. If traditional SysVinit is used as init system (the process #1, the "mother of all processes") in Linux, these scripts are typically located in /etc/init.d directory. Those scripts have standardized parameters: start for starting a service, stop for stopping one, or status for querying the state of a service. There are a few others.

But because writing /etc/init.d/<service name> <action parameter> was tedious, someone made a simple wrapper script: service <name> <action parameter> originally meant just /etc/init.d/<name> <action parameter> .

When SysVinit was replaced with more modern alternatives ( systemd , upstart or others), people wanted to keep the familiar service command and made it a wrapper for the equivalent command for their init system. When systemd is used, service <name> <action parameter> is usually just a wrapper for systemctl <action parameter> <name> . Note the changed order of parameters.

First in Unix the philosophy is that everything is a file. In all your commands, you are only dealing with files on your hard disk: mytextfile , nginx or openvpn are all files.

Now, what the files represent and what actions you can have on them is merely dictated by conventions. Sometimes, and coming from some other OS, files have extensions to better illustrate what they do. Like a text file you can edit will be with .txt at the end, a program will be .sh or .php or .pl , etc. But there are only conventions (the unix bit x for execute is another hint at what is data versus what is executable)

What you list are actions ( nano , service restart , killall ) on different objects/files ( mytextfile , nginx , openvpn ).

Depending on the action you choose and the objects the results would be different. You could as well have done nano openvpn and it would edit, or create, a file called openvpn where you are (this would probably be useless and disturbing, but the tools do not forbid that).

Now as for your specific actions:

  • nano is a text editor, to modify the content of any file (of course if it is a binary files - like some executables but not all - it would be the wrong tool to use to do anything useful)
  • service restart is an action with a "subaction" of restart that uses the current framework on your system dealing with starting/stopping long lived processes also called daemons note that it is only one case among others, it could have been /etc/init.d/nginx restart elsewhere or systemctl restart nginx.service the fact that restart exists as a subaction is entirely specific to the service command any command can have different syntax, with different switches, arguments, subactions, etc. Noone can memorize them all.
  • and killall is a command to look at the list of all current running processes and kill the ones matching the given name (bit of warning: this command does not do the same things on all Unix systems so make sure to read its manual on the host you are using it before using it), so you could in fact provide any name and not necessarily something that exist as a file on disk

Many of your terms are synonyms and loosely defined anyway. An application is anything that can run (be executed), when it is running it is a process handled by the kernel among many other processes. Long living applications typically not under direct control of the user, such as network applications like a webserver, were often called daemons in the past, and are today often called services (even more with systemctl see example syntax above)

You should not have to memorize any kind of this stuff. You will learn it by using them, like if you work with nginx as web server, you will need to restart it and in your specific platform for that it is service restart and so on.


Run command for system information

System information utility shows information of all the hardware and system software available on a computer system. This utility can be launched from Run window by executing the command msinfo32.

Listed below are the details this command shows:
OS name, version, system manufacturer, processor, BIOS, physical memory, virtual memory, page file space, CDROM, sound devices, network, ports, modem, storage, USB, system drives, signed drivers, loaded modules, services, start up programs etc.

need command line information about our network system

hi there i am looking for cmd for all details of computer

Use systeminfo /s for a remote host or simply systeminfo for your local host.

need cmd for connected network and data useses as well connection and disconnection information

this command doesnt work when using windows server
it just show blank


List Event Logs On The Remote System With PsLogList

Remote system logs can be dumped into local system easily with PsLogList command. If we use this command without any extra parameter it will dump all event logs from remote system which will fill out command line. So for the example we will limit for last 5 minutes event logs with -m option.

List Event Logs On The Remote System With PsLogList

Watch the video: 5 πολύ χρήσιμες εντολές CMD 1