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

Handling Paths Given to -r and -I in RUBYOPT #20

Open
shinokaro opened this issue May 17, 2024 · 0 comments
Open

Handling Paths Given to -r and -I in RUBYOPT #20

shinokaro opened this issue May 17, 2024 · 0 comments

Comments

@shinokaro
Copy link
Collaborator

shinokaro commented May 17, 2024

RUBYOPT or the --rubyopt option in OCRAN is the only way to provide Ruby startup options for executables generated by OCRAN. In the future, supporting the -r and -I options in RUBYOPT will be necessary.

In the past, OCRAN (OCRA) did nothing with the paths in RUBYOPT.

Since Ruby 3.2, Bundler sets absolute paths in RUBYOPT in a bundle exec environment. The current OCRAN detects and removes these absolute paths added by Bundler.(1369ee5)

We could replace the absolute paths in RUBYOPT with the absolute paths in the user's execution environment. However, in the user's execution environment, the paths may contain spaces, causing Ruby execution to fail.

Specifically, Ruby cannot correctly interpret quoted strings with -r or -I options in RUBYOPT. This is a Ruby issue. However, even if Ruby fixes this problem, we still need to support older versions of Ruby. We need a solution now.

Our options are:

  1. Modify the stub to allow specifying Ruby startup options (-r, -I).
  2. Modify the stub to launch Ruby and the application through a startup script built by OCRAN.

Implementing the first option requires changing the stub's source code.

The second option is already implemented in the InnoSetup builder. If complex preprocessing is required when launching the application, we can imagine a case where the application script set in OCRAN includes a "Ruby script to launch Ruby." (If we don't solve the problem now, someone will do it in the future.) If the second option works well, in the future, the significance of OCRAN providing a startup script builder will be defined as a service rather than a feature.

Note: I consider this a new feature. This functionality did not exist in OCRA.

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

No branches or pull requests

1 participant