Skip to content
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.

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

Use space-separated paths instead of comma-separated #551

Merged
merged 5 commits into from
Feb 16, 2020

Conversation

am11
Copy link
Member

@am11 am11 commented Feb 16, 2020

Problem

  1. in Windows as well as in Unix-like operating systems, if the file path contains comma, we cannot reliably use --files option.
  2. we are currently incompatible with shell globbing expansion; without using additional tools as workaround (such as dotnet-format: accept a list of files to format (instead of a full workspace) #9 (comment)).

Solution

Change the semantics of --include or --files and --exclude options from comma-separated to space-separated.

Now we can do things like dotnet-format --files {src,test}/**/*.cs or
git ls-files :/{src,tests}/*.cs | xargs dotnet-format --files.

Additional change

Change the output message to include full path to file, so we can distinguish the clashing files.

- dotnet-format --files ./fileA.cs,"a sub directory/fileA.cs"
+ dotnet-format --files ./fileA.cs "a sub directory/fileA.cs"

-  Formatted code file 'fileA.cs'.
-  Formatted code file 'fileA.cs'.
+  Formatted code file '/path/fileA.cs'.
+  Formatted code file '/path/a sub directory/fileA.cs'.

@JoeRobich
Copy link
Member

I like this change. I wish it had worked this way from the start. Could you update the readme docs that use these options to match the new syntax as part of this PR.

@am11
Copy link
Member Author

am11 commented Feb 16, 2020

@JoeRobich, updated the readme to reflect changes. :)

Copy link
Member

@JoeRobich JoeRobich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this change!

src/Program.cs Outdated Show resolved Hide resolved
@JoeRobich JoeRobich merged commit 93383a2 into dotnet:master Feb 16, 2020
am11 added a commit to am11/format that referenced this pull request Aug 29, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh git ls-files :/tests/Utilities/*.cs | dotnet format
    --include - --folder ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh ls ../../../../../src/generated/{*.cs,*.vb} | dotnet
    format --exclude /dev/stdin --folder ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitation:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 29, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh git ls-files :/tests/Utilities/*.cs | dotnet format
    --include - --folder ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh ls ../../../../../src/generated/{*.cs,*.vb} | dotnet
    format --exclude /dev/stdin --folder ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 29, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitation:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 29, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitation:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitation:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
2. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicit deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
`yield return` and enumerator dispatches format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make the pipele , it would require some refactorings; so files
are `yield return` and enumerator can dispatch format operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`ed and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`ed and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

Usage examples:

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

Rules:

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

Limitations / future considerations:

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`ed and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`ed and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`'d and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional tests for
CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so PR did not included any new mechanism.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`'d and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional test mechanism
for CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so no tests are included in this PR.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`'d and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional test mechanism
for CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so no tests are included in this PR.
am11 added a commit to am11/format that referenced this pull request Aug 30, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`'d and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional test mechanism
for CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so no tests are included in this PR.
am11 added a commit to am11/format that referenced this pull request Sep 9, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`'d and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional test mechanism
for CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so no tests are included in this PR.
am11 added a commit to am11/format that referenced this pull request Sep 9, 2020
Today, `dotnet-format` accepts space-separated list of files. This
allows us to pass files via shell's native globbing expansion,
heredoc style redirections as well as via pipelines (see dotnet#551 for
examples). However, in case of pipeline it requires a second utility
(`xarg`) to transform pipeline input as space-separated list to
`dotnet-format`.

This PR implements native pipeline reading support for `--include`
and `--exclude` options, while keeping the space-separated list
intact.

#### Usage examples

1. Include all C# source files under `tests/Utilities` directory
that are in git source tree:

    ```sh
    git ls-files :/tests/Utilities/*.cs | dotnet format --include - --folder
    ```
3. Format all C# source files in last commit:

    ```sh
    git show --name-only --pretty="" | dotnet format --include - --folder
    ```
2. Exclude certain `*.cs` and `*.vb` files using `ls(1)`:

    ```sh
    ls ../../../../../src/generated/{*.cs,*.vb} | dotnet format --exclude /dev/stdin --folder
    ```

#### Rules

* Based on Guideline 13 of [IEEE
1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02)
(POSIX),  it accepts `-` as an explicit marker for stdin with
addition of:
  * `/dev/stdin` - which is a universal synonym of `-` on all Unices.
  * It *only* accepts explicit markers (`/dev/stdin` or `-`) and
  does not implicitly deduce the output if standard input was redirected,
  but marker was not present. This is because our usage is multi-purpose
  (both `--include` and `--exclude`).
* It is an error if both `--include` and `--exclude` are using stdin
marker (`/dev/stdin` or `-`).

#### Limitations / future considerations

* Currently, it reads the entire input from pipeline in `include`/`exclude`
buffer, and then runs the operation on the whole batch. In order
to make it true pipeline friendly, it would require some refactoring;
so files are `yield return`'d and enumerator can dispatch format
operation per file.
* At present, we do not have out-of-process functional test mechanism
for CLI to effectively validate these kind of use-cases (redirection
and shell globbing vs. dotnet-format's built-in globbing support);
so no tests are included in this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants