This repository has been archived by the owner on Nov 23, 2018. It is now read-only.
LANG Variable Setter (needed for MiniMagick) #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
we load up the same environment. So, splitting these up. This is needed for making Benchmark its own thing and not part of the test suite.
This is good because the test output was all messed up and was much slower because of the benchmarks. With this... rake test is NOT a way to run benchmark. It just runs the literal tests with pretty output.
we want passed in to the Process command. It now defaults to "C" if nothing is passed in. The issue with this is, if you are writing a tool that integrates with a UNIX utility (that's why you are using subexec afterall!) and your user's system has a LANG variable set that isn't what you built the system for, then parsing output can be an issue. So, a user in france runs "identify" and the output is in french instead of English. Your library needs a standard output to parse. Hence, "C" is used as this standard output in most UNIX utils. Usually its the same as "en_US", but it can vary. Or, you can pass in a :lang variable when you call run. Subexec.run "echo $LANG", :lang => "en_GB" It will set the language for that ONE command. Your overall environment won't be effected. Wrote tests for all of this.
|
Sorry about the big delay in getting this merged. I've merged it and bumped the version of subexec to 0.1.0. Thanks for all the tests too. |
ilnurnasyrov2
pushed a commit
to metastudio/mini_magick
that referenced
this pull request
Apr 2, 2014
New release of subexec (pull request here: pressly/subexec#3 )
This pull request was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We can now specifiy what LANG environment variable
we want passed in to the Process command. It now defaults
to "C" if nothing is passed in.
The issue with this is, if you are writing a tool that
integrates with a UNIX utility (that's why you are using
subexec afterall!) and your user's system has a LANG
variable set that isn't what you built the system for,
then parsing output can be an issue.
So, a user in france runs "identify" and the output is
in french instead of English. Your library needs a standard
output to parse. Hence, "C" is used as this standard output
in most UNIX utils. Usually its the same as "en_US", but it
can vary.
Or, you can pass in a :lang variable when you call run.
Subexec.run "echo $LANG", :lang => "en_GB"
It will set the language for that ONE command. Your
overall environment won't be effected.
Wrote tests for all of this.