X Tutup
The Wayback Machine - https://web.archive.org/web/20250814010214/https://github.com/processing/processing/pull/5082
Skip to content

Build out shell a bit more #5082

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

Merged
merged 2 commits into from
Jul 11, 2017
Merged

Build out shell a bit more #5082

merged 2 commits into from
Jul 11, 2017

Conversation

gohai
Copy link
Contributor

@gohai gohai commented May 22, 2017

No description provided.

@benfry
Copy link
Contributor

benfry commented May 22, 2017

Responding to your email…

shellQuoted() was only added b/c it was necessary—I think we may need to debug why it wasn't working for you.

And the concern I'd have with just using /bin/sh is that folks might be disappointed when their init or config stuff isn't available—isn't that part of the point of having shell() as a separate command?

@gohai
Copy link
Contributor Author

gohai commented May 22, 2017

I'll put in the code that emulates the interactive shell then!

@gohai
Copy link
Contributor Author

gohai commented May 22, 2017

@benfry With the latest commit:

StringList out = new StringList();
StringList err = new StringList();
shell(out, err, "echo $PATH");
println(out);

Gives me the same the same PATH from inside Processing compared to when query this in the terminal. (Tested on macOS.)

@gohai
Copy link
Contributor Author

gohai commented May 22, 2017

Also tested on latest Raspbian.

@benfry
Copy link
Contributor

benfry commented May 23, 2017

Also the null/non-null thing is going to be a problem in code: I think you're gonna need to cast the null to a StringList object, because a null next to String... cannot be distinguished by the compiler. Please double-check.

Do we really need an additional version with just stdout? I lean toward just keeping it simple… either you want the output or not, and my general experience has been that programs are inconsistent enough about what goes in err and what goes in out…

@gohai
Copy link
Contributor Author

gohai commented May 24, 2017

Double-checked the situation with the variable number of arguments - seems to work 👍

Thinking a bit about my use cases: stderr is certainly useful for user-facing errors, but in many situations I'd forgo the extra line that constructs its StringList object because I'll anyway do a regex on the stdout - and if the number of matches isn't as expected, this would be my error condition.

You bring up a good point that stdout vs stderr isn't really so consistent anyway. Is there a possibility of combining both streams in a way that keeps the temporal ordering, perhaps? (On UNIX one could alternatively do 2>&1 in the cmd, but this should better be parsed, since people might want to do their own tricks with re-directions inside the argument.) What would you think about folding both into a single StringList - vs. having variants with one or two StringList arguments?

@benfry benfry merged commit f32c319 into processing:master Jul 11, 2017
@gohai gohai deleted the shell branch July 19, 2017 16:09
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
X Tutup