Cygwin and irb

If you had tried to start irb in Windows that has cygwin installed, you might have got the following exception trace:

C:/Ruby192/lib/ruby/site_ruby/1.9.1/rbreadline.rb:2095:in `expand_path': non-absolute home (ArgumentError)
        from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rbreadline.rb:2095:in `_rl_read_init_file'
        from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rbreadline.rb:2078:in `rl_read_init_file'
        from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rbreadline.rb:2499:in `readline_initialize_everything'
        from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rbreadline.rb:3730:in `rl_initialize'
        from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rbreadline.rb:4737:in `readline'
        from C:/Ruby192/lib/ruby/site_ruby/1.9.1/readline.rb:40:in `readline'
        from C:/Ruby192/lib/ruby/1.9.1/irb/input-method.rb:115:in `gets'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:139:in `block (2 levels) in eval_input'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:273:in `signal_status'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:138:in `block in eval_input'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:188:in `call'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:188:in `buf_input'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:103:in `getc'
        from C:/Ruby192/lib/ruby/1.9.1/irb/slex.rb:205:in `match_io'
        from C:/Ruby192/lib/ruby/1.9.1/irb/slex.rb:75:in `match'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:286:in `token'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:262:in `lex'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:233:in `block (2 levels) in each_top_level_statement'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in `loop'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in `block in each_top_level_statement'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in `catch'
        from C:/Ruby192/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in `each_top_level_statement'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:155:in `eval_input'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:70:in `block in start'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:69:in `catch'
        from C:/Ruby192/lib/ruby/1.9.1/irb.rb:69:in `start'
        from C:/Ruby192/bin/irb:12:in `
'
The solution to this problem is very simple. Just unset the HOME environment variable and start irb again.
set HOME=
set HOMEDRIVE=
set HOMEPATH=
set HOMESHARE=
Some of them are not directly related to Cygwin. But resetting will help you in avoiding issues while running gems.

Comments

Anonymous said…
Thank you, that solved my problem :)
3/27/2011 07:32:00 AM
Anonymous said…
Thanks, I am able to run irb in windows.
5/31/2012 03:24:00 AM
how to create a database in excel said…
We can usually form more of the possible values and instances out here because in most of the cases the usual thoughts would help students to bring about more of the values.
11/05/2016 01:12:00 AM
Unknown said…
This comment has been removed by the author.
2/07/2018 05:57:00 AM
Post a Comment

Popular posts from this blog

The mysterious ORA-03111 error

Recently one of the applications that I developed started throwing exceptions, that had the following message: SQL state [72000]; error code [1013]; ORA-03111: break received on communication channel When I googled around, I couldn't come across anything useful. Sadly enough most of the sites just showed the documentation for that error, without any explanation from anyone experiencing that issues. So here you go, with the best possible explanation that I could come up with. My application sets two things on the connection that is throwing this exception: It sets the fetchSize to be 2500 rows It sets the query timeout to be 10 seconds The database server and the application are separated over a long latency network (actually there is a NetEm box that emulates the long latency between these two boxes) which has a latency characteristic of 50+/-5 milliseconds. This is the whole setup. It is important to understand how the timeout is handled by the Oracle client (in my case JDBC clien...
Read more

Note on allocationSize parameter of @SequenceGenerator while using JPA

I ran into what I thought as an issue while I was using the sequence ID generation strategy in JPA. The JPA provider I am using is Hibernate. I think sharing my experience will save someone some time. To use a sequence (For e.g. Oracle sequence) to generate values and assign them to the ID field of your persistence object, you will following something like this: @Id @Column(name = "ITEM_ID") @GeneratedValue(strategy = GenerationType.SEQUENCE, generator="ItemIdSeqGenerator") @SequenceGenerator(name="ItemIdSeqGenerator", sequenceName="ITEM_ID_SEQ", allocationSize=1) private long itemId; This means the following things: The @Id annotation says that the field itemId is a primary key. The @Column annotation says that the corresponding column in the database is ITEM_ID. The @GeneratedValue says that the value that needs to be populated in the itemId should be generated, while that object is persisted. The strategy to generate the value is to...
Read more

So you think you understand misfireThreshold?

One of the most critical and least documented features of Quartz is the concept of misfiring and how misfiring is handled. If a trigger was supposed to carry out a job a certain time, and for some reason it was not carried out at that time, it is a misfired trigger. But not any trigger could be treated as a misfired trigger. For e.g. if a trigger is long due for 2 hours from its actual firing time, does it make sense to treat that as a misfired trigger? To make that decision Quartz scheduler relies upon a configurable parameter called misfireThreshold . It is specified in milliseconds. Whenever a trigger is due for misfireThreshold or lesser amount of time, it will be treated as a misfired trigger and triggered depending on the misfire policy specified in the job detail. For e.g. on a certain situation you might want a misfired trigger to be fired immediately, on a certain other situation you might decide its okay to reschdule the same trigger to the next firing time. For SimpleTrigger...
Read more