Prevously OpenTofu delegated browser launching entirely to the third-party module github.com/cli/browser, which consists of a number of platform-specific lists of executable commands to try to run to launch a web browser. On Unix systems there is also a de-facto convention of using an environment variable called BROWSER to explicitly specify what to launch. That variable can either point directly to a browser, or can point to a script which implements some more complex policy for choosing a browser, such as detecting whether the command is running in a GUI context and launching either a GUI or textmode browser. The BROWSER variable has been most commonly implemented with similar treatment to earlier variables like EDITOR and PAGER where it's expected to be set to just a single command to run, with the URL given as the first and only argument. There was also an attempt to define a more complex interpretation of this variable at http://www.catb.org/~esr/BROWSER/ , but that extended treatment was only implemented in a small amount of software, and those which implemented it did so slightly inconsistently due to the specification being ambiguous. OpenTofu's implementation therefore follows the common simpler convention, but will silently ignore variable values it cannot use so that OpenTofu won't fail when run in an environment that has that variable set in a way that's intended for use by some other software. In that case OpenTofu will continue to perform the default behavior as implemented in the third-party library. Because this convention is Unix-specific, OpenTofu will check for and use this environment variable only on operating systems that the Go toolchain considers to be "unix". This means that in particular on Windows systems OpenTofu will continue to follow the Windows convention of specifying the default browser via an entry in the Windows Registry. As usual with this sort of system-integration mechanism it isn't really viable to test this end-to-end in a portable way, but the main logic is separated out into testable functions, and I manually tested this on my own Linux system to verify that it works in a real OpenTofu executable. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
OpenTofu
OpenTofu is an OSS tool for building, changing, and versioning infrastructure safely and efficiently. OpenTofu can manage existing and popular service providers as well as custom in-house solutions.
The key features of OpenTofu are:
-
Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.
-
Execution Plans: OpenTofu has a "planning" step where it generates an execution plan. The execution plan shows what OpenTofu will do when you call apply. This lets you avoid any surprises when OpenTofu manipulates infrastructure.
-
Resource Graph: OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, OpenTofu builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.
-
Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what OpenTofu will change and in what order, avoiding many possible human errors.
Getting help and contributing
- Have a question?
- Post it in GitHub Discussions
- Open a GitHub issue
- Join the OpenTofu Slack!
- Want to contribute?
- Please read the Contribution Guide.
- Recurring Events
- Community Meetings on Wednesdays at 12:30 UTC at this link: https://meet.google.com/xfm-cgms-has (📅 calendar link)
- Technical Steering Committee Meetings every other Tuesday at 4pm UTC at this link: https://meet.google.com/cry-houa-qbk (📅 calendar link)
Tip
For more OpenTofu events, subscribe to the OpenTofu Events Calendar!
Reporting security vulnerabilities
If you've found a vulnerability or a potential vulnerability in OpenTofu please follow Security Policy. We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issue positively or negatively.
Reporting possible copyright issues
If you believe you have found any possible copyright or intellectual property issues, please contact liaison@opentofu.org. We'll send a confirmation email to acknowledge your report.
Registry Access
In an effort to comply with applicable sanctions, we block access from specific countries of origin.