Issue #20259 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Misc #20259: Proposal to add "ruby --irb" and / or "ruby --start-irb" to start irb (interactive ruby) via ruby (bin/ruby), via the commandline https://bugs.ruby-lang.org/issues/20259 * Author: rubyFeedback (robert heiler) * Status: Open * Priority: Normal ---------------------------------------- This issue proposes to add: a) a commandline flag to bin/ruby that allows the user to start irb, and b) allow the user to make use of ruby to start irb, via the commandline (thus, the proposal's a) and b) are naturally connected to one another, meaning that we would have a commandline flag for the binary "ruby", and this flag, when invoked, will start irb, in the current terminal, just as if we would have typed "irb") Background to this proposal, including prior proposals: I believe there are prior proposals that are related, such as this one here from ~3 years ago: https://bugs.ruby-lang.org/issues/17859 by deivid. Note that my proposal is a bit different: I don't propose that "ruby" would behave like python here, but instead I would propose that bin/ruby gets a specific flag such as "--irb" and/or "--start-irb" (the latter is a bit longer to type, so the former is more convenient, but I also like that the latter, aka --start-irb is more specific, showing the intent more clearly; and we can add both flags anyway, so people can just pick what they prefer. I would probably just make an alias such as "rirb" for "ruby --start-irb" on my local system). The way I came yesterday to a somewhat similar conclusion as deivid did, shall be explained next, even though my path is an indirect one. As some may know, Tim (and others) are creating natalie, a ruby "dialect" (well, it'll be ruby in the end I believe but right now it does not satisfy the full ruby specification): https://github.com/natalie-lang/natalie Although there are some issues natalie currently has (it's a bit slow right now, for instance), they did invest quite a lot of time into it and it is slowly shaping up - at the least presently. More work to be done on satisfying ruby's specification. Yesterday I compiled natalie from a git checkout and it compiled and installed fine. I was confused that under bin/ there was only "natalie", but no irb. I may be wrong but I think in the past I had bin/irb there too. Anyway, that then got me thinking that I may have made a mistake - but, also, why can't we just use ruby to start irb, as-is? That is, the executable called "ruby", under bin/ruby. Yes, this is natalie, not ruby, I understand that. I also fully understand that MRI ruby having --irb and --start-irb does not change the situation for natalie, jruby, truffleruby - you name it. I get that, although I should like to point out that they may often follow suit what MRI ruby decides, so if they have a variant of irb, it may be likely that they would add the same or similar commandline flags to support changes in MRI, even if it may take a while (see jruby issue tracker having tons of todo-entries on github, to keep track of new ruby releases and what changed between version). But I was then also wondering why ruby itself would not allow us to start irb in such a way, via "ruby". I understand that we have bin/irb, so this is not a real problem - people can just start "irb" normally. And I think we can require irb from a ruby .rb file just fine, as well, and use irb that way, all fine too. But even then I still wondered why we can not run irb via "ruby". Is there any reason that speaks against "ruby --start-irb" starting irb? I don't think the stdlib idea for ruby was to prevent ruby itself from providing convenience to the user. I also don't propose other gems to be started like that either, supporting many different commandline flags or --start=name_of_gem_here; irb is more important, in my opinion, than many other gems. The key idea for irb is to have "interactive ruby". pry pushed that idea further, and I think the recent irb releases included some ideas from pry too. ALL of these focus on an "interactive ruby", no matter the real name (be it irb, pry or anything else) - just as "python" without arguments focuses on "interactive python". If we look at python, python kind of provides two ways to run things: "python foobar.py", and without argument, the interactive python. Again, I am not proposing to join that together, different to deivid's proposal, but indeed, it made me question ruby's current behaviour. I think python's behaviour to be able to select either way, via "python" itself, is better; that we are unable to select which behaviour to use via commandline flag, in python, is a drawback, as jeremy pointed out since he prefers the current ruby heaviour, but via an additional commandline flag I think we can at the least get python's interactive behaviour into ruby (that is, IRB; although it should be mentioned that the new IRB is a bit different to the older IRB, but I leave it at that, since the proposal here is about starting IRB, not about IRB's behaviour - the latter is for the github project of IRB, rather than MRI's issue tracker here). deivid reasoned that python's behaviour is useful for newbies, which I do not doubt. jeremy said that he prefers the current behaviour of ruby, which is also fine. An explicit commandline flag for starting irb may be a compromise, but I should like to say that my rationale today was different from deivid's one, in that I actually really want bin/ruby to give us a SIMPLE means to start irb, rather than merely "ruby" showing the same behaviour as "python" does, in regarsd to starting its interactive variant. Again, I can work around this just fine, using a .rb file to start IRB and so forth, but I really think having this supported via a simple commandline flag may be more convenient. Of course, a secondary proposal to this may then be to add another commandline flag to get to support deivid's suggestion :) - but that would also be for another issue request on the bugtracker here. For this proposal, I really merely suggest to add --irb and/or --start-irb (or any other variant that may be more fitting, perhaps --interactive; the name is not so important, although it should be a convenient name and ideally short. The functionality is more important than the name.) Implementation details: Let's for a moment assume people may find this useful. Then the question is, which irb should be started when using "ruby --irb"? Probably the most sensible default option here is to simply use whatever irb version has been installed on the target computer. Hiroshi Shibata and others worked towards gemifying ruby's stdlib, so it makes sense that "ruby --start-irb" would use the currently installed irb version, whatever that is. For most ruby users this is probably the one that came distributed with whatever ruby version they are using, at the least for modern ruby versions. Otherwise they may just install a new irb version from e. g. https://github.com/ruby/irb or whatever: gem install irb installs. And this is then started when they do "ruby --start-irb". So, "ruby --start-irb" would be exactly the same as the user typing "irb" on the commandline, without any further arguments. Of course the user can also start irb via "irb", as-is. So they'd only get an additional way to start irb. They can continue to use "irb" just fine. All that would change is that "ruby" itself would get an additional commandline argument, one that starts its "interactive part". Anyway - I have no idea how much support the above would find; perhaps if jeremy is active he could compare it towards deivid's suggestion and comment on it too. I thought about appending to deivid's suggestion, but the suggestion here is a bit different, so I think it may be better to propose it as a separate one, even though it is somewhat close to his proposal, even though it is unrelated (see how I reached that conclusion, which I think is different than deivid's proposal). I am not sure if there are even older proposals or not, but there may be. It's also fine to close this issue here, by the way, to keep the issue tracker list shorter (and perhaps link it towards deivid's above issue too, if this is closed, which is fine). I kind of wanted to contribute a bit to the discussion from a different point of view. Perhaps to avoid having too many open issues, this issue here could be left open for a month or two, to allow for a bit of more discussion, then it can be closed and e. g. referred to deivids' issue; and if deivid has time he may comment on the one here or his older proposal. At any rate, thank you for reading this proposal. (PS: I filed it under Misc because it did not seem to necessarily be a Feature of the ruby language itself. Of course it could also fit under Feature, so I was not sure where to categorize it.) -- https://bugs.ruby-lang.org/