This gem was last updated on the 05.12.2023 (dd.mm.yyyy notation), at 07:04:51 o'clock.

History of this project

In the past I used separate projects / gems, such as OpenInEditor or OpenInBrowser, to open files via my favourite editor, or to open remote URLs via my favourite browser.

Additionally I also had more code aggregated in roebe/classes/open/.

This slightly confusing situation accrued over the years, from 2010 to 2021 or so.

In early September 2021 I reconsidered the old approach.

I wanted to not only clean up the old code base, making it more flexible as well in the process, but add a new API such as:

Open.in_editor('/home/foobar.md')
Open.in_editor(this_file: '/home/foobar.md')

As well as:

Open.in_browser(url: 'google.de', browser: 'firefox')

That way we can 'think' of "Open" first, and then simply call the method name that we want to use. On the commandline we can still do:

open_in_editor foobar.rb
open_in_browser google.de

Layout of the project's structure

This subsection will not include all details, but may serve as a slight introduction to how the project is layout.

Most of the constants will reside under open/constants/constants.rb.

Toplevel-methods can be found under open/toplevel_methods/ for the most part. This may be ignored by some classes if they add toplevel-methods directly; in that case the toplevel may be modified by such a class, and can subsequently be found in that .rb file where the class is defined (or the directory, if this class is split up into several different .rb files).

So, for instance, class Open::Browser may define a toplevel method called Open.in_browser().

You can also grep (on Linux) for where the source code resides specifically, of course.

Optional dependencies in this project

Officially there are no hardcoded dependencies in this project.

However had, you are encouraged to install various gems, such as:

• colours
• convert_global_env
• beautiful_url
• opn

These may enhance the ruby code used in this project.

I highly recommend to install the colours gem, but ultimately the code in this project is written deliberately in a manner to make all these add-ons optional, so this is entirely up to you in the end. (If you find some part of the project that makes any of these external dependencies mandatory rather than optional, consider it a bug. Feel free to report it, to see it changed - but I should have covered all these cases already, so it should be highly unlikely that you can find external dependencies that are not guarded via a begin/rescue clause.)

The various open-related activities in this gem

You can "open" many different things: a local file or a remote URL (in the browser). When it comes to opening local files we can also distinguish whether you want to open in your primary editor, open in a a video-player, open a .pdf file in a pdf-viewer and so on and so forth, so we want to be able to distinguish between these different use cases.

The primary activity for this gem is to open a remote URL. In fact: this was the reason why this gem was initially created. I wanted to be able to open all registered URLs from another gem, called BeautifulUrl, in the web browser. Then I can, for instance, do this:

rf local_sitemap

And the local sitemap (a .cgi or .sinatra fila) will be opened in my browser (thorium usually), on the commandline.

This allows me to quickly navigate to all my local web-pages and I can use them as-is. For instance, I had in the past used one webpage that would inform me about upcoming exams at universities. It is quite convenient to view this in the browser. So, this is the functionality covered by Open.in_browser() specifically.

The next use case, the secondary use case, is Open.in_editor(). Here I wanted to be able to open a local file in my favourite editor - a modified variant of the bluefish editor.

Every other open-related functionality, such as opening a local .pdf file, is bundled into the "remaining" use cases herein. In other words: these other use cases are not as relevant and important as the two other use cases described above this paragraph.

class Open::InEditor

This class can be used for opening a (local) file via the editor.

To open a local file via the open-gem, do:

require 'open'

Open.in_editor('FILE_PATH_GOES_IN_HERE')
Open.in_editor('/home/x/programming/ruby/src/open/open.gemspec')

class Open::InBrowser

This class can be used for opening a remote URL via your favourite browser.

Upon requiring the main class, the method called:

open_in_browser()

will be defined as well, to simplify working with the class.

To specify a particular port, use this variant:

Open.open_in_browser(port: 8080)

This is equivalent to this variant here:

PORT_TO_USE = 8080
Open.in_browser(with_localhost: PORT_TO_USE)

So different keywords can be used, however your brain prefers this or that variant.

In February 2022 I discovered the launchy gem. This gem can be used to open a remote URL via your favourite browser too. Since that is a rather neat functionality to have, I decided to integrate this as an optional API into the open gem as well.

Open.open_in_browser(port: 8080, use_launchy: true)
# or this variant
Open.open_in_browser(port: 8080) { :use_launchy }

Note that in order for this to work, e. g. to use :use_launchy such as shown by the last example, you need to have the launchy gem installed, logically.

On windows you can open a remote URL via firefox in the following manner:

start firefox website_here
start firefox blog.fefe.de
start firefox www.howtogeek.com
start firefox -new-tab www.howtogeek.com

In particular the latter variant can be used as-is via cmd.exe. You can also pass the /k flag to spawn a new cmd.exe, on windows. Before knowing that I used the system() approach passing the path to firefox.exe, but that did not work. Via start, though, it does indeed work.

If you want to find out what the currently used browser is, simply issue the following command:

open --browser?

At the least on my home system, if a certain environment variable is set to 1, class Open::InBrowser will prepend a localhost string. If this is unwanted then --do-not-use-localhost can be used to avoid that. For most users of this project this is irrelevant, as there is a check anyway for that environment variable.

class Open::LastUrl

This small class can be used to specifically open the content of the xorg-buffer via the browser.

class Open::WithDelay

You can open files via a delay, through class Open::WithDelay.

You can specify a delay via:

openwithdelay 3

Or via the method:

.set_use_this_delay()
.set_use_this_delay(3)
.set_use_this_delay(0.5)

Why may this be necessary? My old editor (called bluefish) has had problems batch-opening many files, so I needed a delay. With a delay in place the problem I saw went away. So this was mostly 'workaround' code.

Changing to a different default editor and browser

In November 2021 I realized that we need a way to more easily switch between the default main editor and the default main browser. For instance, I abandoned palemoon, so I needed to use firefox quickly.

The old code had hardcoded calls to palemoon, which was not very elegant, and made changes to the code harder naturally.

Thus two new yaml files were added to the gem:

use_this_browser.yml
use_this_editor.yml

Now you can modify these yaml files and use a different browser or editor. You can even specify the full path to these browsers and it should work fine.

In July 2022 I decided to extend this functionality.

First, you can now automatically set a new browser via the toplevel method Open.permanently_use_this_browser().

Simply pass the new browser as name to the method, such as:

Open.permanently_use_this_browser('thorium') # if you want to use the thorium browser

The second argument is optional and allows the user to specify another .yml file to use. The default value should be fine for most users, though, in perhaps 99.9% of the use cases.

Note that the save_file gem is required for this functionality.

Note that you can also place a file called use_this_browser.yml in your home directory - the home directory can be queried via Dir.home. This .yml file, should it exist, will be checked first. That way you can simply assign a new default value without having to modify the internal .yml files of this project.

Finding out the current editor and browser in use

Use the following two methods if you wish to find out which is the current main editor and the current main browser in use.

puts Open.use_which_editor?
puts Open.use_which_browser? # Or the shorter alias: Open.browser?

Both values can be changed for your own use case. For instance, if you would like to change the browser to be used, use either of the following two methods:

Open.set_use_this_browser
Open.use_this_browser=

Currently, as of July 2022, the following browsers have been tested and "integrated":

firefox
palemoon
chromium
thorium

More may be added in the future. Note that "integrated" mostly means tested on my home system. Each of these may use a slightly different way to open a remote URL in a tab, so the syntax has to be adjusted to each browser differently.

class Open::Base

This subsection contains just a few pointers to the class called Open::Base.

The method .this_file_was_not_found() can be used to designate that a certain file (the input argument to that method) could not be found.

Determining which browser is in use

You can use this method to query which browser has been assigned to be used for Open:

Open.use_which_browser?

Opening local files when the symbol : is used

You can use e. g.

open_in_editor :gamebooks

To open all files that belong to gamebooks. This is catered to my own use cases. You may have to change the .yml file to suit your own use cases. I needed this functionality to batch-open a "project", based on individual files, so this functionality was added in March 2023.

Handling .pdf files

You can call this method to find out which PDF viewer will be used:

Open.pdf_viewer?

I recommend to install the gem pdf_paradise - it handles all my .pdf related needs.

Contact information and mandatory 2FA (no longer) coming up in 2022 / 2023

If your creative mind has ideas and specific suggestions to make this gem more useful in general, feel free to drop me an email at any time, via:

shevy@inbox.lt

Before that email I used an email account at Google gmail, but in 2021 I decided to slowly abandon gmail, for various reasons. In order to limit the explanation here, allow me to just briefly state that I do not feel as if I want to promote any Google service anymore when the user becomes the end product (such as via data collection by upstream services, including other proxy-services). My feeling is that this is a hugely flawed business model to begin with, and I no longer wish to support this in any way, even if only indirectly so, such as by using services of companies that try to promote this flawed model.

In regards to responding to emails: please keep in mind that responding may take some time, depending on the amount of work I may have at that moment. So it is not that emails are ignored; it is more that I have not (yet) found the time to read and reply. This means there may be a delay of days, weeks and in some instances also months. There is, unfortunately, not much I can do when I need to prioritise my time investment, but I try to consider all feedback as an opportunity to improve my projects nonetheless.

In 2022 rubygems.org decided to make 2FA mandatory for every gem owner eventually:

see https://blog.rubygems.org/2022/06/13/making-packages-more-secure.html

Mandatory 2FA will eventually be extended to all rubygems.org developers and maintainers. As I can not use 2FA, for reasons I will skip explaining here, this means that my projects will eventually be removed, as I no longer have any control over my projects hosted on rubygems.org (because I can not use 2FA).

At that point, I no longer have any control what is done to my projects since whoever is controlling the gems ecosystem took away our control here. I am not sure at which point ruby became corporate-controlled - that was not the case several years ago, so something has changed.

Ruby also only allows 2FA users to participate on the issue tracker these days:

https://bugs.ruby-lang.org/issues/18800

But this has been reverted some months ago, so it is no longer applicable. Suffice to say that I do not think that we should only be allowed to interact on the world wide web when some 'authority' authenticated us, such as via mandatory 2FA, so I hope this won't come back again.

Fighting spam is a noble goal, but when it also means you lock out real human people then this is definitely NOT a good situation to be had.