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

Easier Way to Read Process Output? #3947

Closed
devlead opened this issue Aug 20, 2022 Discussed in #3837 · 4 comments · Fixed by #3948
Closed

Easier Way to Read Process Output? #3947

devlead opened this issue Aug 20, 2022 Discussed in #3837 · 4 comments · Fixed by #3948
Assignees
Labels
Milestone

Comments

@devlead
Copy link
Member

devlead commented Aug 20, 2022

Discussed in https://github.com/orgs/cake-build/discussions/3837

Originally posted by RehanSaeed March 10, 2022
I'm executing a process and reading the output like so:

StartProcess(
    "az",
    new ProcessSettings()
        .WithArguments(x => x
            .Append("account")
            .Append("list-locations"))
        .SetRedirectStandardOutput(true),
        out var lines);
var json = string.Join(Environment.NewLine, lines);

This is pretty cumbersome. I'd really like something far simpler like simple-exec built into Cake build aliases so I don't have to include yet another dependency:

var (standardOutput, standardError) = await ReadAsync("az account list-locations");

I don't believe anything like this currently exists unless there is an alias I'm missing?

@devlead devlead added this to the v2.3.0 milestone Aug 20, 2022
@devlead devlead self-assigned this Aug 20, 2022
devlead added a commit to devlead/cake that referenced this issue Aug 20, 2022
devlead added a commit to devlead/cake that referenced this issue Aug 21, 2022
devlead added a commit to devlead/cake that referenced this issue Aug 22, 2022
gep13 pushed a commit to devlead/cake that referenced this issue Aug 22, 2022
devlead added a commit to devlead/cake that referenced this issue Aug 22, 2022
devlead added a commit to devlead/cake that referenced this issue Aug 23, 2022
gep13 added a commit that referenced this issue Sep 4, 2022
@cake-build-bot
Copy link

🎉 This issue has been resolved in version v2.3.0 🎉

The release is available on:

Your GitReleaseManager bot 📦🚀

@Jericho
Copy link
Contributor

Jericho commented Oct 23, 2022

@devlead Thanks for this improvement. I'm in the process of removing StartProcess from my Cake scripts and replacing them with the new Command. One thing I struggled with is how to specify the tool to execute without using the built-in tool resolution. In other words, I know precisely the location of my desired tool, and I would like to be able to simply specify the full path.

I came up with the following solution, but it feels very verbose to be forced to specify the tool name, tool executable names and tool path:

Command(
	new CommandSettings
	{
		ToolName = appName,
		ToolExecutableNames = new[] { appName, $"{appName}.exe" },
		ToolPath = $"{publishDir}{appName}.exe",
	},
	new ProcessArgumentBuilder()
		.Append("nopause")
);

I tried specifying ToolPath only, but I get "Null" exceptions due to the fact that I omitted ToolName and ToolExecutableNames. Therefore, I am forced to specify all three properties.

It would be great to be able to only specify the FilePath of the desired tool. Something along these lines:

Command(
	new FilePath($"{publishDir}{appName}.exe"),
	new ProcessArgumentBuilder()
		.Append("nopause")
);

@devlead
Copy link
Member Author

devlead commented Oct 23, 2022

@Jericho If ToolPath specified we should be able to use it. So that could be a potential improvement.

For now you should, instead of specifying ToolPath be able to register your exes fullpath with Cake tools resolution, that way tool resolution will find it.

Context.Tools.RegisterFile("C:/ProgramData/chocolatey/bin/NuGet.exe")

https://cakebuild.net/docs/writing-builds/tools/tool-resolution

@Jericho
Copy link
Contributor

Jericho commented Oct 23, 2022

If ToolPath specified we should be able to use it

That would indeed be the best option (in my humble opinion!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants