Skip to content

Remove extraneous backticks #10726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 9, 2024
Merged

Remove extraneous backticks #10726

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 17 additions & 30 deletions xml/System.Diagnostics/ProcessStartInfo.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,9 +71,7 @@
[!INCLUDE [untrusted-data-instance-note](~/includes/untrusted-data-instance-note.md)]

> [!NOTE]
> This class contains a link demand at the class level that applies to all members. A <xref:System.Security.SecurityException> is thrown when the immediate caller does not have full-trust permission. For details about security demands, see [Link Demands](/dotnet/framework/misc/link-demands).


> This class contains a link demand at the class level that applies to all members. A <xref:System.Security.SecurityException> is thrown when the immediate caller does not have full-trust permission. For details about security demands, see [Link Demands](/dotnet/framework/misc/link-demands).

## Examples
The following code example demonstrates how to use the <xref:System.Diagnostics.ProcessStartInfo> class to start Internet Explorer. The destination URLs are provided as <xref:System.Diagnostics.ProcessStartInfo> arguments.
Expand Down Expand Up @@ -309,34 +307,25 @@
<remarks>
<format type="text/markdown"><![CDATA[

`ArgumentList` and the <xref:System.Diagnostics.ProcessStartInfo.Arguments> property are independent of one another and **only one of them can be used at the same time**. The main difference between both APIs is that `ArgumentList` takes care of escaping the provided arguments and **internally** builds a single string that is passed to operating system when calling `Process.Start(info)`. So if you are not sure how to properly escape your arguments, you should choose `ArgumentList` over <xref:System.Diagnostics.ProcessStartInfo.Arguments>.
`ArgumentList` and the <xref:System.Diagnostics.ProcessStartInfo.Arguments> property are independent of one another and **only one of them can be used at the same time**. The main difference between these APIs is that `ArgumentList` escapes the provided arguments and **internally** builds a single string that's passed to the operating system when calling `Process.Start(info)`. So if you aren't sure how to properly escape your arguments, you should choose `ArgumentList` over <xref:System.Diagnostics.ProcessStartInfo.Arguments>.

[!INCLUDE [untrusted-data-instance-note](~/includes/untrusted-data-instance-note.md)]
```

## Examples

This example adds three arguments to the process start info.

```csharp
var info = new System.Diagnostics.ProcessStartInfo("cmd.exe");
info.ArgumentList.Add("/c");
info.ArgumentList.Add("dir");
info.ArgumentList.Add(@"C:\Program Files\dotnet"); // there is no need to escape the space, the API takes care of it

// or if you prefer collection property initializer syntax:

var info = new System.Diagnostics.ProcessStartInfo("cmd.exe")
{
ArgumentList = {
"/c",
"dir",
@"C:\Program Files\dotnet"
@"C:\Program Files\dotnet" // The space character is escaped automatically.
}
};

// The corresponding assignment to the Arguments property is:

var info = new System.Diagnostics.ProcessStartInfo("cmd.exe")
{
Arguments = "/c dir \"C:\\Program Files\\dotnet\""
Expand All @@ -349,7 +338,6 @@ info.ArgumentList.Add("dir")
info.ArgumentList.Add("C:\Program Files\dotnet")

' The corresponding assignment to the Arguments property is:

info.Arguments = "/c dir ""C:\Program Files\dotnet"""
```
]]></format>
Expand Down Expand Up @@ -807,7 +795,7 @@ If you use this property to set command-line arguments, <xref:System.Diagnostics
## Remarks

> [!NOTE]
> <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> must be `true` if you want to set <xref:System.Diagnostics.ProcessStartInfo.ErrorDialog%2A> to `true`.
> <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> must be `true` if you want to set <xref:System.Diagnostics.ProcessStartInfo.ErrorDialog%2A> to `true`.

]]></format>
</remarks>
Expand Down Expand Up @@ -1124,17 +1112,17 @@ If you use this property to set command-line arguments, <xref:System.Diagnostics
## Remarks

> [!IMPORTANT]
> The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property must be set if <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> and <xref:System.Diagnostics.ProcessStartInfo.Password%2A> are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.
> The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property must be set if <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> and <xref:System.Diagnostics.ProcessStartInfo.Password%2A> are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.

> [!NOTE]
> Setting the <xref:System.Diagnostics.ProcessStartInfo.Domain%2A>, <xref:System.Diagnostics.ProcessStartInfo.UserName%2A>, and the <xref:System.Diagnostics.ProcessStartInfo.Password%2A> properties in a <xref:System.Diagnostics.ProcessStartInfo> object is the recommended practice for starting a process with user credentials.
> Setting the <xref:System.Diagnostics.ProcessStartInfo.Domain%2A>, <xref:System.Diagnostics.ProcessStartInfo.UserName%2A>, and the <xref:System.Diagnostics.ProcessStartInfo.Password%2A> properties in a <xref:System.Diagnostics.ProcessStartInfo> object is the recommended practice for starting a process with user credentials.

A <xref:System.Security.SecureString> object is like a <xref:System.String> object in that it has a text value. However, the value of a <xref:System.Security.SecureString> object is automatically encrypted, it can be modified until your application marks it as read-only, and it can be deleted from computer memory by either your application or the .NET Framework garbage collector.

For more information about secure strings and an example of how to obtain a password to set this property, see the <xref:System.Security.SecureString> class.

> [!NOTE]
> If you provide a value for the <xref:System.Diagnostics.ProcessStartInfo.Password%2A> property, the <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> property must be `false`, or an <xref:System.InvalidOperationException> will be thrown when the <xref:System.Diagnostics.Process.Start%28System.Diagnostics.ProcessStartInfo%29?displayProperty=nameWithType> method is called.
> If you provide a value for the <xref:System.Diagnostics.ProcessStartInfo.Password%2A> property, the <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> property must be `false`, or an <xref:System.InvalidOperationException> will be thrown when the <xref:System.Diagnostics.Process.Start%28System.Diagnostics.ProcessStartInfo%29?displayProperty=nameWithType> method is called.

]]></format>
</remarks>
Expand Down Expand Up @@ -1266,14 +1254,14 @@ If you use this property to set command-line arguments, <xref:System.Diagnostics
When a <xref:System.Diagnostics.Process> writes text to its standard error stream, that text is typically displayed on the console. By redirecting the <xref:System.Diagnostics.Process.StandardError%2A> stream, you can manipulate or suppress the error output of a process. For example, you can filter the text, format it differently, or write the output to both the console and a designated log file.

> [!NOTE]
> You must set <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> to `false` if you want to set <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardError%2A> to `true`. Otherwise, reading from the <xref:System.Diagnostics.Process.StandardError%2A> stream throws an exception.
> You must set <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> to `false` if you want to set <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardError%2A> to `true`. Otherwise, reading from the <xref:System.Diagnostics.Process.StandardError%2A> stream throws an exception.

The redirected <xref:System.Diagnostics.Process.StandardError%2A> stream can be read synchronously or asynchronously. Methods such as <xref:System.IO.StreamReader.Read%2A>, <xref:System.IO.StreamReader.ReadLine%2A> and <xref:System.IO.StreamReader.ReadToEnd%2A> perform synchronous read operations on the error output stream of the process. These synchronous read operations do not complete until the associated <xref:System.Diagnostics.Process> writes to its <xref:System.Diagnostics.Process.StandardError%2A> stream, or closes the stream.

In contrast, <xref:System.Diagnostics.Process.BeginErrorReadLine%2A> starts asynchronous read operations on the <xref:System.Diagnostics.Process.StandardError%2A> stream. This method enables a designated event handler for the stream output and immediately returns to the caller, which can perform other work while the stream output is directed to the event handler.

> [!NOTE]
> The application that is processing the asynchronous output should call the <xref:System.Diagnostics.Process.WaitForExit%2A?displayProperty=nameWithType> method to ensure that the output buffer has been flushed.
> The application that is processing the asynchronous output should call the <xref:System.Diagnostics.Process.WaitForExit%2A?displayProperty=nameWithType> method to ensure that the output buffer has been flushed.

Synchronous read operations introduce a dependency between the caller reading from the <xref:System.Diagnostics.Process.StandardError%2A> stream and the child process writing to that stream. These dependencies can cause deadlock conditions. When the caller reads from the redirected stream of a child process, it is dependent on the child. The caller waits for the read operation until the child writes to the stream or closes the stream. When the child process writes enough data to fill its redirected stream, it is dependent on the parent. The child process waits for the next write operation until the parent reads from the full stream or closes the stream. The deadlock condition results when the caller and child process wait for each other to complete an operation, and neither can continue. You can avoid deadlocks by evaluating dependencies between the caller and child process.

Expand Down Expand Up @@ -1376,7 +1364,7 @@ You can use asynchronous read operations to avoid these dependencies and their d
A <xref:System.Diagnostics.Process> can read input text from its standard input stream, typically the keyboard. By redirecting the <xref:System.Diagnostics.Process.StandardInput%2A> stream, you can programmatically specify the input of a process. For example, instead of using keyboard input, you can provide text from the contents of a designated file or output from another application.

> [!NOTE]
> You must set <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> to `false` if you want to set <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardInput%2A> to `true`. Otherwise, writing to the <xref:System.Diagnostics.Process.StandardInput%2A> stream throws an exception.
> You must set <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> to `false` if you want to set <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardInput%2A> to `true`. Otherwise, writing to the <xref:System.Diagnostics.Process.StandardInput%2A> stream throws an exception.



Expand Down Expand Up @@ -1463,14 +1451,14 @@ You can use asynchronous read operations to avoid these dependencies and their d
When a <xref:System.Diagnostics.Process> writes text to its standard stream, that text is typically displayed on the console. By setting <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardOutput%2A> to `true` to redirect the <xref:System.Diagnostics.Process.StandardOutput%2A> stream, you can manipulate or suppress the output of a process. For example, you can filter the text, format it differently, or write the output to both the console and a designated log file.

> [!NOTE]
> You must set <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> to `false` if you want to set <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardOutput%2A> to `true`. Otherwise, reading from the <xref:System.Diagnostics.Process.StandardOutput%2A> stream throws an exception.
> You must set <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> to `false` if you want to set <xref:System.Diagnostics.ProcessStartInfo.RedirectStandardOutput%2A> to `true`. Otherwise, reading from the <xref:System.Diagnostics.Process.StandardOutput%2A> stream throws an exception.

The redirected <xref:System.Diagnostics.Process.StandardOutput%2A> stream can be read synchronously or asynchronously. Methods such as <xref:System.IO.StreamReader.Read%2A>, <xref:System.IO.StreamReader.ReadLine%2A>, and <xref:System.IO.StreamReader.ReadToEnd%2A> perform synchronous read operations on the output stream of the process. These synchronous read operations do not complete until the associated <xref:System.Diagnostics.Process> writes to its <xref:System.Diagnostics.Process.StandardOutput%2A> stream, or closes the stream.

In contrast, <xref:System.Diagnostics.Process.BeginOutputReadLine%2A> starts asynchronous read operations on the <xref:System.Diagnostics.Process.StandardOutput%2A> stream. This method enables a designated event handler (see <xref:System.Diagnostics.Process.OutputDataReceived>) for the stream output and immediately returns to the caller, which can perform other work while the stream output is directed to the event handler.

> [!NOTE]
> The application that is processing the asynchronous output should call the <xref:System.Diagnostics.Process.WaitForExit%2A> method to ensure that the output buffer has been flushed.
> The application that is processing the asynchronous output should call the <xref:System.Diagnostics.Process.WaitForExit%2A> method to ensure that the output buffer has been flushed.

Synchronous read operations introduce a dependency between the caller reading from the <xref:System.Diagnostics.Process.StandardOutput%2A> stream and the child process writing to that stream. These dependencies can cause deadlock conditions. When the caller reads from the redirected stream of a child process, it is dependent on the child. The caller waits for the read operation until the child writes to the stream or closes the stream. When the child process writes enough data to fill its redirected stream, it is dependent on the parent. The child process waits for the next write operation until the parent reads from the full stream or closes the stream. The deadlock condition results when the caller and child process wait for each other to complete an operation, and neither can continue. You can avoid deadlocks by evaluating dependencies between the caller and child process.

Expand All @@ -1490,8 +1478,6 @@ There is a similar issue when you read all text from both the standard output an

You can use asynchronous read operations to avoid these dependencies and their deadlock potential. Alternately, you can avoid the deadlock condition by creating two threads and reading the output of each stream on a separate thread.



## Examples
:::code language="cpp" source="~/snippets/cpp/VS_Snippets_CLR/ProcessOneStream/CPP/stdstr.cpp" id="Snippet1":::
:::code language="csharp" source="~/snippets/csharp/System.Diagnostics/ProcessStartInfo/RedirectStandardOutput/stdstr.cs" id="Snippet1":::
Expand Down Expand Up @@ -1756,7 +1742,7 @@ You can use asynchronous read operations to avoid these dependencies and their d
## Remarks

> [!IMPORTANT]
> The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property must be set if <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> and <xref:System.Diagnostics.ProcessStartInfo.Password%2A> are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.
> The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property must be set if <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> and <xref:System.Diagnostics.ProcessStartInfo.Password%2A> are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.

If the <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> property is not `null` or an empty string, the <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> property must be `false`, or an <xref:System.InvalidOperationException> will be thrown when the <xref:System.Diagnostics.Process.Start%28System.Diagnostics.ProcessStartInfo%29?displayProperty=nameWithType> method is called.

Expand Down Expand Up @@ -1920,7 +1906,8 @@ Each file name extension has its own set of verbs, which can be obtained by usin
When you use the <xref:System.Diagnostics.ProcessStartInfo.Verb%2A> property, you must include the file name extension when you set the value of the <xref:System.Diagnostics.ProcessStartInfo.FileName%2A> property. The file name does not need to have an extension if you manually enter a value for the <xref:System.Diagnostics.ProcessStartInfo.Verb%2A> property.

## Examples
The following code example starts a new process by using the specified verb and file name. This code example is part of a larger example provided for the <xref:System.Diagnostics.ProcessStartInfo.Verbs%2A> property.

The following code example starts a new process by using the specified verb and file name. This code example is part of a larger example provided for the <xref:System.Diagnostics.ProcessStartInfo.Verbs%2A> property.

:::code language="csharp" source="~/snippets/csharp/System.Diagnostics/ProcessStartInfo/Verb/source.cs" id="Snippet4":::
:::code language="vb" source="~/snippets/visualbasic/VS_Snippets_CLR/ProcessVerbs_Diagnostics/VB/source.vb" id="Snippet4":::
Expand Down Expand Up @@ -2164,14 +2151,14 @@ When you use the <xref:System.Diagnostics.ProcessStartInfo.Verb%2A> property, yo
## Remarks

> [!IMPORTANT]
> The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property must be set if <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> and <xref:System.Diagnostics.ProcessStartInfo.Password%2A> are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.
> The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property must be set if <xref:System.Diagnostics.ProcessStartInfo.UserName%2A> and <xref:System.Diagnostics.ProcessStartInfo.Password%2A> are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.

If the directory is already part of the system path variable, you do not have to repeat the directory's location in this property.

The <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property behaves differently when <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> is `true` than when <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> is `false`. When <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> is `true`, the <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property specifies the location of the executable. If <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> is an empty string, the current directory is understood to contain the executable.

> [!NOTE]
> When <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> is `true`, the working directory of the application that starts the executable is also the working directory of the executable.
> When <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> is `true`, the working directory of the application that starts the executable is also the working directory of the executable.

When <xref:System.Diagnostics.ProcessStartInfo.UseShellExecute%2A> is `false`, the <xref:System.Diagnostics.ProcessStartInfo.WorkingDirectory%2A> property is not used to find the executable. Instead, its value applies to the process that is started and only has meaning within the context of the new process.

Expand Down
Loading